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!

What would an ethical overlay look like?

• Karl Groves writes about the ‘overlay widgets’ offered by companies such as accessiBe, and how their claim that including their product on your website will make it fully WCAG compliant is simply untrue. Many a11y issues, such as missing alt text, can only be fixed by a person. Moreover, the extra features an overlay often provides (e.g. screen magnification) are poor imitations of what’s already available to the user on their computer. The only ‘ethical’ overlay is a temporary one, Karl says: it should only be used as a discovery tool to find accessibility problems, which you should then spend time fixing the root cause of.

Accessible Game Design / Accessible Player Experiences

• I came across accessible.games while watching the 2020 Video Game Accessibility Awards. It lists the basic “access design patterns” to follow when developing your games. Examples include “second channel” (such as captioning that alerts you to incoming attacks; not just relying on sound) and “improved precision” (allowing gamers to adjust sensitivity of mouse/controller input). There are also “challenge design patterns”, which are patterns to follow once you’ve got the basics sorted, which go beyond core access into the realm of inclusion, so that people can fully enjoy your game. Examples include “slow it down“, allowing gamers to adjust game speed or reduce enemy damage so that they can successfully progress through the game.

PlayStation 5: The Accessibility Review

Pros:

• The integrated screen reader is available across the PS5 system and comes in multiple languages, which can be adjusted for speed, volume, and choice of male or female voice.
• There are a number of global settings to accommodate different types of colour blindness.
• You can set a ‘game preset’ for game difficulty ranging from Easiest to Hardest, which should map to the standard options in most games. Similarly you can indicate a preference for subtitles, inverted controls, and audio language, which games should obey automatically.
• There are options to increase text size, and to remap your controller.
• 3D Audio, alongside supported headsets, give surround sound to the player, enabling blind players to pinpoint with accuracy where enemies are (as well as improving the experience for everybody).
• The new DualSense controller has a built-in microphone, which can be used for voice-to-text. Haptic feedback in the controllers is designed to immerse the player, but can be disabled if uncomfortable.

Cons:

• The controller is larger and heavier than before, and the accessible ‘Back Button Attachment’ accessory for the PS4’s controller doesn’t fit on this one.
• The ‘zoom’ option that allowed screen magnification on the PS4 has not yet been carried over.

Under-Engineered Responsive Tables

• Adrian Roselli describes how to create an accessible table that scrolls horizontally on mobile. You need to put your <table> element inside a <div role="region" aria-labelledby="mycaption" tabindex="0">, where “mycaption” references the <caption id="mycaption"> that should be inside the table. The tabindex satisfies WCAG Success Criteria 2.1.1 Keyboard, and the aria-labelledby satisfies 4.1.2 Name, Role, Value. For the CSS, apply overflow: auto to the table, and don’t forget to apply a focus style.

Accessibility Testing is like Making Coffee

• This article by Madalyn Parker was very popular back in August. Madalyn describes accessibility testing through different coffee brewing methods, with some nice illustrations. French Press is like automated testing: quick, easy, but doesn’t catch all of the grit. Aeropress, like semi-automated testing, is a step up from that, but requires more judgement. Pour Over is like manual testing, requiring the most time and attention but giving the smoothest brew. Going to a Café is like User Testing: you’ll learn things (either how to make coffee in new ways, or how users with disabilities use your site). a11y.coffee is kind of a sister site to this article and is also worth a look.

Survey of Web Accessibility Practitioners #3

• This WebAIM survey, which was previously conducted in 2014 and 2018, is aimed at “everyone that implements accessibility, whether casually or as a primary part of your job”. It is open until January 20th 2021 and its results will be published in the same month. Please take 5-15 minutes of your day to complete the 36 short questions and help inform the web accessibility field.

Introducing the Accessibility VRCs

