Manual accessibility testing means having people who rely on screen readers and Braille displays check whether a digital application is actually usable. Automated tests catch missing HTML attributes, but they can’t judge whether controls are used in a semantically meaningful way. Good accessibility and good front-end architecture go hand in hand.
Key Takeaways
- Poor accessibility is a direct sign of poor front-end architecture: teams that use good patterns and clean HTML structures often meet accessibility requirements as a side effect.
- Screen readers such as JAWS can make inaccessible desktop applications usable through pixel-based scripts, but any change to window size or resolution can break them right away.
- Accessible components in the style guide don’t guarantee an accessible application, because combining several components or implementing them differently can still break accessibility.
- Test automation can check whether an ARIA role is set, but not whether the semantic element makes sense for its purpose. That judgment call is left to manual testing.
What Makes Accessibility Testing Different
Accessibility testing checks whether an application can be used without seeing the screen, and it can’t be fully automated. A tool can detect whether a control has a role set in the HTML. It can’t tell you whether that role makes sense for what the control does.
That is where manual testing by people with disabilities comes in. Serdal Bilir works as an accessibility tester and consultant. He is legally blind himself and tests applications with the same tools he uses every day: a screen reader and a Braille display, which lets him read the screen content with his fingers.
The strength of this setup is experience. Someone who uses applications with a screen reader every day knows right away whether a workflow holds up or falls apart. In the tests he runs alongside development, Serdal no longer sticks strictly to predefined test cases. He works through the application based on experience and covers what matters that way.
Why Semantic Elements Make or Break Accessibility
A control has to do what it claims to be. A tab tells a screen reader user that the content is about to change. If a tab is actually used to jump to an anchor on the page, what it announces and what it does no longer match.
Serdal describes a case like this: a query form used tabs as jump links. The HTML contained a skip link that was presented to the outside as a tab. Sighted users never notice. For someone who hears or feels the output, expectation and reality collide.
The rule behind it is simple: use semantic elements that name their function correctly. No fake elements that look right but are declared wrong. That discipline is the foundation for a screen reader to convey an interface in a meaningful way at all.
Good Architecture and Good Accessibility Go Together
Clean front-end development and working accessibility are closely linked. Teams that use good patterns have a high chance of being accessible without extra effort. The reverse also holds: a poorly accessible application says a lot about how the front end was built.
The principle goes back to separating content and presentation with HTML and CSS, and it runs all the way through to how the interface is structured. The invisible grouping of elements is part of the architecture. Leave that structure out and the content arrives as plain text, which leaves the users who depend on the structure stranded.
René Matthäi draws a parallel to test automation. Controls that describe themselves, making it clear what they are and what they can do, help not only screen readers but any kind of automation. The same thing that makes a test stable makes an application accessible.
“If an application is extremely poorly accessible, that’s definitely an indicator of how the front-end development was done.”
(René Matthäi)
How Developers Learn What Using a Screen Reader Is Like
The fastest way to build understanding is a live demonstration. Serdal invites developers to his office and shows them his Braille display, which renders screen content in Braille. He also turns on the speech and Braille viewer in his screen reader, a built-in feature that shows sighted colleagues in a panel what he is hearing and feeling.
If meeting in person isn’t possible, he shares his audio in an online meeting so everyone can listen to the screen reader. Either way, understanding clicks at the same moment: as soon as someone hears the problem, it becomes real.
If you want to try this yourself, you don’t need paid software. Besides the commercial JAWS, there is NVDA, an open source screen reader whose name stands for NonVisual Desktop Access. You can download it and use it for your own tests.
Why Getting Involved Early Is Still the Biggest Problem
The two biggest hurdles are late involvement and a lack of basic knowledge in the team. Accessibility is on the project checklist, but in practice the first contact often happens shortly before go-live, when acceptance is due.
A better approach is an agreed way of working with fixed checkpoints throughout the project. That includes a shared understanding of which test steps will be done, which tools will be used and what the HTML has to look like. Most teams have a rough idea. Still, walking through the application together regularly brings aha moments.
A common misconception is about ready-made components. When a style guide team delivers input fields, tables and buttons as accessible components, project managers and developers expect the result to be accessible automatically. That is only true in theory. If components aren’t implemented exactly as intended, or several of them are combined, accessibility can still break.
The Missing Third Role: Why Testers and Developers Aren’t Enough
For good accessibility, a tester and a developer working as a pair aren’t enough. A role for UI design is missing. René describes a project with close, focused collaboration. Even there, changes made things worse in other places, and they only came to light because a second tester also went through the visual test steps.
What’s needed is someone who looks at the front end the way a business analyst would: How should this element behave, and how has it been solved in similar places in the application? Without someone holding it all together, decisions drift apart.
Direct collaboration between testers and developers still matters. A developer has to be there during testing, because only they know what’s needed technically. It took a long time to make that presence standard. Findings get noted and passed on directly instead of getting lost along the way.
Reporting Findings Without Reading the Source Code
Serdal checks controls through the HTML information without having to open the full source code. If the screen reader only announces “button” instead of naming what the button does, he puts focus on the element and pulls up its HTML details with a keyboard shortcut.
There he can see the role and the tag and whether the element has a label. If the label tag is missing, he reports that specific finding, and the developers add it. That is more targeted than digging through the full source code, because it goes straight to the affected element.
Web applications are much easier to make accessible than desktop applications. Even Office products aren’t accessible out of the box. They work because the screen reader vendor ships scripts and adaptations for them. You don’t notice in daily use, but there is an extra layer running in the background.
How Legacy Desktop Applications Can Still Be Made Usable
A desktop application that has grown over 20 years can be made usable even if it wasn’t built for accessibility. An application like this runs the core business of a public agency, has been carried along through every Windows upgrade and in some cases can’t even be operated with a keyboard.
The solution is scripts that adapt JAWS to the application. You lay a kind of template over the interface and tell the screen reader where each button is. This works with pixel information: at its core, it taps into the graphics card driver, meaning whatever the graphics card is currently putting out.
That pixel dependency is fragile. If the window size changes, the coordinates are off, and colleagues who rely on the screen reader report that something has stopped working. Maximizing the window often fixes it. A sturdier option is to give the screen reader an anchor instead of pixels, such as a button with a specific color, shading and content.
This mirrors the history of test automation, which also relied on coordinates before object recognition came along. Investing in accessibility also improves the conditions for stable test automation, and the other way around.
Two Tracks at Once: Better Applications and Better Assistive Technology
Accessibility needs a parallel strategy. On one side, the application has to actually work for the people using it. On the other, a web application should bring as much accessibility as possible on its own instead of relying on assistive layers in front of it.
The web community is debating overlays, meaning assistive layers placed in front of existing sites to make them easier to use, similar to a screen reader. Shifting the responsibility onto them alone causes two problems: the screen reader has a harder time than it needs to, and not every user has such a tool at hand or can afford one.
That leads to shift left. The more accessibility an application offers from the start, the less the assistive layer has to make up for. Self-help and training are part of it too, because people who can’t operate an application on their own fall back on workarounds. Some buttons react to neither Enter nor the space bar. In that case, you can tell the screen reader to move the mouse to the keyboard focus and simulate a click. Tricks like that are only known to those who have learned them.
Good Resources Make It Easy to Get Started
Accessibility is unusually well documented. The Web Content Accessibility Guidelines are written concisely for developers. You basically just have to read them and work through the sources.
For companies, the topic is getting more urgent because legal requirements are turning it from a special case into the norm. That obligation is one of the main pillars, even if nobody likes to wave the legal stick. It gives the topic attention it didn’t have before.
For project work, three levers remain central: reusable components, a consistent look and feel across applications and closer, earlier collaboration. The more consistently applications are built, the less friction there is for the people who use them without seeing the screen.
Frequently Asked Questions
Are automated testing tools sufficient to verify accessibility?
No. A tool can detect whether an ARIA role or an HTML attribute is set, but it cannot assess whether the semantic element makes sense for its intended purpose. This judgment call is best left to manual testing, ideally by people with disabilities who use the application with a screen reader and Braille display just as they would in everyday life.
What does poor accessibility say about the quality of front-end development?
It’s a direct indicator. Those who use good patterns and clean HTML structures meet many accessibility requirements without any extra effort. This principle ranges from separating content and presentation via CSS and HTML to the invisible grouping of elements: If this structure is missing, the content is delivered as plain text.
Why is it a problem when a control is something other than what it claims to be?
Because the label and the behavior don’t match. A tab signals to a screen reader user that the content is changing. In a query form, tabs were used as jump labels, and a skip link was rendered externally as a tab. Sighted users don’t notice this, but those who hear or feel the output are left in the dark.
Is an application automatically accessible if the components from the style guide are accessible?
No, that’s only true in theory. If components aren’t implemented exactly as intended, or if multiple components interact, accessibility can still break down. This fallacy is widespread: project managers and developers expect that using accessible input fields, tables, and buttons will automatically result in an accessible product.
When should accessibility testing begin in a project?
As early as possible, not just at the acceptance phase. In practice, contact often doesn’t happen until shortly before the go-live, even though accessibility is on the checklist. It makes more sense to establish an agreed-upon workflow with fixed review points and a shared understanding of which test steps are being performed, which tools are being used, and what the HTML code must look like.
Are testers and developers enough to ensure accessibility in a project?
No, there’s a missing role for UI design. In a project involving close collaboration, changes were made elsewhere that actually made things worse, and these were only noticed because a second tester reviewed the visual test steps. What’s needed is someone who views the front end like a business analyst: How should an element be designed, and how is it implemented in similar contexts?
How can old desktop applications that weren’t built to be accessible be made accessible?
Through scripts that adapt the screen reader to the application. You overlay a kind of template onto the software’s interface and tell it where each button is located, often using pixel coordinates derived from the graphics card’s output. This is fragile: if the window size changes, the coordinates are no longer accurate. More robust are anchors, such as a button with a specific color, shading, and content.
Can overlays and assistive technologies compensate for a lack of accessibility?
Only to a limited extent. If you shift the responsibility solely to upstream assistive technology, the screen reader faces more difficulties than necessary, and not every user has such a tool at their disposal or can afford it. That’s why “shift left” applies: The more accessibility the application itself provides, the less the assistive layer has to compensate for.
