Approaches for developing for screen readers often conflict with the approaches used for non-screen reader users. By identifying where those differences lie early in the project, and making often very slight additions to the development process, we can address the needs of both sets of users equally without any unexpected surprises come testing time.
Target Chrome
In their latest screen reader user survey, WebAIM has identified Chrome as the most popular browser for people to use with their primary screen reader, making up 53.6% of usage. In comparison, Microsoft Edge accounts for 18.4% of their screen reader usage, and Firefox only accounts for 16.5% of it (Source: WebAIM).
Skim Your Content Like A Screen Reader
Sighted users can skim your content visually by looking over your content and picking out your well designed headers, illustrations, links and navigation structure. Screen readers offer the same filtering by allowing users to tab through those items in a list format. This is why it's so important to follow WCAG standards when adding titles, subtitles and links. In fact, one of the quickest ways to test your accessibility is to use the screen readers Links list feature, which will create a list of all links on the page. You can then review that list to make sure your link titles make sense when read separately from the content. Similarly, use the Header list feature to ensure your titles and sub-titles are accessible.
Give Context To Your Tabbed Navigation
Tabbed navigation is a simple way to navigate a site sequentially for sighted users, but for visually impaired users it's tremendously confusing. You can fix that by simply adding screen reader only text to those links identifying the focused tabs location within the tab order. A selected tab in a 5 tab sequential navigation, for example, could read 'Current Tab 3 of 5'.
Skip Links For Duplicated Navigation And Content
Visually, duplicated navigation on each screen, including the main menu, quick links and footers, can provide a great amount of information instantly, but for screen reader users, it means listening to the same navigation over and again each time the page loads (or manually skipping the section, link by link). Fortunately, you can add Skip links for that content to give screen reader users the options to skip straight to the content area. It can be set up to only appear when using the keyboard to tab through the page.
Describe Your Charts, Graphs And Illustrations
Designers spend a lot of time creating charts and graphs that illustrate complicated information in a simple manner. For your visually impaired users, visual charts and illustrations provide little benefit. Fortunately, by including clear descriptions of the illustrations for screen readers, or providing the content in table form, we can make sure visually impaired users have access to the same content as your sighted users.
Bonus Tip: Expect Accessibility From The Very First Release
For the most part, accessibility should be built-in as a site develops. There's no need to go back and make content or links standard later, although some items involving dynamic alternative text may be done at a later time. Each release should be tested for accessibility or you'll end up with surprises, and unnecessary code rebuilds, at the end.
Although there are differences in developing for screen readers and non-screen readers, there's no need to treat them as completely separate development flows. Simple changes can solve most of the conflicts. Make sure you test screen readers on the right browsers to get relevant results. Keep code standard so both sets of users can 'skim' the content. Describe your navigation structure in context, and give your screen reader users the option to skip straight to the information they want. Give your screen reader users alternate content for those graphs and illustrations. When consideration is given to these conflicts from the start, you'll find simple tweaks are often all you need to give equal access to your screen reader users.
