Design for the blind

If you ever had to describe a User Interface to someone over the phone, you know how frustrating that is for both. It is way easier to share a screenshot or do a screen share. However, if you are blind and using Assistive Technologies like Screen Readers (VoiceOver or TalkBack), this is your reality.

I recently prepared for the Web Specialist Specialist or WAS technical examination (a certification provided by the International Association of Accessibility Professionals (IAAP)), and I wanted to create a series of posts calling out some of the most profound things I learned — this is the first one talking about things to keep in mind when designing for “Audio-Structural Interaction UX.”

In their most raw form, apps are visually appealing and dynamic Word Processors. Something close Notion.

Try deactivating the CSS on your web app or site, for example…

Apple.com without CSS is just like reading a written document

Now, look at a typical Word Doc below. As a sighted user, you tend to navigate the document visually and read it in a particular and predictable order. Blind people navigate the content in very similar ways. However, they use Assistive Technologies that read the content and provide them with contextual cues on where they are in the “Document” and what they can do if their input is necessary.

Structure of an ordinary Word Processor like Google Docs.

Imagine trying to read a Word document with no headings, no hierarchy, or structure. The document would, in most cases, be impossible to understand. Imagine trying to book a flight in a document like this 😵‍💫.

In Summary

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.

I wrote a post about how to improve your Interaction Design Skills that is super related to this…

As a side note, keep in mind that you should consider many other things when designing and implementing for Audio-Structural experiences to make them not only compliant with guidelines but also inclusive and accessible. These are just suggestions that can get you close.

Let me know if you want me to create a more comprehensive walkthrough of how to design for Audio-Structural Interactions.

Stay safe,

Oscar.