in brief:
below we provide a structured overview of the process of an accessibility audit with the aim of determining the current status of accessibility.
the scope and the effort required to check accessibility increases and decreases depending on the target level: a-aa-aaa. the scope is also defined by the range of functions and content of the website to be checked. it should be noted that level aa has been defined as the legal basis. this allows a good compromise between the optimal accessible website and affordable effort to create accessibility for many web users.
here is a brief description of the wcag rules
| version | principles | guidelines | success criteria | for a | for aa | for aaa |
|---|---|---|---|---|---|---|
| 2.0 | 4 | 12 | 61 | 25 | 38 | 61 |
| 2.1 | 4 | 13 | 78 | 30 | 50 | 78 |
| 2.2 | q1-2023 |
procedure
definition test sample
to select the pages to be tested, we analyze the different types of content on the website. examples of this are:
- standard pages
- blog posts single pages, blog posts archive pages
- form pages
- store product single pages, store category pages, store product archive pages
- custom post types, individual and archive pages
- further functions, e.g. event booking, appointment reservation, etc.
representative urls are selected from the different types of content and defined as a test sample.
Automated tests
it should be noted that there is no single tool that reliably shows all deviations from the required properties. however, the results of the tools used provide a good overview of the degree of accessibility, but must be validated manually.
a simple example to help you understand:
a missing alt-tag of an image does not necessarily represent an error.
if the image is not meaningful, for example a graphic as a separator or purely decorative element, there must be no alt-tag to avoid unnecessary reading out of non-meaningful information when using a screen reader.
we use the following tools to carry out automatic tests:
- ... axe devtools (https://www.deque.com/axe/)
- ... tenon toolkit (https://tenon.io)
- ... wave evaluation tool (https://wave.webaim.org)
- ... google lighthouse (lighthouse chrome extension)
- ... css & html validator (w3c validator service)
- summary of the results of the automated tests.
- creation of a to-do (error) list to manual validation.
manual test procedure
after the automatic tests have been carried out, a visual and auditory test is carried out to find all errors that can be detected by visual and auditory perception. examples of this are
- contrast ratios
- responsiveness
- check the audio and video content
another central component of the manual tests is the screen reader test and the in-depth test of keyboard operability.
finally, the declaration of accessibility (if available) is compared with the actual status.
recording of the results
the results are recorded with the help of the wcag-em reporting tool (https://www.w3.org/WAI/eval/report-tool/)
on the one hand, this ensures the completeness of the check and, on the other hand, this report is known to all web developers involved in accessible topics as a working basis for correcting the errors found.
you can find more information on the topic of accessibility for small and medium-sized enterprises in austria in our detailed blog post.
if you have any questions or are interested in the current status of your site, please do not hesitate to contact us:
