week11y issue 109

Your (almost) weekly frequent11y newsletter, brought to you by @ChrisBAshton. Advance warning: I’m on holiday next week, so the next edition will appear on Friday 25th March!

Giving a damn about accessibility

A useful resource for advocates, created by accessibility professional Sheri Byrne-Haber in partnership with UX Collective.

The handbook (PDF – 13.3 MB) is beautifully illustrated throughout its 49 pages, and covers the different ‘people challenges’ you will face as an accessibility advocate, and how to overcome them:

  • People who are allergic to change. There’s little you can do about these.
  • People who want to see the “business case” for accessibility. Their request is irrelevant: people with disabilities should not need to produce a business case to get an organisation to do the right thing.
  • People who want to see detailed proof for every accessibility recommendation. Your first step should be to prove that WCAG applies to the inaccessible product.
  • People who prioritise the creation of inaccessible new features over making old features accessible. Classic example: the Twitter ‘audio tweet’ “fiasco” (which I covered in dai11y 28/08/2020).
  • People who believe “it only impacts a small number of users”. Sheri equates this attitude to “the moral equivalent of pickpocketing”: supporting an environment where inaccessible tools are generated.
  • People who don’t believe that disabled people are part of the target demographic of their product. This is a “circular logical fallacy” as if people are excluded from using your product, they’ll never start to become your customer.
  • People who brought you accessibility overlays. I’ve covered overlays a fair bit already.

The second half of the handbook is more broad. I’ve picked out some highlights:

“[Organisations should] reward employees for releasing accessible software, not just making their deadlines with whatever they hurl over the fence”.

“Perfectionism is a bad approach to accessibility”. Every moment you wait for ‘perfect’ increases the length of time people have to continue using an inaccessible product. “Your first attempt at making anything accessible will be awful – but even awful is better than 98% of what other people are doing”.

Accessibility is not a ‘project’: it requires ongoing commitment, best done in a continuous process improvement feedback loop.

Sheri praises design systems for building in accessibility that spreads throughout the software. And she recommends implementing an accessibility ‘release gate’, which sets the expectation from the beginning that only accessible software will be released.

“Good accessibility professionals speak at accessibility events. Great accessibility professionals speak at design events”. Talk accessibility at an a11y event and you’re preaching to the choir; talk accessibility at a design event and you’re preaching to a lot of “non-believers”.

This was a quick skim, but the whole handbook is worth a read, and doesn’t take as long as you’d think!

Overlay Position and Recommendations

The International Association of Accessibility Professionals (IAAP) has published a statement outlining its position on controversial accessibility overlay widgets/plugins. This can be referred to as an authoritative position on the subject, alongside other community efforts such as https://overlayfactsheet.com.

It is a short statement, so worth reading fully in its own right. But here are a couple of highlights:

[IAAP acknowledges] “the deceptive nature of marketing claims that a single addition of a line of code… provides full compliance with web accessibility standards, mandates, regulations, or laws currently.”

However, it is noticeably more open to the technology than other resources I’ve read. For example:

“IAAP recognizes the importance of automating functions related to accessibility and that artificial intelligence (AI) and other emerging technologies have great potential in improving accessibility. IAAP calls upon Overlay providers to engage with advocacy groups and the broader accessibility community to ensure that Overlays are developed and implemented in a way that improves access to websites and applications.”

Place Your Bets: How Accessible Is PokerStars VR?

Accessibility advocates from Equal Entry rated the accessibility of the popular VR game PokerStars VR. The article highlights a couple of articles written by the participants in this area, covering 360 video audio descriptions (which I covered in dai11y 01/01/2021) and VR from a deaf person’s perspective.

The group recall being immediately dropped into a public space, without any training, and being a bit overwhelmed by being approached by strangers before they’d had a chance to orient themselves.

One of the group, Meryl, is deaf, and had to pull her goggles up to check the Google Meet captions and chat box. In doing so, she kept accidentally turning off her goggles.

Holding cards, and picking up poker chips, was difficult, even with full mobile dexterity.

It’s not all bad news though: when testing the game in greyscale, the team noted that the poker chips had their value in text, and card suits have different symbols, so the game doesn’t rely on colour alone to denote information. It did note that the hearts and clubs are in the same shade, however, and would perhaps benefit from two different shades.

The group concluded with some recommendations for PokerStars VR. The game needs:

  1. Addition of subtitles
  2. Ability to change size and contrast of text
  3. More use of haptic, alongside visual/audio feedback
  4. Controller remapping
  5. Display settings (e.g. brightness, contrast)
  6. Several improvements to controlling movement/locomotion/rotation

Are we live?

Scott O’Hara dives deep into ARIA live in this technical post, detailing all the different ways of implementing a live region that inform screen readers that something has updated:

  1. You can use specific ARIA region roles: alert, log or status
  2. You can use aria-live, with one of the following states: assertive, polite, off
  3. You can use HTML’s native output element, which has an implicit ARIA role of status

A common use case is the ‘notification’ design pattern whereby a message appears at the top of the screen. Developers often inject this notification into the page on an as-needed basis, but this doesn’t work very well for screen readers other than VoiceOver. The best approach is to ensure an empty live region exists on the page from the beginning, and then inject notification text into it.

The ARIA working group are apparently reviewing and planning to make big updates to live regions in ARIA 1.4. This is still a way off, as ARIA 1.2 is still only a W3C Candidate Recommendation Draft.


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.

Loading...