Unfortunately, blind people are sometimes limited to browsing/consuming written content online. Things that sighted users do quickly and easily, like buying that plane ticket or posting content online, are incredibly complex and, in most cases, impossible for blind people. Most web and mobile apps are not designed or constructed with this in mind. Let’s change that by keeping the following things in mind 👍🏽
- All content must be presented in text or via a text equivalent (like images or other non-text objects should have alt text if they are not decorative) since screen readers cannot read non-text content (images, icons) directly. But they can read ALT text that you provide.
- All functionality must be available using only the keyboard. Even though most blind users can physically use a mouse or trackpad, they can’t see the mouse pointer.
- The content must use markup with good structure and semantics (headings, landmarks, tables, lists, etc.). Just like the “Table of Contents” on a Word Doc, screen reader users often pull up lists of headings, landmarks, and other semantic elements to help them understand what is on the page. They can also navigate by these elements (jump directly to the main content landmark, or to a specific heading). Always use a coherent order for each UI element on the page (Focus Order), and also do not forget to call out custom Landmarks.
- All custom elements that do not come native with the OS (like expand/collapse buttons, dialogs, etc.) must have the correct name/label, role (either with HTML or with ARIA), and value, and must change value when appropriate. Unlike native HTML elements, custom controls have no semantic parts natively, so screen readers can’t tell users what the element is and can’t update users on it properties unless you give them that information via ARIA, roles, states, and properties. This is the one teams get wrong the most. You can technically be compliant with the established guidelines, but if you fail or do a poor job here, your app is not really accessible. Try to use the native elements from the OS, as they provide most of what you need.
- Users must receive immediate feedback after all actions they take or if the system is doing something in the background (Live Regions), via their screen reader. Silence after doing anything is always bad
Although all of these things are primarily beneficial for blind individuals using assistive screen readers, keep in mind that drawing parallels with how we experience a Work Doc allows us to construct a more coherent information architecture for a page and/or task which benefits everyone. If the presented content makes sense in a word doc, you are on the right track.
