Category: dai11y

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

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.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

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

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.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

Your daily 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.”

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

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

colorandcontrast.com

This is a very deep dive into colour, contrast, and how people differ in how they see things. It has interactive examples throughout, which really help to illustrate the concepts. Definitely one worth a bookmark.

It begins with the biology of the eye, before going into colour vision and visual impairments, and different vision effects. It then covers properties of colour (lightness and hue, but also chromaticity and chroma), the relationships between colour, the different colour models used in technology (RGB vs CMYK etc) and different ways of measuring contrast.

It ends with a chapter on light vs dark mode, and a chapter on user interfaces and data visualisations, which will be perhaps the most relevant sections to skim through.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

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

Swearing and automatic captions

Eric Bailey highlights the issue of how automatic captions deal with swearing. A number of providers automatically censor certain words, displaying a string of asterisks instead. There are lots of problems with this:

1. It’s nannying what a Deaf person should be hearing, creating a lack of equivalency in experience.
2. It undoes the speaker’s agency, “diluting the message they’re trying to communicate”. People get passionate, people swear, it is a deliberate act.
3. It wrongly assumes that captioning is only ever used in a professional or ‘business’ context.
4. It also asserts that all professional or business contexts should be swear free – why?
5. It creates confusion: the audience is left trying to figure out what the word is, and may even imagine a far ruder word than the captioning software was trying to save them from!
6. It falls victim to inaccuracy. Non-swear words get accidentally censored, whereas actual swear words get imaginatively interpreted (Eric cites “Titz”, a municipality in Germany).

Eric experiments with speaking specific swear words into a number of different applications that provide automatic captioning, e.g. Zoom, Google Meet and TikTok. The results were mixed – you can watch videos of each in the article. I particularly enjoyed the summary for Skype: “many swears were initially displayed and then replaced with asterisks, making the entire point moot.”

We then move onto ‘voice control’ technologies, such as voice access (a native Windows 11 feature). It censors (with asterisks) the swear words you’re transcribing – a disappointing outcome for inclusivity. Apple’s equivalent, Voice Control, doesn’t censor. Dragon Home censors by mishearing words, e.g. “shipped”.

Censoring swear words is kind of a default approach built into a lot of software. It’s often implemented with little thought, on the reasonable enough assumption that this is the correct, ‘safe’ approach, to avoid the risk of abuse of your product and/or reputational damage to your company. But there’s a serious accessibility issue at the heart of this, and Eric hits the nail on the head. Well worth a read.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

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

The 411 on 4.1.1

Adrian Roselli writes about WCAG SC 4.1.1: a 13.5 years old rule that first came out in WCAG 2.0. Roughly, it stipulates that content should have proper markup (elements only nested as per specifications, no duplicate attributes or IDs, etc).

One of the authors recently-ish filed a proposal to clarify the language, claiming that the original intent of the criterion was narrower than the current interpretation reflects. Moreover, it’s been argued that 4.1.1 as a whole should be deprecated now that browsers more predictably handle nesting, closing elements and duplicate attributes. It may disappear as early as WCAG 2.2.

Adrian goes into technical detail on why each thing covered by 4.1.1 is either no longer relevant, or considers where that thing might be better covered by other Success Criteria. He anticipates that the W3C will “come out with a clearer and better considered mapping for former 4.1.1 issues”.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

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

Giphy is adding alt text to make GIFs more accessible

Giphy is working with Scribely (a “content accessibility solutions provider”) to add descriptive text to its most popular animated gifs. It will be professionally hand written, not auto-generated.

Giphy is also planning to expose the alt text through its APIs, so that third party platforms can benefit from the alt text too. Twitter, for example, has a partnership with Giphy, so any Giphy content shared to Twitter might soon be more accessible.

It does seem a bit sad that we’re celebrating a major company beginning to recognise the importance of alt text as we’re entering into 2023. But a step in the right direction nevertheless.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

We’re fast approaching Christmas, and I have a gift for you. You can shape the future direction of this newsletter by filling in my survey! It would really help me to understand what you like or don’t like, which subjects you’d like to read more about, all that lovely stuff. All I Want for Christmas is You(r) thoughts on my newsletter – please fill it in! 🎄 Now on with the show…

