Your fortnightly frequent11y newsletter, brought to you by @ChrisBAshton:

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.

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.