Chris Ashton

week11y issue 138

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

EA shares more accessibility patents

Electronic Arts – the games developer – unveiled its “accessibility patent pledge” in August 2021. Its purpose is to “create a collective” among games developers, to improve accessibility for disabled players. It originally shared 5 patents through the pledge:

  • “Contextually Aware Communications Systems in Video Games”
  • “Systems and Methods for Automated Image Processing for Images with Similar Luminosities”, which helps address colour vision deficiencies
  • “Contrast Ratio Detection and Rendering System”: a system that automatically detects and updates subpart contrast rations
  • “Personalised Real-Time Audio Generation Based on User Physiological Response”: technology that plays personalised music based on a user’s hearing issues.

In late 2022 they added 6 more:

  • A “machine learning system for improving a player’s experience and performance by automatically recommending and applying (if approved by the player) controller configuration settings based on the player’s specific gameplay style, skill and tendencies”
  • “Haptic feedback sequences to communicate to a player both the content displayed on a screen and how to select each item”
  • Two patents related to improving voice-controlled features
  • Tech providing a virtual joystick “that moves based on the position of the player’s thumb on a touchscreen”
  • A smart colour-blindness patent that adjusts gameplay depending on the player’s condition

Finally, EA has open-sourced Fonttik, a tool which “automatically identifies text in video content and determines whether it meets specified size and contrast ratio criteria, making it easier to ensure that the text can be read by players with varying vision conditions.”

Do we need an Interop for assistive technologies?

Hidde de Vries writes about Interop 2022: a collaborative initiative shared by the major browser vendors to solve the 15 top browser compatibility issues. These include areas like cascade layers, CSS color spaces, scrolling behaviour, and so on.

Hidde would like to see an equivalent of this but focussed on accessibility. He asked on Twitter what the top bugs in assistive technology are. Responses included: display properties (still) break default semantics, the HTML video player has accessibility issues in various browsers, aria-controls is not properly supported by screenreaders, the expanded state of details/summary is not communicated to users of screenreaders in Firefox if the arrow is hidden, and aria-owns is not supported in Safari.

Developers often try to ‘use the platform’ and assume their work will be accessible as a result. The result is that their work is either not accessible like they think it is, or they end up having to add some hacks and workarounds to fix pre-existing accessibility issues.

Hidde hopes the W3C’s ARIA-AT Community Group might be a suitable equivalent to Interop. It works on interoperability by writing tests (ensuring alignment between how assistive technologies behave and what users expect), running the tests across different assistive technologies, building consensus in the industry and enabling scalable automated testing.

How to Create an Accessible Progress Bar With React

I always find it interesting to read tutorials on how to write a commonly needed component, in an accessible way. This tutorial doesn’t do a great job of explaining the purpose of each line of code, but it’s fairly straightforward to follow.

The progress bar <div> is given a role="progressbar" (see the MDN page on the progressbar role), with additional attributes of aria-valuenow={progress}, aria-valuemin={0} and aria-value-max={100}. The <div> contains a <span> which also outputs the progress in text form.

A bit of React syntax crept into the above paragraph ({} as opposed to "" for the attribute value interpolation). The tutorial goes on to show how to use styled components to render the progress bar width.

The final result can be rendered like <ProgressBar progress={50}/>. The article doesn’t go into detail on how you should define the ‘progress’ value – that’s an implementation detail that presumably varies too much between use cases.

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.