Your fortnightly 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.
Better accessible names
Hidde de Vries shares some great tips for naming your labels and aria-labels:
- Describe what the thing does, rather than what it looks like, e.g. “Next slide” vs “Arrow right”
- Frontload the most unique part of the thing, e.g. in a list of albums, use “Midnight Marauders – Album” over “Album – Midnight Marauders”
- Be concise: 1-3 words is ideal
- Avoid roles, e.g. use “Close” instead of “Close button”, as the role will be announced by screen readers anyway
- Keep names unique, e.g. “See also: [name of page]” vs “Click here”
- Start names with a capital letter, and don’t end with a period – names aren’t sentences. This should lead to better pronunciation by screen readers.
Which fonts to use for your charts and tables
At first glance, this blog post looks like an advert for the website it’s hosted on: Datawrapper. But it’s packed with informative and useful content, and written by Lisa Charlotte Muth – so let’s dive in. Of course, due to the subject area, some of this will be quite subjective. Your mileage may vary.
The first recommendation is to use sans-serif typefaces as a general rule, as opposed to serif ones which are most useful for long texts such as articles. Sans-serif looks cleaner and is easier to skim. You can still use serif sparingly, such as for the chart title or labels.
Next, your font choice should have lining and tabular numbers. Lining numbers all have the same height, whereas ‘old style’ numbers go above/below the line (e.g. the ‘tail’ in the number 9). The picture in the article demonstrates this much more easily than I can describe! Similarly, tabular numbers all have the same width.
Going one step further, choose a multiplexed font: one where the height and width of each character is the same regardless of whether the weight of the font is bold. This can be useful for bolding a particular row in a table, whilst still making the table look neat. Bold, by the way, should be used sparingly, to emphasise things.
There’s a warning about ensuring your chosen font supports all the glyphs you need, such as characters for specific languages (ü ß é). And also a suggestion to choose a font that is not too wide nor too thin, though it then links to some well-known exceptions to the rule, so don’t take that as gospel.
Only at the halfway point is WCAG mentioned, followed by advice about ensuring your text is big enough and has a high enough contrast. Some specific sizes and ratios are given, if you’re unfamiliar.
Finally, there’s a note about using UPPERCASE text sparingly, and the often unwanted side-effect of said text becoming much wider than before. This can be corrected through a three step process: spacing out the letters more (called ‘tracking’ or ‘letter-spacing’), decreasing the font size to make it shorter, and then making the text bolder to aim for the same letter stroke width as the original text.
Giving your future self a little credit with progressive enhancement
This article alludes to the concept of technical credit, which is the antithesis of tech debt. It is the idea that putting in some effort now will make things easier on ourselves in future.
The article describes the difference between progressive enhancement and graceful degradation, and cites some useful statistics. Around 0.2% of users ‘opt out’ of the modern web by disabling JavaScript. But at least around an extra 0.9% face pages where JavaScript simply fails to load, for whatever reason. These figures are based on a 2013 study run by Government Digital Service. The author re-ran GDS’s experiment and put the figure closer to 3% of users for whom JavaScript doesn’t load.
The author underlines the fact that these are 3% of visits, not users – so the real figure of ‘how many users fail to get some of your JavaScript?’ is probably much higher. He visualises this with an animated gif of emoji faces, representing users on their journey on your site.
The article is full of thought provoking soundbites like “An escalator can never break… it can only become stairs”. Worth a read!
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.