A Guide To Keyboard Accessibility: JavaScript (Part 2)

In this second part of a two-part series, we move away from HTML and CSS and take a closer look at JavaScript.

The click event listener listens for a mouse click, but is also triggered by the Enter key (on buttons and links) and the Space key on buttons only. For other keys, you’d need to use the keydown event. This is often used for things like enabling the Esc key to close a modal. You can use keycode.info to find out which key code corresponds to the key you’re listening for.

Another important event is blur, which indicates that the element has lost focus. Combined with the keydown event, you can use this to add and remove a class on the given element, so that the state is wiped clean on each interaction and you can (for example) continually open and close a modal.

Next, we learn about the focus() method, which allows you to bring the keyboard focus to a particular element. It can be used with the preventScroll argument to ensure the browser doesn’t scroll as part of the interaction. There’s also a new focusVisible argument, which would prevent the focussed element from displaying its focus styling, but this currently only works in Firefox.

There’s a section on “roving tabindex“ which looks interesting – check out the demo. Sadly, the role="tab" and role="tabpanel" attributes are left unexplained, but there’s lots of detail about the actual JavaScript implementation.

The inert attribute mentioned in dai11y 15/12/2022 (intended for things like modals) gets a second showing here: the author talks us through how we should implement a modal at the moment (with inert not yet supported). We give it a role="dialog" and aria-modal="true" for screen reader, and a tabindex="-1" to make it programmatically focussable. Then, we create a function to open the modal, but need to keep track of which element opened it, as we’ll need to return focus to that element when closing the modal. The code looks something like:

let focusedElementBeforeModal;
const modal = document.querySelector("[role='dialog']");

const openModal = () => {
  focusedElementBeforeModal = document.activeElement;
  modal.hidden = false;
  modal.focus();
};

There’s some more detail about modals / focus traps and how to use the new inert attribute, towards the end of the article.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

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

A Guide To Keyboard Accessibility: HTML And CSS (Part 1)

This is a comprehensive run-through of a lot of the stuff you may already know: how different tabindex values affect keyboard behaviour, the new(ish) :focus-within CSS selector to be able to apply focus styles on a container element, the new (and not ready to use yet) inert attribute that promises to make modal dialogs much easier to implement, and so on.

There are some nuggets of handy tips and links to resources that were new to me though. Did you know that Firefox allows you to tab to any area that is scrollable (i.e. even if it isn’t a form control or link)?

There’s a reminder to not use outline: none in your CSS (to eliminate the element’s outline), as it is used by Windows High Contrast Mode. And, despite showing an example that demonstrates otherwise, we’re told to avoid wrapping <input> with <label> because it doesn’t work well with Dragon speech recognition software.

We’re warned against the use of display: contents, which effectively makes the element’s children direct descendents of the element’s container (i.e. the childrens’ grandparent), but “without losing semantics”. It’s an interesting concept, but one that is quite buggy, and best avoided. There’s also a section about CSS grid and flexbox, and the care needed to ensure that tabbing continues to be in a predictable order.

I liked the section about ‘skip links’ towards the end of the article. It reminds us that we can provide multiple skip links at the top of the page, e.g. to skip to main content, or to skip to a list of all articles. We can also apply skip links within content, e.g. if there is an embedded map in the page and it has lots of focussable elements, you may want to give the keyboard user an option of skipping over it.

Further reading: MDN web docs page demonstrating lots of different input types, so that you can try interacting with each one of them using your keyboard.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

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

HTMHell Advent Calendar 2022

Manuel Matuzović’s famous “HTMHell” site cites lots of examples of bad HTML practices, copied from real websites. See “button disguised as a link“.

Last year, Manuel created an ‘advent calendar’ of links to other sites, linking to articles about HTML.

This year, Manuel has enlisted the help of 24 authors from all over the world, to write and publish articles specifically for Manuel’s calendar.

Visit the calendar link above to see the articles published so far, or follow along on Twitter.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.