Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:
Candidate recommendation version of WCAG 2.2 published
September 6th 2022 marks the first update since May 2021. According to w3.org:
A Candidate Recommendation is a document that satisfies the technical requirements of the Working Group that produced it and their dependencies, and has already received wide review. W3C publishes a Candidate Recommendation to signal to the wider community that it is time to do a final review [and to] gather implementation experience.
The document is considered complete and fit for purpose… No further refinement to the text is expected without additional implementation experience and testing; additional features in a later revision may however be expected.
You can see the announcement on Twitter, which links to a page summarising what’s new in WCAG 2.2. One of the interesting ones is Success Criterion 3.2.6 Consistent Help, which has an example of a site’s ‘help chatbot’ feature that should be accessed in a consistent way, e.g. from a button on the bottom right corner of the page.
SC 3.3.7 Accessible Authentication suggests giving users ways of logging into services via an email link, for those that don’t use password managers and find it difficult to remember their passwords. And a niche one, SC 3.3.9 Redundant Entry, requires that if users have to enter the same information again in the same process, the app should auto-fill the information rather than make the user re-type it.
Thanks to David Cox for bringing news of the WCAG update to my attention.
Preparing for the physical world through the digital
Two articles caught my eye recently.
In Ipswich station gets virtual tour to help passengers with accessibility requirements, we learn how Greater Anglia has launched an online tour of Ipswich rail station. It uses 360 degree photography to allow people to explore the platforms, the waiting room, and the toilets. There’s also an ‘autopilot’ tool allowing customers to select their destination location within the station and be automatically guided to it.
The aim is to reduce anxiety about getting around, to help people to plan their journey in advance, and to help people confirm whether or not the station facilities are accessible to them. It’s been developed with technology from The Virtual Tour company and with the help of feedback from Greater Anglia’s Accessibility Panel.
A dozen of Greater Anglia’s busiest stations are now covered by the technology, including Cambridge, Harlow Town, Stansted Airport and Norwich.
The next article is Lanarkshire charity shop launches new tool WelcoMe to improve accessibility for disabled customers.
WelcoMe is a website where customers can share with venues their access needs, anticipated arrival time and reason for visiting, for the best possible chance of an accessible and welcoming experience. The site also gives the shop team training in how to best meet the needs of the customer.
Improving accessibility with accessibility acceptance criteria
A GOV.UK blog post from 2018, describing GDS’s use of ‘acceptance criteria’ for accessibility testing.
These criteria are more specific than general WCAG guidance, and concentrate on specific checks to make at the component level for specific components. For example, GDS’ accessible autocomplete component must:
- be focusable with a keyboard
- enable the user to navigate the available matches using touch or keyboard
- inform the user when a match is selected
- inform the user which number the currently selected match is – for example, 1 of 3 (optional)
- inform the user if a match is pre-selected
- …and so on
These criteria are a way of recording decisions made early on in development, and provide a sense check against making breaking changes when iterating the component in future. They also serve to raise awareness of accessibility issues from the start.
To write criteria such as these, start with accessibility needs by identifying where there is a high risk of introducing an accessibility barrier, and documenting how to prevent it. The hard work has often already been done in the WCAG guidelines, so extract rules pertaining to what you’re building, and link back to the guidelines for context.
Criteria are most useful when they’re specific and testable. Don’t be too generic. Also avoid defining the solution; describe an outcome instead.
Continue to refine your criteria over time, e.g. when encountering bugs, add further criteria and treat them like a failing unit test.
Are you enjoying my newsletters so far? It would really mean a lot to me if you could share it with any colleagues or friends who may be interested! They can subscribe in a few seconds by visiting https://ashton.codes/subscribe-to-frequent11y/.
Mac VoiceOver Testing the Simple Way
Scott Vandehey writes about a familiar problem: getting comfortable testing with VoiceOver. It’s an experience that can make new users feel, as he puts it, “overwhelmed”.
The first issue is with enabling VoiceOver; Scott could never remember the CMD + F5 keyboard shortcut. On newer MacBooks, Scott recommends triple-clicking the TouchID button instead, which is the shortcut for opening the Accessibility Shortcuts panel, from which you can enable VoiceOver.
To avoid having to go via the panel, you can also go to System Preferences -> Accessibility -> Shortcut and uncheck everything except VoiceOver. This means triple-clicking the TouchID button will immediately enable VoiceOver.
As Scott only uses VoiceOver for testing, he uses the visual caption panel instead of listening to the speech, which he has muted by opening the VoiceOver Utility -> Speech -> Mute speech.
With VoiceOver configured, Scott’s approach to testing is to TAB through all the content on the page, which doubles up as a test that all appropriate elements are reachable and have focus styles. This approach commonly reveals issues with lack of context around interactive elements, e.g. a button that simply says “Menu”.
Next, Scott uses the Rotor to show a list of particular items in the page, such as headings and links. This is a useful way to check page structure and to ensure that all links have enough description.
Finally, using VO + →, Scott reads the entire content of the page. He acknowledges most screen reader users won’t do this, but it often brings up some little surprises.
Visit for a surprise
Eric Bailey raises the interesting dilemma of what link text you should provide on an ‘easter egg’ link to Rick Astley’s “Never Gonna Give You Up” YouTube video.
WCAG SC 2.4.4: Link Purpose (In Context) might indicate that you should let the user know exactly what’s at the end of that link. “YouTube: Rick Astley – Never Gonna Give You Up (Official Music Video), contains auto-playing media”, or such like.
Alternatively, you could go the other way and just have alt text of “Cryptic icon” and provide no clue at all, like sighted users would experience.
Eric picks out an example from the WCAG docs and emphasises the last sentence:
The word guava in the following sentence “One of the notable exports is guava” is a link. The link could lead to a definition of guava, a chart listing the quantity of guava exported or a photograph of people harvesting guava. Until the link is activated, all readers are unsure and the person with a disability is not at any disadvantage.
The goal is to preserve the author’s intentional act, which is to create a sense of curiousity.
Eric eventually lands on “Visit for a surprise, contains autoplaying media”, arguing that “Cryptic icon” does not provide the enticement, and that it is important to at least flag that there’s autoplaying media. Ideally, he says, sighted users should be warned of this too.
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.
