Testing accessibility with those affected

Accessibility testing means testing digital applications for real usability by people with screen readers and Braille displays. Automated tests recognize missing HTML attributes, but cannot assess whether control elements are used in a semantically meaningful way. Good accessibility and good front-end architecture correlate directly.

Key Takeaways

• Poor accessibility is a direct indicator of poor front-end architecture: If you use good patterns and clean HTML structures, you often automatically fulfill accessibility requirements.
• Screen readers such as JAWS allow non-accessible desktop applications to be made usable by pixel-based scripts, but this means that any change in window size or resolution can break the function immediately.
• Accessible components in the style guide do not guarantee an accessible application, because combining multiple 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 is logical for the respective purpose. This judgment step is reserved for manual testing.

What makes accessibility testing different from normal testing

Accessibility tests check whether an application can be used without visual perception, and they cannot be fully automated. A tool can recognize whether the role of a control element is set in the HTML. It does not say whether this role is logical for its purpose.

This is exactly where manual testing by affected users comes in. Serdal Bilir works as an accessibility tester and consultant, is legally blind himself and tests applications with the same tools that are used in everyday life: a screen reader and a Braille display that makes the screen content readable with the fingers.

The advantage of this constellation lies in the experience. Anyone who uses an application with a screen reader on a daily basis knows immediately whether a process is working or not. Serdal no longer works strictly according to predefined test cases in its development accompanying tests, but goes through the application according to experience and covers the essentials.

Why semantic elements determine success

A control element must do what it claims to do. A tab signals to the screen reader user that the content is changing. However, if a tab is technically used to jump to a marker, there is a contradiction between announcement and behavior.

Serdal describes such a case: A query form used tabs for jump labels. A skip link was built into the HTML, which was displayed externally as a tab. This is not noticeable for sighted users. For someone who hears or feels the output, the expectation collides with reality.

The rule behind this is simple: use semantic elements that name their function correctly. No fake elements that fit visually but are incorrectly declared. This discipline is the basis for a screen reader being able to convey an interface in a meaningful way at all.

Good architecture and good accessibility are connected

Clean front-end development and functioning accessibility correlate strongly. Those who use good patterns have a high chance of being accessible without additional effort. Conversely, a poorly accessible application is an indicator of how the frontend has been worked on.

The principle goes back to the separation of content and form via CSS and HTML and continues through to the structuring of the interface. The invisible grouping of elements is itself a component of the architecture. If this structure is omitted, the content is delivered as pure text, and users who rely on this structure will not be able to cope with it.

René Matthäi draws a parallel with test automation. Self-labeling control elements that make it clear what they are and what they can do not only help screen readers, but also any form of automation. The same requirement that makes a test robust makes an application accessible.

If an application is extremely poorly accessible, then this is definitely an indicator of how the front-end development was handled. René Matthäi

How developers put themselves in the shoes of a visually impaired person

The quickest way to understand is through direct demonstration. Serdal invites developers into his office and shows them his Braille display, on which screen content can be displayed as Braille. He also switches on the speech and Braille viewer in the screen reader, an onboard tool that shows sighted colleagues what they are hearing and touching in a bar.

If an on-site meeting is not possible, he shares his sound in an online meeting so that the participants can listen to the screen reader. In both cases, understanding changes at the same point: as soon as someone hears the problem, it becomes tangible.

If you want to try this out for yourself, you don’t need any paid software. In addition to the commercial JAWS, there is also NVDA, an open source screen reader whose name stands for Non-Visual Desktop Access. It can be downloaded and used for your own tests.

Why early integration remains the biggest project problem

The two biggest hurdles are late integration and a lack of basic knowledge within the team. Accessibility appears on the project checklist, but in practice contact is often only made shortly before go-live, when acceptance is due.

