Digital accessibility means that websites, apps and software can be used by everyone, including people with disabilities. The focus is on five user groups: blind, visually impaired, motor-impaired, cognitively impaired and auditory-impaired users. The international standard is the WCAG, the Web Content Accessibility Guidelines.
Key Takeaways
- Automated accessibility tests cover around 57 percent of all criteria, according to a study by X-Core, with the remainder requiring manual testing by experienced testers.
- From 2025, the European Accessibility Act will also oblige private companies to ensure digital accessibility; by 2030 at the latest, this will apply to all existing products.
- Anchoring accessibility early on in the development process, i.e. in the style guide and pattern library, prevents expensive rework after a hundred-page test report at the end.
- Sufficiently strong contrasts, correct HTML syntax and keyboard operability are requirements that benefit several user groups at the same time and measurably improve general usability.
What digital accessibility means in concrete terms
Digital accessibility transfers the principle of structural accessibility to websites, software and apps. Just as a ramp next to the stairs allows a wheelchair into a building, digital accessibility ensures that a digital product can be used by everyone, including people with disabilities.
The term is less well-known than its structural sister, but it means the same thing. A website or application should be built in such a way that a blind user can use it just as easily as someone with a visual impairment.
One basic assumption is important: people with disabilities are not a homogeneous group. One blind user is not the same as another blind user. Disabilities have different characteristics and the assistive technologies used differ.
Five user groups structure the requirements
For practical work, digital accessibility can be divided into five broad user groups. This classification gives a development team a framework on which to hang its requirements.
- Blind users: operate the application using a screen reader and keyboard.
- Visually impaired users: need sufficient contrast, among other things.
- Motor-impaired users: often navigate without a mouse, using the keyboard alone.
- Cognitively impaired users: benefit from comprehensibility and a clear structure.
- Auditory impaired users.
Each group has its own requirements. A screen reader reads out the content of a page, so the page must be programmed in such a way that it can reproduce it. Above all, this requires correct HTML syntax.
Keyboard operability connects two groups. Screen reader users navigate using the keyboard, as do users with motor impairments. If a page only works with the mouse, it excludes both.
Where the requirements come from
The relevant requirements are set out in the Web Content Accessibility Guidelines (WCAG), the international standard for accessible digital applications. The EN 301 549 standard is also used to check whether a product is accessible by measuring it against these criteria.
In Germany, the impetus for accessible development has so far mostly come from the law. Since 2021, federal public bodies have been obliged to make their digital products accessible.
This obligation will be extended from 2025. The European Accessibility Act, implemented in Germany in the Barrierefreiheitsstärkungsgesetz, will then also require private companies to implement digital accessibility. The obligation will apply to existing products by 2030 at the latest.
The goal should go beyond the obligation. Accessibility as a self-evident standard, considered from the outset, is a better approach than reacting to a legal requirement.
Accessibility belongs in the process, not at the end
The most common mistake is to finish developing the application and then submit it for accessibility testing. In the worst case, the result is a hundred-page test report and large parts have to be rebuilt. This is not the way to do it.
The better way is to start early. A style guide specifies colors and color combinations, and even here you can check whether the contrasts are sufficient. A pattern library with buttons, dropdowns and select elements can be structured in such a way that the individual components are already barrier-free.
If developers then use these patterns, they will pass on the accessibility by themselves. The effort is spread over the process instead of piling up into an unaffordable mountain at the end.
What can and cannot be tested automatically
Test automation is a good way to achieve a quick effect, but it only covers part of the criteria. A study of around 15,000 manually and automatically tested pages came up with around 57 percent of the criteria that can be tested automatically. More than half, but not all.
Tests with a clear target value can be automated well:
- Contrast ratio between font and background
- Presence of alternative texts
- correct heading hierarchy (H1, H2, H3 neatly nested)
- whether the role of an element matches the element type
- correct HTML syntax
Automation reaches its limits when it comes to meaning. It is easy to check whether an alternative text exists at all. Whether the text matches the image and is meaningful enough for a blind user can hardly be assessed automatically. Humans are needed here.
Moreover, an automated test rule often only covers part of a WCAG criterion. The human eye is still required for the final evaluation. An open source tool such as axe-core, which can be integrated into the pipeline with little effort, is a good place to start.
The gray areas need experience instead of measured value
Many requirements do not have a simple pass or fail. A sensible reading order or simple navigation are examples that can be discussed.
If two experienced testers are testing the same object, one may consider a navigation to be coherent, while the other would swap two or three steps. This is not a defect, but a consequence of the matter. There is no fixed standard that says: this is good enough.
The reason lies in the diversity of users. What is easy for one person is cumbersome for another. It is not possible to make an application one hundred percent right for every single user.
No tester can replace real users
When it comes to usability, there is no way around the people concerned. Screen reader users are the professionals when it comes to using their tool. A screen reader is powerful, and mastering all the operating options requires extensive training.
Testers can recognize rough problems and evaluate many things in advance. However, when it comes to actual usability, it is worth involving a blind user and asking specific questions: Does it work like this, or would it be better another way? This is how the most viable solution is created.
Tests follow the classic pattern
Accessibility testing can be evaluated in the same way as a technical test. The requirements from WCAG and EN 301 549 are translated into test cases that can be carried out and evaluated as passed or failed.
Where a test case fails, there is a barrier. This is documented and summarized in a test report at the end. The only special feature is the shades of gray mentioned above: if the test case has a meaningful reading order, the judgment of the tester decides.
Accessibility is a competitive advantage, not just an obligation
Teams often approach the topic with the feeling that they are carrying out a chore. It costs budget, time and manpower, and employees first have to familiarize themselves with it. The arguments against it, however, lie in the benefits.
Accessibility increases general usability. The contrast example shows it well: everyone reads a text with sufficient contrast more easily and quickly than one where you have to squint your eyes.
Each of us reads a text with sufficient contrast much more easily and preferably than one where we have to squint to read what is written.
Myria Pflaum
The other advantages extend beyond the individual user group:
- More users reached and therefore more sales in the end.
- Positive image because a company invites all users to use the application.
- Better search engine optimization as a side effect of accessible content.
- Access to tenders: Public bodies must offer accessible products and are obliged to require the same for purchased software. Those who already have an accessible product can bid directly and have better chances.
Where to start when everything seems too much
The WCAG is comprehensive. With WCAG 2.2, there are 86 success criteria, each described in detail. Reading through everything at once is more overwhelming than helpful. There are easier ways to get started.
A sample test provides an initial feeling for the status. If you have a large website, have two or three pages tested by experts. The effort involved is manageable and the basic problems are quickly identified and can be rectified.
At the same time, internal access via automated testers helps. Although they do not cover everything, they do provide initial feedback. Once around 57 percent of the covered criteria are clean, a good step in the right direction has been taken.
The third building block is training: gradually empowering developers, designers and testers so that they know what accessible implementation requires. In this way, the topic slowly becomes part of the normal development process.
Where the field is heading
Two developments will shape the next few years. The European Accessibility Act will apply to new developments from 2025 and to existing products by 2030 at the latest. This will raise awareness and should also reach the private sector, which will recognize the competitive advantage as soon as usability and visibility are measurably improved.
The second movement comes from AI. It could make more success criteria automatically verifiable and better interpret existing ones. The alternative text example shows the direction: in future, an AI could assess whether a text matches the image without having to run a manual test over it.
