In digital accessibility, the team of accessibility specialists includes blind team members who exemplify the spirit of digital accessibility. These accessibility specialists also function as the internal simulator for groups doing accessibility testing and remediation.
Unlike most users, blind accessibility specialists can’t stop using the website or app when they encounter blockers. Their job is to find workarounds and report the details of each accessibility issue. What can they do when they encounter these scenarios? With a little patience, they can work around the problem to figure out the cause. But in some cases, it will call for asking a sighted colleague about the problem.
Here are the six most common barriers blind testers encounter and how they can work through them.
1. Improper focus management
Proper focus ensures blind users have the best user experience. When they’re navigating a page, they know where they are. The key is to ensure nothing takes away from this focus. For example, they activate a link or a button and an unexpected pop-up box opens. If the page does not announce the change, then blind users will think nothing has changed. They think they’re navigating through the original page.
The reality is the focus has changed from the page to the popup. The blind tester doesn’t know this. This will lead to confusion.
When improper focus happens, blind testers will need to double-check all the contents of the page from top to bottom. In doing this, they’ll look for whether something new appeared. An easier way is to ask for sighted assistance. This request signifies there’s a major accessibility problem.
2. Interactive elements are not conveyed as interactive
Interactive elements such as links and buttons are strong indicators that an action can be executed. When elements are not conveyed as interactive, this can confuse users. Also, they might miss crucial controls for completing an action.
To identify this problem, testers must go through the content from top to bottom to figure out what is interactive. They can do this by activating every single one to see what happens or gauging which of the labels seem actionable.
3. Selected state of elements not conveyed
Another vital component for digital accessibility is identifying the selected state of an element as soon as it’s selected. For example, links are announced as “current” and buttons are announced as “selected” or “pressed.”
This is most useful when filling out multiple forms with several different steps. The ideal way is to convey which among the steps is the current step. Similarly, this is also useful for paginations.
If the screen reader does not announce the state of an element, then study the content of the page multiple times and note any changes. This will help them verify whether an action occurred or the page refreshed.
4. Availability of sub-menus through mouse hover
This is one of the biggest blockers for screen readers. It’s commonly found in navigation menus. When a menu item designed with a sub-menu gets activated, the screen reader gives the wrong impression that nothing happened. Keyboard navigation won’t expand the sub-menu because it was designed to work with a mouse pointer.
Unfortunately, there’s no workaround for this hurdle during testing. The only thing to do is ask for sighted help and report this as a major blocker.
5. Visual icons without a text alternative
Universal icons like a trash bin or garbage can represent removing or deleting items. Similarly, triple lines or triple dots represent a “more” control meaning when you select them, you’ll get more options or a sub-menu. There’s also the gear icon that represents “settings.”
Like images, these icons should have alternative text. The screen reader will announce what the icon does. For sighted people, locating and identifying these icons is easy as one, two, three. No effort is needed. For blind users, it’s a different story when there’s no alt text associated with the icon.
If a person is a user with a screen reader, they will instantly quit browsing or navigating the page when they can’t locate controls. However, for blind people doing accessibility testing, it is crucial to ask for sighted help when these icons do not have text alternative labels.
6. Visual presentations without a text description
Similar to the previous point, charts and graphs need to have text descriptions. This is different from alt text used to describe images or icons.
When infographics, charts, and graphs don’t have text descriptions, then the only option is to ask for sighted help.
Other Scenarios
What about other scenarios such as color contrast in images and text, font readability (size, color, style, etc.), visual hover, how the site handles zoom, and other things that automated tests can’t identify? Can blind testers check for these?
“So my short answer is going to be no,” says Sam Proulx of Fable. ” If you can’t perceive the associated criteria, you can’t test it. You could use automated testing, but in that case, you’re not doing user testing: you’re just writing reports based on automated results. That’s why Fable prioritizes having testers who use different assistive technologies, and have different disabilities, test each product.”
There is no one-size-fits-all process on the journey to achieving digital accessibility and inclusion. User needs vary. This is where the role of the blind accessibility specialist comes in. They are in the best position to filter and catch some of the biggest accessibility issues.
Being a blind tester for accessibility requires patience but it’s a fulfilling career because they can prevent actual users from experiencing these barriers. They help create better user experiences.
Does Your Technology Need to Be Audited for Accessibility?
Equal Entry has a rigorous process for identifying the most important issues your company needs to address and we can help you address those quickly. Contact us to speak to us about auditing your digital product or website for accessibility.
Image by Mohamed Hassan from Pixabay