It makes more sense to have an agreed working mode with fixed reunion points throughout the project. This includes a common understanding of which test steps will be carried out, which tools will be used and what the HTML code must look like. A basic idea is usually there. Nevertheless, when going through the application, aha moments regularly occur.

A common misconception concerns ready-made components. When a styleguide team delivers input fields, tables and buttons as accessible components, project managers and developers expect the result to be automatically accessible. This is only true in theory. If components are not implemented exactly as intended, or if several components come together, accessibility can still be broken.

The third party involved: why testers and developers are not enough

For good accessibility, the duo of tester and developer is not enough, there is a missing role for UI design. René describes a project in which there was close and focused collaboration. In the process, things were improved elsewhere that only became apparent because a second tester also checked the sighted test steps.

As a result, there is a need for a person who looks at the front end like a business analyst: How should an element be, and how is it solved in comparable places in the application? Without this bracket, decisions will diverge.

Direct cooperation between testers and developers is still important. A developer must be present during testing because only they understand what is needed technically. It took a long time to establish this presence. Findings are noted and passed on directly instead of disappearing via detours.

How findings can be reported without reading source code

Serdal checks control elements via the HTML interface without having to open the entire source code. If the screen reader only reads out “switch” for a button instead of naming its content, it focuses on the element and retrieves the HTML information using a key combination.

There it sees the role and tag and recognizes whether the element has a label. If the label tag is missing, it names the specific finding and the development adds it. This is more targeted than looking at the complete source code because the affected element is examined directly.

Web applications are much easier to access than desktop applications. Even Office products are not inherently accessible. The fact that they can be used is due to scripts and adaptations supplied by the screen reader manufacturer. This is not noticeable in everyday use, but there is an additional layer running in the background.

How old desktop applications can still be used

A desktop application that has grown over 20 years can be made accessible even if it is not accessible from the ground up. Such an application represents the main business in the office, was upgraded with every Windows change and in some cases cannot even be operated using a keyboard.

The solution is scripts that adapt JAWS to the application. The screen reader is given a kind of template over the interface and told where each button is located. This works via pixel information; in essence, the graphics card drivers are tapped, i.e. what the graphics card is currently delivering.

This pixel reference is fragile. If the window size changes, the coordinates are no longer correct and affected colleagues report that something is no longer working. Maximizing the window often helps. A more robust alternative is to give the screen reader an anchor instead of pixels, such as a button with a certain color, shading and content.

This development is reminiscent of test automation, which also used to rely on coordinates before object recognition came along. Investing in accessibility also improves the conditions for robust test automation, and vice versa.

Two paths at the same time: strengthening the application and improving assistance

Accessibility requires a parallel strategy. On the one hand, use must actually work, while on the other, the web application must provide as much as possible on its own instead of relying on upstream assistance.

In the Internet world, there is discussion about overlays, i.e. upstream assistance functions that are intended to make existing services easier to use, similar to a screen reader. If the responsibility is shifted to this alone, two problems arise: The screen reader gets into more trouble than necessary, and not every user has such an aid to hand or can afford it.

This leads to the Shift Left principle. The more accessibility an application provides from the outset, the less the assistance layer has to compensate. Self-service and training are part of this, because if you can’t operate an application yourself, you have to make do with workarounds. Some buttons do not respond to either Enter or the space bar, in which case the screen reader can be instructed to drag the mouse to the keyboard focus and simulate a click. Such tricks are only known to those who have learned them.

Where good sources make it easy to get started

Accessibility is a topic with unusually good documentation. The Web Content Accessibility Guidelines are concisely prepared for developers, you basically just have to read them and navigate through the sources.

The topic is becoming more urgent for companies because legal requirements are turning it from a special case into a standard. This obligation is one of the main pillars, even if nobody likes to swing the legal club. It gives the topic attention that it didn’t have before.

Three levers remain central to project work: Reusability of components, a consistent look and feel across applications and closer, earlier collaboration. The more consistently applications are structured, the less friction there is for the people who use them without visual perception.