• A blog post from Facebook’s Oculus team, describing ‘Virtual Reality Checks’ (VRCs), which are technical requirements all apps on the Oculus Platform must meet. It covers things like security, framerates, etc.
• There is now a set of Accessibility VRCs, which are unfortunately not requirements but “strong recommendations”. A 34m video, “Designing Accessible Experiences“, explains it in more detail.
• The actual Accessibility VRCs cover things like subtitle options, distance grabbing, head-tracking alternatives, in-game feedback & direction, colour blindness support, display setting customisation and controller reconfiguration. Each link describes how to manually test the requirement, and links out to a bit more implementation detail.

Almost 50% Got This #a11y Question Wrong! — WCAG Explained (8m video)

• Eric Eggert asked Twitter if the following code fails WCAG:
• <button aria-level="2">Action</button>
• 49% thought it failed WCAG, but Eric explains why it doesn’t. This all may seem a bit hypothetical, but it’s actually quite a useful exercise in how to judge code against the WCAG criteria.
• Eric admits the code is invalid ARIA, as buttons can’t have levels (level doesn’t appear on the button role documentation, nor does button appear on the aria-level docs), but that does not constitute a WCAG failure.
• It doesn’t fail SC 4.1.1 Parsing, as the HTML can still be parsed. SC 4.1.2 Name, Role, Value also passes; it says that “states, properties, values that can be set by the user can be programmatically set”, but as aria-level is unsupported on the button element, it cannot be set by the user.
• Eric explains a couple more WCAG criteria that people cited, and why they don’t apply. Worth a watch.

My watch told me I have a leak

• An AbilityNet article describes how Google’s Live Transcribe app, which turns speech into text for live conversations, can also be trained with non-voice data. An update to the app can now identify environmental sounds such as “crying baby”, “door knocking”, “smoke alarm”, or as the title suggests, “running water”. The app can vibrate or flash for these noises, and Google announced in October 2020 that it will soon be able to notify your Android watch (Wear OS), though the ‘listening’ will still be done through a nearby phone. The next step will be to bring environmental noise detection natively to any devices that contain a microphone.

A plan for accessible maps

• Benjy Stanton describes how he would design a map service from the ground up, considering the needs of all users. Maps are inherently inaccessible – they require digital and geographic literacy as well as visual methods of communication, so they should always be seen as an enhancement. Benjy’s tips can be largely summed up as follows:
• The core content should be available outside of the map, e.g. as a data table or downloadable spreadsheet. Design your map in black and white first, to help prevent you relying on colour alone to convey meaning. Avoid pan & zoom interactivity unless they’re required. Ensure all interactive features (rivers, roads etc) are high contrast enough to see. Turn off background layers you don’t need. Test the map works on mobile and with a keyboard.

Here’s What It’s Like To Live With A Tracheostomy

• Ginny Butcher describes her experience of living with a tracheostomy (or ‘trache’): a tube in her neck, connected to a ventilator to enable her to breathe.
• She’s completed a master’s degree to become a lawyer, and has done many impressive things such as rock climbing, abseiling, canoeing and zip lining, all with a ventilator strapped to her body. She’s also flown a plane and completed a half-marathon.
• The practical aspects are that she needs to carry three bags of machines and some spare batteries at all times. One of the machines is to assist with coughing and secretions. The tube needs changing daily, which Ginny likens to something as boring as “clipping your toenails”.
• It has its upsides too – Ginny doesn’t breathe through her nose or mouth, which makes her “the absolute best at downing pints”. Worth a read!

Accessible Web Animation: The WCAG on Animation Explained

• Val Head gives a detailed overview of WCAG animation recommendations. These include:
  • “Pause, Stop, Hide“: provide a way of pausing, stopping or hiding any autoplaying animation that lasts more than 5 seconds.
  • “Three flashes or below threshold“: avoid flashing more than 3 times in a one second period, to reduce chances of triggering seizures.
  • “Animation from interactions“: any animation triggered by the user, which gives the illusion of motion (so not including things like colour or opacity change) should have an option to be disabled, as they can cause people with motion sensitivities to become ill. You can implement this with a ‘toggle’ on your site, and also pay attention to the prefers-reduced-motion media query.
