Digital accessibility means that websites, apps and software can be used by everyone, including people with disabilities. Five user groups are in focus: blind users, users with low vision, users with motor impairments, users with cognitive impairments and users who are deaf or hard of hearing. The international standard is WCAG, the Web Content Accessibility Guidelines.
Key Takeaways
- According to a study by Deque, the maker of axe-core, automated accessibility tests detect around 57 percent of the issues found. The rest has to be checked manually by experienced testers.
- Since June 2025, the European Accessibility Act has also required private companies to make their digital products accessible. By 2030 at the latest, this applies to all existing products as well.
- Building accessibility into the development process early, in the style guide and the pattern library, avoids expensive rework after a hundred-page test report at the end.
- Strong enough contrast, correct HTML and keyboard operability help several user groups at once and make an application measurably easier to use for everyone.
What Digital Accessibility Means in Practice
Digital accessibility applies the idea of accessible buildings to websites, software and apps. A ramp next to the stairs lets a wheelchair user into a building. In the same way, digital accessibility makes sure a digital product works for everyone, including people with disabilities.
The term is less familiar than its counterpart in architecture, but it means the same thing. A website or application should be built so that a blind user can operate it just as well as someone with low vision.
One assumption matters from the start: people with disabilities are not one homogeneous group. Two blind users are not the same user. Disabilities vary, and so do the assistive technologies people rely on.
Five User Groups Give Digital Accessibility a Structure
For practical work, digital accessibility can be broken down into five broad user groups. This gives a development team a framework to organize its requirements around.
- Blind users operate the application with a screen reader and a keyboard.
- Users with low vision need, among other things, sufficient contrast.
- Users with motor impairments often navigate without a mouse, using only the keyboard.
- Users with cognitive impairments benefit from clear language and a clear structure.
- Users who are deaf or hard of hearing need captions and transcripts for audio and video content.
Each group comes with its own requirements. A screen reader reads the content of a page aloud, so the page has to be coded in a way the screen reader can interpret. Above all, that takes correct HTML.
Keyboard operability links two of these groups. Screen reader users navigate with the keyboard, and so do many users with motor impairments. A page that only works with a mouse locks both of them out.
Where the Requirements Come From
The key requirements are set out in the Web Content Accessibility Guidelines (WCAG), the international standard for accessible digital applications. Alongside them is the European standard EN 301 549. To find out whether a product is accessible, you measure it against these criteria.
In Germany, the push for accessible development has mostly come from legislation so far. Federal public bodies have been required to make their digital products accessible since 2021.
Since June 2025, that obligation has reached further. Through the European Accessibility Act, implemented in Germany as the Barrierefreiheitsstärkungsgesetz, private companies have to make their digital products accessible too. For existing products, the obligation applies by 2030 at the latest.
The goal should go beyond compliance. Treating accessibility as a normal standard that is part of the plan from day one is a better mindset than reacting to a legal requirement.
Accessibility Belongs in the Process, Not at the End
The most common mistake is to finish building the application and then send it off for accessibility testing. In the worst case, the result is a hundred-page test report, and large parts have to be rebuilt. That is not how it should work.
The better approach starts early. A style guide defines colors and color combinations, and that is already the place to check whether the contrast is sufficient. A pattern library with buttons, dropdowns and select elements can be built so that each component is accessible from the outset.
When developers then use these patterns, accessibility carries over automatically. The effort is spread across the whole process instead of piling up into an unaffordable mountain at the end.
Accessibility Testing: What Automation Can and Can’t Cover
Test automation is a good way to get quick results, but it only covers part of the criteria. A Deque study of more than 13,000 pages that were tested both manually and automatically found that roughly 57 percent of the issues found can be detected automatically. More than half, but far from all.
Checks with a clear expected value automate well:
- Contrast ratio between text and background
- Presence of alternative text
- Correct heading hierarchy (H1, H2, H3 properly nested)
- Whether an element’s role matches its element type
- Correct HTML
Automation hits its limit when meaning comes into play. Whether an image has alternative text at all is easy to check. Whether that text matches the image and tells a blind user enough is something automation can hardly judge. That takes a human.
On top of that, an automated test rule often covers only part of a WCAG criterion. The final assessment still needs a human eye. A good starting point is an open source tool such as axe-core, which can be added to the pipeline with little effort.
Gray Areas Call for Experience
Many requirements have no simple pass or fail. A sensible reading order or simple navigation are examples that are open to debate.
When two experienced testers test the same object, one may find the navigation coherent while the other would swap two or three steps. That is not a defect. It comes with the subject. There is no fixed yardstick that says: this is good enough.
The reason is the diversity of users. What is easy for one person feels cumbersome to another. Making an application one hundred percent right for every single user is not possible.
No Tester Can Replace Real Users
When it comes to usability, there is no way around the people affected. Screen reader users are the experts in using their tool. A screen reader is powerful, and mastering all of its controls takes extensive training.
Testers can spot major problems and evaluate a lot in advance. But for real-world usability, it pays to involve a blind user and ask specific questions: Does it work like this, or would another way be better? That is how you get the most viable solution.
Tests Follow the Familiar Pattern
Accessibility tests can be evaluated like any functional test. The requirements from WCAG and EN 301 549 are turned into test cases that are executed and marked as passed or failed.
Where a test case fails, there is a barrier. It gets documented and summarized in a test report at the end. The only difference is the gray areas mentioned above: if a test case asks for a sensible reading order, the tester’s judgment decides.
Accessibility Is a Competitive Advantage, Not Just an Obligation
Teams often approach the topic as a chore. It costs budget, time and people, and staff first have to learn the subject. The counterargument lies in the benefits.
Accessibility improves usability in general. Contrast is a good example: everyone reads text with sufficient contrast more easily and more quickly than text that makes you squint.
“Every one of us reads a text with sufficient contrast much more easily and happily than one where you have to squint just to make out what it says.”
(Myria Pflaum)
The other benefits reach beyond any single user group:
- More users reached, and in the end more revenue.
- A positive image, because a company invites all users to use its application.
- Better search engine optimization as a side effect of accessible content.
- Access to public tenders: public bodies have to offer accessible products and are required to demand the same from the software they buy. Companies that already have an accessible product can bid right away and have a better chance.
Where to Start When It All Feels Like Too Much
WCAG is extensive. WCAG 2.2 has 86 success criteria, each described in detail. Reading all of it at once is more overwhelming than helpful. There are easier ways in.
A spot check gives you a first sense of where you stand. For a large website, have experts test two or three pages. The effort is manageable, and the basic problems are identified quickly and can be fixed.
At the same time, automated tests are a good way to start internally. They don’t cover everything, but they give you early feedback. Once the issues they can detect are fixed, you have taken a solid step in the right direction.
The third building block is training: step by step, developers, designers and testers learn what an accessible implementation requires. Over time, the topic becomes part of the normal development process.
Where the Field Is Heading
Two developments will shape the coming years. The European Accessibility Act has applied to new products since June 2025 and will cover existing products by 2030 at the latest. That raises awareness and should also reach the private sector, which will see the competitive advantage once usability and visibility measurably improve.
The second push comes from AI. It could make more success criteria testable automatically and interpret existing ones better. Alternative text shows the direction: in the future, an AI could judge whether a text matches its image without a manual test.
Frequently Asked Questions
Why Is It Not Enough to Base Digital Accessibility on a Single Type of Disability?
People with disabilities are not a homogeneous group: disabilities manifest in various ways, and the assistive technologies they use differ. In practice, it is helpful to categorize users into five groups: blind users, users with visual impairments, users with motor impairments, users with cognitive impairments, and users with hearing impairments. Some requirements apply across all groups. Keyboard accessibility affects both screen reader users and users with motor impairments. If a page works only with a mouse, it excludes both groups.
Who is legally required to ensure digital accessibility in Germany?
Federal government agencies have been required to make their digital products accessible since 2021. Since June 2025, the European Accessibility Act, implemented in Germany as the Barrierefreiheitsstärkungsgesetz, has also applied to private companies. For existing products, the requirement takes effect no later than 2030. The impetus for accessible development thus usually comes from the law, although treating accessibility as a matter of course would be the better approach.
Are automated tests sufficient to demonstrate digital accessibility?
No. A Deque study of more than 13,000 pages tested both manually and automatically found that only about 57 percent of the issues found could be detected automatically. Tests with clear target values are easy to measure: contrast ratio, presence of alternative text, heading hierarchy, and correct HTML syntax. Automated testing does little to assess whether an alternative text matches the image’s content and is meaningful to a blind user.
At what stage of the development process should accessibility be considered?
As early as possible. The most common mistake is to finish developing the application and only then submit it for accessibility testing. In the worst-case scenario, this results in a hundred-page test report, and large parts of the application have to be rebuilt. A better approach: check color combinations in the style guide for sufficient contrast and build a pattern library whose buttons, dropdowns, and select elements are already accessible.
Why do two experienced testers evaluate the same application differently?
Many requirements don’t have a simple “passed” or “failed” outcome. A logical reading order or simple navigation are examples that are open to discussion: one tester might consider a navigation structure coherent, while another might swap two or three steps. This isn’t a flaw in the method but stems from the diversity of users. There is no fixed standard here.
Can experienced testers replace the involvement of users with disabilities?
No, not when it comes to usability. Screen reader users are the experts in using their tools, because mastering all the operating options requires extensive training. Testers can identify major problems and evaluate many aspects in advance. When it comes to actual usability, it’s worth asking a blind user directly: Does this work this way, or would it be better done differently?
What are the benefits of accessibility beyond legal requirements?
It improves overall usability: Everyone finds it easier to read text with sufficient contrast than text that makes you squint. In addition, it reaches more users (which leads to increased revenue) and fosters a positive image, better search engine optimization as a side effect, and access to government contracts. Public agencies must also require accessibility when procuring software; those who already offer it can bid directly.
Where should a team with no prior experience in accessibility start?
Not by reading through the entire WCAG: WCAG 2.2 comprises 86 success criteria described in detail. It makes more sense to start with three building blocks. A spot check, in which experts review two or three pages of a large website, quickly reveals the fundamental issues. Automated tests provide initial internal feedback. Training gradually equips developers, designers, and testers with the necessary skills.
