Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!
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.
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!
US Accessibility Lawsuits
There have been a number of accessibility related lawsuits in America of late. As ever, I’ll try my best to summarise, but bear in mind I am no legal expert.
On Reconsideration, Judge Albright Transfers AudioEye, Inc. v. accessiBe Ltd. In December 2020, AudioEye accused accessiBe of infringing 9 patents, as well as committing false advertisement. The lawsuit has dragged on since then on the basis of where the case should be heard. It was originally filed in the Western District of Texas (WDTX), but accessiBe requested that it is heard in New York (WDNY) instead. After initially declining, the Judge has now agreed to transfer the case to WDNY; the article goes into details on why.
As Refining harm in Web Accessibility cases: Harty v. West Point Realty describes, New York is the most popular district court to process ADA web accessibility cases. In this West Point Realty case, the plaintiff attempted to visit the hotel’s website but “couldn’t discern from the room description whether the accessibility features in the hotel room meet his needs”. This allegedly violates the Department of Justice’s 2010 ADA regulations that require hotels to “identify and describe accessible features in the hotels and guest rooms offered through its reservation service“.
However, in such cases, the plaintiff must demonstrate that the violation brought them harm, something author Ken Nakata summarises as the “no harm, no foul” rule. It’s clear that the plaintiff would suffer a real harm should they book the hotel room believing that it is accessible, and then can’t navigate their wheelchair into the bathroom. But Ken doesn’t believe this lawsuit will succeed on the basis of “emotional injury” alone.
The final case I’d like to look at – also centred in New York – is Early Win for Deaf Plaintiff in VR Captioning Lawsuit. In 2020, Dylan Panarra, who is deaf, filed a lawsuit against the HTC corporation, arguing that they violated the ADA for failing to include captioning in their virtual reality content (housed on their subscription service “Viveort Infinity”). The case is still ongoing, and is the first known case about virtual reality captioning, so is an important one to keep an eye on.
Adrian Roselli shares a JavaScript bookmarklet which turns your cursor into a 24 by 24 pixel square.
It is designed to test the new Understanding Success Criterion 2.5.8: Target Size (Minimum), which will be introduced in WCAG 2.2 (currently draft). The criterion specifies that “the target offset is at least 24 CSS pixels to every adjacent target”, to “help ensure targets can be easily activated without accidentally activating an adjacent target”.
Adrian adds a disclaimer that, as this is a new SC, it is still in flux and may not even be a square when done. Follow the GitHub discussions for updates.
This is a short article that’s well worth a quick read. Google’s Search Advocate John Mueller says, in an office-hours hangout recorded on March 25th, that accessibility plays no part in Google search ranking. In other words, an accessible site is no more likely to be ranked higher in search results than a less accessible one.
The underlying reason for this is measurability: no automated tools can give a true evaluation of accessibility, though there are things like Google’s own Core Web Vitals which provide some automated ways of measuring accessibility.
Google already considers the mobile-friendliness of a site in the search ranking, which helped encourage companies across the world to invest in responsive. It feels like there’s a real opportunity here to make businesses value accessibility more by making it a search ranking factor. But for now at least, this isn’t on Google’s roadmap.
Article by @bramus, discussing the new CSS Toggles Unofficial Proposal Draft, alongside the demo site for the proposed feature.
“CSS toggles are a mechanism for associating toggleable state with a DOM element”. Perhaps this is best summarised in a code example:
html {
toggle-root: lightswitch; /* Create a toggle named lightswitch. It will cycle between 0 (inactive, default) and 1 (active) */
}
button {
toggle-trigger: lightswitch; /* When clicking the button, toggle the lightswitch */
}
html:toggle(lightswitch) {
/* Styles to apply when the lightswitch toggle is active */
}
This should make it much easier to define global toggles such as dark/light mode, applying reduced motion, switching to low data modes, etc, allowing us to apply the necessary styles without relying on JavaScript.
For now, this is just a prototype, and is subject to change. To start using this today, you’d need to use the polyfill.
Rachel Zemach writes about some of the frustrating encounters she’s had, as someone who became Deaf at the age of 10 (and had already learned to speak). Her speech is indistinguishable from someone who is not deaf, and she can ‘lip read’, which is problematic, as we’ll discuss below.
Incidentally, I’d come across the term ‘Deaf’ (with a capital D) before, but wasn’t quite sure when it should be used. Rachel links to an article describing the difference, which essentially comes down to whether or not the subject sees their deafness as an identity; a community that shares a mutual culture and language. Hence Rachel “became Deaf” at the age of 10, and “someone who is not deaf” refers simply to the medical definition of hearing loss. But I digress…
Lip-reading is hard, and pretty inaccurate: “55% to 70% of English is not lip-readable because many sounds are made deep in the mouth or throat”. This makes Rachel’s encounters with waiters and the like all the more frustrating, when, upon realising Rachel can lip-read and speak, they push to communicate only in speech. This contrasts heavily with when Rachel is out with her Deaf friends, who can not or choose not to lip-read/speak, where waiters are far more willing to ‘pantomime’ gestures to communicate.
Rachel has concluded that she will try and avoid speaking in future. She finishes with a request:
If you’re a hearing person, please, when you meet someone who says they can’t hear you, take your cues from them. Do they want you to write what you have to say? Do they want you to take down your mask and speak slowly? Do they want you to pantomime? Deaf and hard-of-hearing people are the experts on how to communicate with them. Ask them openly and earnestly and respect their solutions, which they’ll undoubtedly have.
I came across this via Anselm Hannemann’s Web Development Reading List. The author, Taylor Hunt, goes into a lot of detail about why they chose a traditional website over a Single Page Application (SPA), for a recent project.
There are a lot of accessibility concerns to consider when building an SPA, including:
- Restoring scroll positions between navigations
- Focussing on the last-used element when going ‘back’
- Focussing on an appropriate element when going ‘forward’
- And all the other client-side gubbins: back/forward history buttons, double-clicks, timeouts, ‘CMD + Click’, etc…
But the bit that struck me the most was this guideline from the article. We should favour:
- Security even over accessibility (“downgrading HTTPS ciphers for old browsers isn’t worth letting credit cards be stolen”)
- Accessibility even over speed (“a fast site for only the able creates inequality, but a slower site for everyone creates equality”).
- Speed even over slickness (deliver a fast site rather than an unnecessarily fancy one).
The battle of security vs accessibility was something that struck me in my article, I Used The Web For A Day On Internet Explorer 8, where I was faced with the dilemma that certain sites forced TLS 1.1, and my browser was only capable of TLS 1.0. The sites’ security policies made them inaccessible to me, but I had to concede that this was probably the right call.
To audit the accessibility of its digital services, the Cabinet Office has signed a two year deal with Digital Accessibility Centre (DAC) – a non-profit organisation based in Wales.
Adding context to the deal, which Civil Service World values at £436,632, the article states: “Research conducted over the past two years, and published by the CDDO in January, found that about 99% of public sector websites contained accessibility issues representing a potential problem for users with physical or cognitive impairments – as well as a possible breach of the new regulatory requirements.”
Side note: DAC are not to be confused with Deque (pronounced “dee queue”), a leading accessibility organisation that also does accessibility audits. Not knowing how the latter was pronounced, I must admit I mixed up the two when I heard colleagues talking about their accessibility audits, and only recently clarified it in a work chat!
Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.