• These recommendations come under different WCAG conformance levels. for example, the first two rules are level A rules – the bare minimum standard to be met. The “animation from interactions” rule is AAA, which is the highest level of conformance. In general most people aim for the middle level: AA compliance.

More Accessible Skeletons

• Adrian Roselli describes – quite late on in his blog post – why he thinks skeletons (placeholder areas to display to the user while content is loading) are a bad idea. But he also describes how he would build one if he had to.
• Some skeletons have aria-busy="true" markup, which is designed to be temporarily ignored by screen readers, though few screen readers support it. Adrian recommends pairing it with aria-hidden="true" for now at least. In practice, this means having two sibling nodes; one for the skeleton and one of the content.
  • When your content is loading, it should be hidden and have aria-busy="true", and the skeleton node should be visible. When it has loaded, it should be flipped to aria-busy="false" and the skeleton node should be set to aria-hidden="true".
  • You should have CSS which sets display: none on aria-hidden content, and on aria-busy="true" content.

How we made GOV.UK more accessible

• A team on GOV.UK analysed a small subset of representative pages to identify any violations of the WCAG 2.1 AA standard. They prioritised each issue by its regularity / likelihood of occurrence and its impact on the user’s ability to use GOV.UK. These were either technical issues, content issues or a mixture. They could generally be fixed in one central place (the Design System or components) or by an improvement in the guidance. There’s a great video on how differently marked up tables are experienced by screen readers.

iPhones can now automatically recognize and label buttons and UI features for blind users

• iOS 14 has a new feature, “Screen Recognition”, which is built into VoiceOver. It uses AI to detect interactable elements on the screen, even when such elements aren’t properly labelled / exposed to assistive technology. It has the potential to allow blind users to use apps that are otherwise inaccessible.
• I highly recommend this GadgetHacks article which goes into more detail on the feature and includes screenshots demonstrating how to enable it.
• I haven’t had a chance to try out the feature myself yet, but it looks as though you first enable the feature, then ‘opt in’ to the feature on individual apps. I don’t yet know whether that means it would work on browsers such as Safari and Chrome. If it does, this could be a game changer, as it might allow the user to navigate previously inaccessible websites.

Are your Anchor Links Accessible?

• Amber Wilson describes the HTML structure she came up with for turning headings into ‘linkable headings’, whose links can be used as anchor links to that specific part of the page. It can be tricky to implement these without making it a noisy or confusing experience for screen reader users. Here is the markup she ended up with:
• <h2 id="introduction">Introduction</h2><a href="#introduction"><span aria-hidden="true">#</span><span class="hidden">Section titled introduction</span></a>
• You could also wrap your link inside your heading, which is simpler but arguably has usability issues (e.g. makes it harder to select heading text):
• <h2 id="introduction"><a href="#introduction">Introduction</a></h2>

A placeholder is not a label

• This is your regular reminder from HTMHell that <input type="text" placeholder="First name"> is not accessible and requires an associated <label>. Some screen readers will fall back to using the placeholder if a label is missing, but it can’t be relied upon.
• There are various UI issues with a placeholder-only approach. Contrast is often too low to read the text easily (though this can be tweaked by styling with the ::placeholder rule, at the risk of making the user think the input is already filled in). Placeholders get cut off if the input is too small, and get removed as soon as you start typing, straining your short term memory.

Alexa Makes Shopping Lists Sharable as Accessibility Feature

• Alexa allows you to create lists such as shopping lists and todo lists, adding and removing items with your voice. And now, users can ask Alexa to send a given list to a specific contact. Once Alexa confirms it has identified the right person, the recipient gets a message on their Alexa account through the app. This feature is designed to help those with limited access to a grocery store connect with those who can help get them supplies in the ongoing COVID-19 situation.

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.