In one of our latest healthcare projects, there was a focus on adhering to the WCAG’s and on screen reader accessibility. The dev team at Macadamian worked closely with a legally blind user as part of the development process and learned things we otherwise would have missed. Here are three mistakes you should avoid:
1. Not knowing your target screen reader
It takes a lot of time and work to satisfy the WCAG criteria (Level AA in our case), but if you REALLY intend to make your web app screen reader accessible, you must check how the intended screen reader(s) interprets it. There are several out there for various targets, all with their own bugs and quirks. If that doesn’t provide you with enough already, they each have their own settings as well, giving too many combinations to reasonably test.
Once you lock down what platform and screen readers will be used most commonly by your app’s users, it gets less overwhelming. Also, it’s good to check what the commonly-used settings of target screen reader(s) are, and set up your devices to match that.
2. Using HTML elements for the wrong purpose
This one sounds obvious and simple, and for the most part, it is! It’s common to find
<a> masquerading as
<button> or vice versa but to be friendly to your screen reader, it’s best to use those elements for their defined purpose. For cases where that isn’t possible, you can use the role attribute. Don’t forget to check any fancy custom components for how the screen reader handles them.
3. Adding aria-hidden to those fancy components
For something like a graph or complicated graphic, our instinct was to slap an
aria-hidden on it and move on. The issue with this approach is that all screen reader users are not completely blind. Somebody with moderate visual impairment may be using a screen reader to access your application, see your graph, and wonder why the screen reader does not mention it.
Instead, this technique works nicely:
- Present the data in a way that is easier for the screen reader. For example, a graph’s data could be represented by a table
- Place your screen reader-friendly component earlier (from screen reader point of view) on the page than the not-so-friendly component
aria-labelto indicate which component is the friendly one and which one is not friendly
This example demonstrates the technique.
<div class=”i-am-a-table” aria-label=”awesome information. Preferred access for assistive technologies.”></div> <div class=”i-am-a-graph” aria-label=”awesome information”></div>
If you found this helpful or have any other tips you think we should add, let us know in the comments below.
Insights delivered to your inbox
Subscribe to the dev blog to get the latest insights in IoT, Alexa Skills development, and software development.