The process of documenting components Screen Reader (SR) accessibility can be broken up into the following steps:

Screen Reader is a part of assistive technology. It is a stand-alone application built especially for blind or visually impaired people. It allows them to navigate devices by verbalizing the content and providing basic navigation actions.

There is a variety of both paid and free SR on the market. Although there might be some differences in their navigation, they all serve the same purpose: allow users to navigate, drill in, and select the content.

SR is able to read internet browsers like any other software. It verbalizes website content by scanning the web tree and finding HTML elements. For example: if reader finds <select> HTML tag, it pronounces: Selected Value; Label; Component State; Component Role.

If you are interested to find more on SR accessibility read this article .

As mentioned before SR identifies interface components according to HTML tags. This might be a problem when it comes to WSR components. If we inspect WSR <dropdown/> component we will not find <select/> tags. In fact <dropdow/> is combination of <input/> and variety of <div/> elements. This is because WSR components are systematically built out of other components. Therefore SR might mislead visually impaired users by pronouncing the wrong component names.

Luckily, W3 Organisation provides the internet with ARIA Markup Language.

Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make web content and web applications (especially those developed with JavaScript) more accessible to people with disabilities.

It supplements HTML with additional attributes so that the Screen Reader might get an explanation of how to read certain elements.

There is a variety of ARIA tags used to cover all types of assistive technology. There is no need to know them all, but it’s important to understand the general idea of how SR accessibility is added to WSR components.

It is important to obtain basic SR navigation knowledge. Here are a couple of applications that come free with operating systems:

Once you learn the SR basics, you might need some practice. Websites of schools for blind people like Perkins School For Blind People provides a perfect playground for practicing your web navigation skills using SR.

Also, you might get some useful insights by observing how visually impaired people are using screen readers for web content. Here is an example.

The aim of this step is to find and adopt best practices for SR accessibility on the web. Therefore we recommend checking how the same component is red by SR in at least three different sources:

If the behavior of the same component is different across the sources, it is important to identify these differences. This might be done by comparing the SR sentence structure of each example. Finlay, you should be able to identify the behavior that might provide the most information for visually impaired users. Sometimes you might want to combine several behaviors together to provide the best experience.

Once you have determined components SR behavior it’s time to document it. The section describing SR Accessibility can be found in the Wix Style Spec template, right under the Keyboard Focus Effects section. There might be two ways of defining SR Accessibility in the specs:

As much as we try, it might be hard to step into someone’s shoes. Luckily there are accessibility specialists at Wix. Please contact accessibility@wix.com to discuss your specs and make adjustments if necessary.

TBD