Your fortnightly frequent11y newsletter, brought to you by @ChrisBAshton:
GOV.UK had discovered that in recent versions of screen readers, its contact form was too aggressive in announcing how many characters were remaining. This was despite the existing markup of aria-live="polite".
I’ve been keeping an eye on the GitHub issue for this, and a fix was merged recently. There are now three elements responsible for character count announcements:
- A static element: “You can use up to 200 characters”. This is visible for non-JavaScript users, and visually hidden otherwise.
- An injected, live-updating element showing the characters remaining. This has
aria-hidden="true" to hide itself from screen readers. - An injected, debounced element showing characters remaining, visually hidden and
aria-live="polite". It only updates after 1 second of inactivity, and only announces once the user has passed the threshold (if a threshold has been set).
This looked like quite a thorny issue to resolve – well done to the Design System team for getting it updated! I hope to see an official blog post on it soon 🤞
Interesting WebAIM threads
WebAIM (“Web Accessibility In Mind”) is a non-profit organization based at Utah State University, and is most famous for its annual accessibility analysis of the top million websites.
It also has an email discussion list, whereby anyone with an accessibility question can start a thread asking for advice. These next threads landed in my inbox recently, and looked pretty interesting:
First, Links within image captions. Jo wanted to check whether having links inside <figcaption> was an accessibility fail. The consensus seemed to be that it was OK.
Next, Links that open new windows and/or go off site: “do they need to have an icon or additional text?”. There was initially consensus that the absence of these would not be a WCAG fail, but on further sleuthing, the conclusion was that it would in fact violate SC 3.2.2 .
Finally, Accessibility a external content, in which Christopher wonders if there’s a material difference between linking to, and embedding, inaccessible content. The motivation for the question was that if people knew they needed to wrap captions around an embedded video that lacks them, but didn’t need to if simply linking off to the video, then people might decide to only use linking from now on. It led to an interesting discussion, but nothing conclusive.
Quick shout-out to edx.org, which is offering a free “Introduction to Web Accessibility” course. It takes an estimated 4-5 hours per week, for 4 weeks, to complete the course, but you can go at your own pace.
It covers WCAG, POUR, finding W3C resources, and how you can check pages for issues.
This is a video clip (5m28s) from the BBC’s Dragon’s Den. Rene and Andy Perkins have founded a company, CityMaaS, aimed at improving accessibility on the web. They’ve created a product, Assist Me, which they hope to see companies embed on their websites (at a subscription fee of £30 to £45 per month). Assist Me is a button that triggers a popup menu where the user can adjust font size, turn on a screen reader, etc. In other words, this is an accessibility overlay.
The investors didn’t probe into why accessibility overlays are bad, but did express that this sort of assistive technology should exist on the user’s machine so that it can be used on any website. The founders’ response was that this puts the onus (and expense) on the user, and is therefore wrong.
The company has a couple of other products but they didn’t get much airtime. The Mobility Map looked promising – a way of seeing the accessibility information of any public place. But it’s behind a paywall, which is disappointing, as I really think there’s a gap in the market for making it easier to find accessible housing.
None of their products look any good to me, but I do applaud any opportunity to raise awareness of digital accessibility issues on prime time TV.
Developer Aaron Stephenson has developed a free ‘Braille Scanner’ app for iOS, which allows you to take a picture of a paper Braille document, and it will convert it to text, using a combination of image processing and machine learning. It supports Unified English Braille grade 1 and does not currently read other types of Braille.
One use case would be for people who are learning Braille and want to double-check what they’ve written. Watch a video demonstrating how Braille Scanner works on Twitter.
Free events at AbilityNet
Kelly from the charity AbilityNet got in touch with me to let me know about some free events that might be of interest to frequent11y readers.
Training on Wednesday 4th May (10am BST): How to build a disability inclusive workplace. “Discover where your organisation currently sits on our disability inclusion gap analysis scale overall and at each stage in the employee lifecycle”.
Stefan Judis writes about the HTML inert attribute. When applied to a container, it renders all children inaccessible, i.e. you can no longer tab to or interact with any form elements within.
This will be super useful for properly implenting modal windows, such as a confirmation dialog asking if you’re sure you want to delete your account. With inert, you can ensure the user can’t tab away from the modal and continue to navigate around the page.
Browser support has been very poor, but that’s about to change. Stefan summarises:
Now, Safari Tech Preview ships it with v143, Chrome will enable the attribute with Chrome 102 in May and Firefox implements the feature behind the html5.inert.enabled flag.
PS: Stefan writes a fantastic weekly newsletter about web development – I suggest checking it out!
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.