Frontend developer Jess Budd shares five things they’ve learned from user testing with screen reader users.
- “None” of the users interviewed used the tab key as their primary means of navigation – perhaps unlike the way many of us do manual testing! They’d typically bring up a list of all links or headings instead, and jump straight to the interesting bit.
- When asked to navigate to the homepage, none of the interviewees used the company logo in the top left corner, as most sighted users would. Instead, they searched for a link announced as “Home”. Side note: the alt text for the company logo should describe the functionality of the link, rather than the image itself, i.e. “Home” instead of “YourCompany”.
- Many of the users, upon bringing up a list of links, would type a letter to narrow the list down, e.g. “c”, looking for the contact page. So if your company has gone for more informal language, e.g. “Get in Touch!”, it will make it harder for screen reader users to find what they’re looking for.
- None of the interviewees made their browser window full screen. By default, the browser window only took up a portion of monitor space, giving the mobile styling and behaviour. We can’t assume people are experiencing our desktop layouts just because they’re not on a mobile.
- None of the interviewees use skip links. They have other, more efficient means at their disposal, and they say that skip links often don’t work well because it doesn’t always change the keyboard focus. This is one of those cases where skip links are often more useful for sighted users, even if we might be tempted to think otherwise.
This article has been in my bookmarks since the Pixel 7 launch event on October 6th, 2022. Google announced “a number of features” including:
- Guided Frame, which is a “voice coach that will tell users where to hold their phones in order to, for instance, take a selfie”. It directs you to move the phone up, down, or to the side, and automatically triggers the shutter when the AI believes you’re in shot.
- True Tone, which is the result of Google teaming up with photographers and artists of color “to help ensure that photos are accurate and representative of everyone’s skin tone”.
There is actually a different standard for authoring apps: the Authoring Tool Accessibility Guidelines (ATAG). This “seemed like the obvious choice”, but the tool doesn’t create “web content” as defined by the WCAG. WCAG defines web content as HTML or PDF or similar, whereas Sanity stores the content as data.
ATAG also doesn’t come with an evaluation methodology like the WCAG Evaluation Method (WCAG-EM), and doesn’t map to VPAT (“a format used to compare accessibility in the US and Europe”). Therefore, they decided to evaluate against WCAG Level A + AA, following WCAG-EM.
Other complications included deciding the scope of the audit. For a highly customisable application that can accept lots of plugins, how far do you evaluate? They opted for a minimally customised and representative site that they use for client demonstrations.
The end result was an audit covering 50 Success Criteria, of which 36 were satisfied. The remaining had issues identified, which is a “list of opportunities to improve accessibility in the Studio”.
The article ends with a link to Collaboration Tool Accessibility User Requirements, which is a W3C working draft of guidelines for making real time collaboration more accessible.
Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.