Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:
WebAIM Million Report 2023
In March, WebAIM published their annual accessibility report. A number of well-informed folks have read the report and written articles with their key takeaways.
Manuel Matuzović picks up on one figure in his post, “50.1% empty links“. The number of websites containing links with no text (usually when linking an image that lacks alt text) has risen by 0.4%. He tests out various screen readers on an ’empty link image’ and documents the result, which is universally garbage, albeit with some differences.
Manuel concludes that you should “test your sites at least with an automatic testing tool like axe, Lighthouse, or Wave, and label linked graphics. I’ve described several ways in “Buttons and the Baader–Meinhof phenomenon.”“.
In “We need accessibility action“, Eric Eggert goes deeper. He notes that WebAIM’s tests are all automated (and test home pages only), so show us trends but only find a subset of accessibility barriers. Highlights:
- Average errors per page went slightly down (to 50). 96.3% of all pages have easily detectable WCAG failures – this is down 1.5% in four years.
- ARIA usage has increased a lot, and “pages that use ARIA are more likely to be inaccessible”.
- 96.1% of all errors are in one or more of the following categories:
- Low contrast text
- Missing alternative text for images
- Empty links
- Missing form input labels
- Empty buttons
- Missing document language
- As noted on the report itself, “Addressing just these few types of issues would significantly improve accessibility across the web.”
Eric finds these figures “embarrassing”. These WCAG requirements are not new – they’ve “all been around since WCAG 1.0” which is now 24 years old. For 96% of websites to still have issues underlines the need for “better strategies to educate people about the issues”.
Eric suggests that browsers themselves could fix some issues – “a ramp built into a train will generally be more available than a situation where every stop needs to provide its own”. Mitigation for low contrast text could be built into the browser, for example.
Other errors, like empty links and lack of alt text, really require developer intervention – and Eric argues that such errors should be highlighted in the browser’s console error messages. “There is no reason why JavaScript programming errors trigger messages, and accessibility issues do not. Tooling is bizarrely oblivious to accessibility.”
As for ARIA: “essential ARIA functionality must be transferred into HTML. ARIA needs to be a specialist tool that you only get out if you don’t have any other options. Many of the ARIA techniques are very intricate and for 90% of developers they should never be exposed to that kind of complexity and power.”
Eric concludes that the release of WCAG 3 won’t necessarily help. We have standards already, and people are unable or unwilling to follow them. “In the best case, web accessibility will drag on. In the worst case, we will have multiple standards to follow that have entirely unique ideas of how to test and measure accessibility”.
Interview with Jamie Knight (and Lion)
This landed in my inbox only recently (despite being published in April last year). I remember Jamie from my days at the BBC, so it’s always nice to find out how people are doing!
Jamie has autism and mobility issues. Denis Boudreau interviewed Jamie about the accessibility of virtual and in-person events.
One of the worst things speakers can do to ruin an attendee’s experience is to make assumptions. Jamie is “semi-speaking” and an unexpected demand to speak can be difficult – so don’t assume someone can speak at a moment’s notice. Another assumption is that someone can move. Jamie needs a harness to sit upright, “so for that reason, a 10-minute ‘break’ often means sitting alone for 10 minutes as that’s not enough time to unstrap, transfer and move anywhere”.
The rest of the interview is largely focussed on how speakers can help their audience to focus. Visual structure for slides is important: “slide numbers, visually indicated sections (colours, icons etc), and coming back to something consistent at the end of each section”. This allows audiences to pace themselves and follow the narrative. Most people will be relying on at least two of three means of access: spoken words, visuals, and something textual or signed. Finally, events should “be joyful. The most engaging accessible content treats any topic in a playful way”.
Jamie ends with “Assumptions are the root cause of most barriers. If you keep on top of the assumptions, then most of the barriers can be avoided.”
Don’t use custom CSS scrollbars
Eric Bailey writes a comprehensive article on why you should never, ever provide custom styling for your website’s scrollbars.
The post begins somewhat philosophically: Eric highlights the area of a browser window that is your responsibility (the web page) and then highlights what isn’t (the browser ‘furniture’, URL display, and yes, the scrollbar).
But it’s more than just ideological – people who use Windows themes or Forced Colors Mode / High Contrast Mode may be doing so for aesthetical reasons or because they have accessibility requirements. By overriding their choices, you’re potentially excluding them from being able to use your scrollbar. Windows, Eric reminds us, is incredibly popular – something that developers using shiny MacBooks can sometimes forget.
It is possible to set scrollbar width to 1px – the browser won’t stop you. This is obviously a bad idea. Eric’s point is that by taking on styling for the scrollbar, you’re taking on its WCAG requirements too. It’s now on you to ensure it has a large enough touch area, a high enough contrast, and so on. Eric evaluated a number of scrollbar-code-generators and none of them accounted for this stuff.
Modifying a scrollbar’s visuals breaks external consistency. “Digital literacy is also a spectrum. When digital things don’t look or behave the way they are expected to, people tend to internalize it as a personal failure—they broke something, they’ve been hacked, they’re being spied on, etc”.
Eric’s key takeaway is “maybe you should write less code and in doing so allow more people do more things”.
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.
