19 Apr

dai11y 19/04/2023 – How to use the accessibility tree for a11y testing

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

How to use the accessibility tree for a11y testing

Giovani Camara uses a simile to describe the accessibility tree’s relationship to the DOM as being like a ‘filter’ for your emails: the DOM contains a lot of information, but the accessibility tree shows only the data related to accessibility.

This article is very short – it describes how to access the accessibility tree in Chrome DevTools, which is to right-click, Inspect, click the double arrow in the bottom right panel and select Accessibility.

What’s more interesting is the embedded video (10m) where Giovani demonstrates this visually, and then goes on to show how he uses the accessibility tree as a development aid, by using it to examine the W3 WAI ARIA example implementation of tabs. He explains how to use it to see the computed properties, ARIA attributes and the child/parent relationships of a component.


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.

18 Apr

dai11y 18/04/2023 – What makes writing more readable?

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

What makes writing more readable?

A fantastic deep dive into how to write in ‘plain language’. The entire article is written in normal literary style, but every paragraph has a plain language equivalent adjacent to it, which you can toggle to switch to.

The interactivity of this article is a joy to play with and really helps to demonstrate the processes that go into translating text into plain language. We see Rebecca Monteleone’s thought process behind how she translated an example paragraph into plain language.

We then learn about the Flesch-Kincaid formula, which measures readability based on the length of words and sentences. It’s not hugely effective: “the dun fox cleared that slouch of a dog at full tilt” is at a 0.89 (1st grade) grade reading level, compared to the allegedly more difficult 2.34 (2nd grade) reading level for “the quick brown fox jumped over the lazy dog”.

The Dale-Chall Readability Formula considers the proportion of “difficult” words instead. This, similarly, isn’t all that effective. “The quick brown fox jumped over the lazy dog” is at 0.45 (4th grade or below) according to that formula, but drops to 0.25 (also 4th grade or below) by simply prefixing the sentence with “Yes!”.

Finally there is the Lexile Framework for Reading, which is a proprietary scoring system whose exact algorithms are unclear. But it oddly rates The Grapes of Wrath as far easier to read than The Library Mouse (32 page children’s book).

Formulas aren’t a great measure of ease of reading:

None consider how well organized the information is, or whether the sentences and paragraphs are coherent. None consider the role of grammatical tense. None account for the explanation of acronyms and jargon. None would balk at Jack Torrance’s rambling and meaningless draft in The Shining, endlessly repeating “All work and no play makes Jack a dull boy.”

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.

14 Apr

fortnight11y issue 73

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

HTML gains a <search> element

This one came up in the work chat.

On 24th March, the “WhatWG HTML living standard” gained a new <search> element. It is intended to be used to contain a set of form controls “related to performing a search or filtering operation”. Example code snippet:

<search>
  <form action="search.php">
    <label for="query">Find an article</label>
    <input id="query" name="q" type="search">
    <button type="submit">Go!</button>
  </form>
</search>

Functionally, it is the equivalent of using <div role="search">. The contributors that proposed it did not like the fact that this could only be expressed in ARIA (after all, the first rule of ARIA is to not use ARIA). See the original issue and the resulting pull request.

Quite what this means for browsers is hazy. WHATWG is a community with oversight from Apple, Google, Mozilla and Microsoft (i.e. the companies that build our browsers) so it should be supported in browsers at some point, but there is no clear timeline. See the WHATWG FAQ for details.


Building inclusive products for trans people

Chiara Angori shares some great tips for building products that don’t exclude your trans users.

Some are obvious, such as allowing users to specify their pronouns, and not asking users for their ‘title’ (Mr, Mrs, etc). Titles have no legal bearing and there’s almost never a good reason to ask for them. Even offering a get out option like “Prefer not to say” can be problematic, as some user research towards the end of the article demonstrates. Participants were worried that that option sounds “almost accusatory” and also that they were worried they’d be discriminated against for choosing it.

If asking for something sensitive like sex, e.g. in a medical context, offer three options (male, female and intersex) and provide details around why you’re asking for it. The article shows a screenshot of how the NHS app approaches this.

If you need to know a user’s legal name (or birth name), provide users a way to set their ‘preferred name’, so that trans individuals who have not yet changed their name legally can specify the name they should now be referred by. Give users options to keep their legal name confidential.

Consider enabling ‘discreet’ notifications, e.g. the Trans Memo app that helps trans people track their intake of hormones. This app enables users to replace notification text with something of their choosing, so that anyone who happens to see their notification on a lock screen etc won’t be able to easily understand what is being notified about.

Well worth a read.


Why Motion on Websites and Digital Content Is a Problem

Meryl Evans describes how at times she feels dizzy and light headed, in symptoms she describes as vertigo. 70 percent of deaf and hard of hearing children with sensorineural hearing loss have a vestibular disorder, which is also expected to affect “more than 35% of US adults aged 40 and older at some point in their lives”.

This demographic, alongside people who experience migraines, epilepsy, and general motion sickness, are sensitive to motion. It can be brought on by animated gifs, or background videos and slide shows on websites.

Meryl suggests giving viewers control over motion. Taking Twitter as an example, their accessibility settings have options to reduce motion and turn off autoplay. “When an image with the Play button shows up on Twitter, it’s either a video or an animated GIF. Select the image and it plays. Select the image again and it stops.”

Meryl touches on the “reduce motion” accessibility setting in operating systems, which I covered in more detail in dai11y 12/12/2022.


Sabbath mode and assistive technology features

Eric Bailey writes about the “secret mode that comes with almost all large ovens, refrigerators, dishwashers, and other large kitchen appliances”. Sabbath mode (or Shabbat mode) helps people to comply with Halakha (a body of Jewish religious laws), which forbids Jews from doing “work that creates” on Shabbat (the day of rest, Saturday).

For example, an oven can be set to Sabbath mode to keep food prepared ahead of time hot. The work to create the food and the heat to keep it warm is done outside of the bounds of the holy day.

Sabbath mode is not easy to activate: it “usually requires a very specific, non-obvious, and convoluted set of button presses”. Therefore, it is only used by those who know it exists: “activation is almost always a highly intentional act made by an individual whose background means they know the feature exists and uses it for a very specific purpose.”

Eric uses this as a metaphor for assistive technologies. Many accessibility features built into operating systems are obscure, known only by the people who rely on them. Not every Jewish person knows that Sabbath mode exists, and not every disabled person knows about or is comfortable using assistive technologies designed for their disability.

Eric concludes that it’s important to build accessible experiences by default, and not rely on your users to explicitly ‘enable’ accessibility (such as setting prefers-reduced-motion in a nested submenu somewhere on their OS). On the flipside, people who do set such modes have done so deliberately and rely on them, so don’t remove, override or subvert this functionality.


Addressing concerns about CSS Speech

Léonie Watson (better known online as Tink) writes about CSS Speech. In dai11y 25/11/2022, I covered Léonie making the case for CSS Speech. In this latest article, Léonie specifically addresses concerns raised by the community.

People who use screen readers are worried that CSS Speech could make their experience worse, not better. They’re currently in control of the volume and speed of the speech, and are worried that giving developers influence over this could make content more difficult to understand.

Léonie points out that the use case for CSS Speech is wider than just assistive technologies, and encompasses things like reader (read aloud) capability in browsers. With the wider audience, the default speech speed is likely to be too slow for the typical screen reader user.

Screen readers “have shortcuts that let you change the rate of speech on the fly”, which LĂ©onie claims screen readers often use already, e.g. slowing down the speech when reading a document that requires closer attention, before reverting back to normal speed.

Moreover, LĂ©onie quotes the CSS Speech module with regards to volume: values of x-loud vs x-soft are not intended to be dramatic or uncomfortable, but relative to your current volume level. There is an outstanding concern that the proposal allows a ‘Decibel offset’ from the chosen keyword, which could lead to more extreme volume changes, but LĂ©onie argues this option could be removed or refined further in the specification.

The “ultimate safeguard” is to ignore CSS Speech altogether, which will be possible in the same way as users can currently disable CSS globally. This isn’t ideal as not all screen reader users are blind and thus retaining visual styles is important.

The article ends with some synthesised speech samples that demonstrate the potential benefits of the module. It would be possible to configure things like news headlines to read with more impact, and the date of the news story to be announced in a more subdued manner. Listen to the demo.


removal techniques and implications

This CodePen by Vincent Valentin shows over a dozen different ways of hiding or removing content, and the implications of each for things like DOM access, keyboard access, pointer access and so on.

It’s a quick reference table that doesn’t go into detail about why you might want to use each method, but is a useful thing to bookmark nevertheless.


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.

14 Apr

week11y issue 146

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

Sabbath mode and assistive technology features

Eric Bailey writes about the “secret mode that comes with almost all large ovens, refrigerators, dishwashers, and other large kitchen appliances”. Sabbath mode (or Shabbat mode) helps people to comply with Halakha (a body of Jewish religious laws), which forbids Jews from doing “work that creates” on Shabbat (the day of rest, Saturday).

For example, an oven can be set to Sabbath mode to keep food prepared ahead of time hot. The work to create the food and the heat to keep it warm is done outside of the bounds of the holy day.

Sabbath mode is not easy to activate: it “usually requires a very specific, non-obvious, and convoluted set of button presses”. Therefore, it is only used by those who know it exists: “activation is almost always a highly intentional act made by an individual whose background means they know the feature exists and uses it for a very specific purpose.”

Eric uses this as a metaphor for assistive technologies. Many accessibility features built into operating systems are obscure, known only by the people who rely on them. Not every Jewish person knows that Sabbath mode exists, and not every disabled person knows about or is comfortable using assistive technologies designed for their disability.

Eric concludes that it’s important to build accessible experiences by default, and not rely on your users to explicitly ‘enable’ accessibility (such as setting prefers-reduced-motion in a nested submenu somewhere on their OS). On the flipside, people who do set such modes have done so deliberately and rely on them, so don’t remove, override or subvert this functionality.


Addressing concerns about CSS Speech

Léonie Watson (better known online as Tink) writes about CSS Speech. In dai11y 25/11/2022, I covered Léonie making the case for CSS Speech. In this latest article, Léonie specifically addresses concerns raised by the community.

People who use screen readers are worried that CSS Speech could make their experience worse, not better. They’re currently in control of the volume and speed of the speech, and are worried that giving developers influence over this could make content more difficult to understand.

Léonie points out that the use case for CSS Speech is wider than just assistive technologies, and encompasses things like reader (read aloud) capability in browsers. With the wider audience, the default speech speed is likely to be too slow for the typical screen reader user.

Screen readers “have shortcuts that let you change the rate of speech on the fly”, which LĂ©onie claims screen readers often use already, e.g. slowing down the speech when reading a document that requires closer attention, before reverting back to normal speed.

Moreover, LĂ©onie quotes the CSS Speech module with regards to volume: values of x-loud vs x-soft are not intended to be dramatic or uncomfortable, but relative to your current volume level. There is an outstanding concern that the proposal allows a ‘Decibel offset’ from the chosen keyword, which could lead to more extreme volume changes, but LĂ©onie argues this option could be removed or refined further in the specification.

The “ultimate safeguard” is to ignore CSS Speech altogether, which will be possible in the same way as users can currently disable CSS globally. This isn’t ideal as not all screen reader users are blind and thus retaining visual styles is important.

The article ends with some synthesised speech samples that demonstrate the potential benefits of the module. It would be possible to configure things like news headlines to read with more impact, and the date of the news story to be announced in a more subdued manner. Listen to the demo.


removal techniques and implications

This CodePen by Vincent Valentin shows over a dozen different ways of hiding or removing content, and the implications of each for things like DOM access, keyboard access, pointer access and so on.

It’s a quick reference table that doesn’t go into detail about why you might want to use each method, but is a useful thing to bookmark nevertheless.


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.

14 Apr

dai11y 14/04/2023 – removal techniques and implications

removal techniques and implications

This CodePen by Vincent Valentin shows over a dozen different ways of hiding or removing content, and the implications of each for things like DOM access, keyboard access, pointer access and so on.

It’s a quick reference table that doesn’t go into detail about why you might want to use each method, but is a useful thing to bookmark 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.

13 Apr

dai11y 13/04/2023 – Addressing concerns about CSS Speech

Addressing concerns about CSS Speech

Léonie Watson (better known online as Tink) writes about CSS Speech. In dai11y 25/11/2022, I covered Léonie making the case for CSS Speech. In this latest article, Léonie specifically addresses concerns raised by the community.

People who use screen readers are worried that CSS Speech could make their experience worse, not better. They’re currently in control of the volume and speed of the speech, and are worried that giving developers influence over this could make content more difficult to understand.

Léonie points out that the use case for CSS Speech is wider than just assistive technologies, and encompasses things like reader (read aloud) capability in browsers. With the wider audience, the default speech speed is likely to be too slow for the typical screen reader user.

Screen readers “have shortcuts that let you change the rate of speech on the fly”, which LĂ©onie claims screen readers often use already, e.g. slowing down the speech when reading a document that requires closer attention, before reverting back to normal speed.

Moreover, LĂ©onie quotes the CSS Speech module with regards to volume: values of x-loud vs x-soft are not intended to be dramatic or uncomfortable, but relative to your current volume level. There is an outstanding concern that the proposal allows a ‘Decibel offset’ from the chosen keyword, which could lead to more extreme volume changes, but LĂ©onie argues this option could be removed or refined further in the specification.

The “ultimate safeguard” is to ignore CSS Speech altogether, which will be possible in the same way as users can currently disable CSS globally. This isn’t ideal as not all screen reader users are blind and thus retaining visual styles is important.

The article ends with some synthesised speech samples that demonstrate the potential benefits of the module. It would be possible to configure things like news headlines to read with more impact, and the date of the news story to be announced in a more subdued manner. Listen to the demo.


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.

12 Apr

dai11y 12/04/2023 – Sabbath mode and assistive technology features

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

Sabbath mode and assistive technology features

Eric Bailey writes about the “secret mode that comes with almost all large ovens, refrigerators, dishwashers, and other large kitchen appliances”. Sabbath mode (or Shabbat mode) helps people to comply with Halakha (a body of Jewish religious laws), which forbids Jews from doing “work that creates” on Shabbat (the day of rest, Saturday).

For example, an oven can be set to Sabbath mode to keep food prepared ahead of time hot. The work to create the food and the heat to keep it warm is done outside of the bounds of the holy day.

Sabbath mode is not easy to activate: it “usually requires a very specific, non-obvious, and convoluted set of button presses”. Therefore, it is only used by those who know it exists: “activation is almost always a highly intentional act made by an individual whose background means they know the feature exists and uses it for a very specific purpose.”

Eric uses this as a metaphor for assistive technologies. Many accessibility features built into operating systems are obscure, known only by the people who rely on them. Not every Jewish person knows that Sabbath mode exists, and not every disabled person knows about or is comfortable using assistive technologies designed for their disability.

Eric concludes that it’s important to build accessible experiences by default, and not rely on your users to explicitly ‘enable’ accessibility (such as setting prefers-reduced-motion in a nested submenu somewhere on their OS). On the flipside, people who do set such modes have done so deliberately and rely on them, so don’t remove, override or subvert this functionality.


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.

31 Mar

week11y issue 145

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

HTML gains a <search> element

This one came up in the work chat.

On 24th March, the “WhatWG HTML living standard” gained a new <search> element. It is intended to be used to contain a set of form controls “related to performing a search or filtering operation”. Example code snippet:

<search>
  <form action="search.php">
    <label for="query">Find an article</label>
    <input id="query" name="q" type="search">
    <button type="submit">Go!</button>
  </form>
</search>

Functionally, it is the equivalent of using <div role="search">. The contributors that proposed it did not like the fact that this could only be expressed in ARIA (after all, the first rule of ARIA is to not use ARIA). See the original issue and the resulting pull request.

Quite what this means for browsers is hazy. WHATWG is a community with oversight from Apple, Google, Mozilla and Microsoft (i.e. the companies that build our browsers) so it should be supported in browsers at some point, but there is no clear timeline. See the WHATWG FAQ for details.


Building inclusive products for trans people

Chiara Angori shares some great tips for building products that don’t exclude your trans users.

Some are obvious, such as allowing users to specify their pronouns, and not asking users for their ‘title’ (Mr, Mrs, etc). Titles have no legal bearing and there’s almost never a good reason to ask for them. Even offering a get out option like “Prefer not to say” can be problematic, as some user research towards the end of the article demonstrates. Participants were worried that that option sounds “almost accusatory” and also that they were worried they’d be discriminated against for choosing it.

If asking for something sensitive like sex, e.g. in a medical context, offer three options (male, female and intersex) and provide details around why you’re asking for it. The article shows a screenshot of how the NHS app approaches this.

If you need to know a user’s legal name (or birth name), provide users a way to set their ‘preferred name’, so that trans individuals who have not yet changed their name legally can specify the name they should now be referred by. Give users options to keep their legal name confidential.

Consider enabling ‘discreet’ notifications, e.g. the Trans Memo app that helps trans people track their intake of hormones. This app enables users to replace notification text with something of their choosing, so that anyone who happens to see their notification on a lock screen etc won’t be able to easily understand what is being notified about.

Well worth a read.


Why Motion on Websites and Digital Content Is a Problem

Meryl Evans describes how at times she feels dizzy and light headed, in symptoms she describes as vertigo. 70 percent of deaf and hard of hearing children with sensorineural hearing loss have a vestibular disorder, which is also expected to affect “more than 35% of US adults aged 40 and older at some point in their lives”.

This demographic, alongside people who experience migraines, epilepsy, and general motion sickness, are sensitive to motion. It can be brought on by animated gifs, or background videos and slide shows on websites.

Meryl suggests giving viewers control over motion. Taking Twitter as an example, their accessibility settings have options to reduce motion and turn off autoplay. “When an image with the Play button shows up on Twitter, it’s either a video or an animated GIF. Select the image and it plays. Select the image again and it stops.”

Meryl touches on the “reduce motion” accessibility setting in operating systems, which I covered in more detail in dai11y 12/12/2022.


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.

31 Mar

dai11y 31/03/2023 – Why Motion on Websites and Digital Content Is a Problem

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

Why Motion on Websites and Digital Content Is a Problem

Meryl Evans describes how at times she feels dizzy and light headed, in symptoms she describes as vertigo. 70 percent of deaf and hard of hearing children with sensorineural hearing loss have a vestibular disorder, which is also expected to affect “more than 35% of US adults aged 40 and older at some point in their lives”.

This demographic, alongside people who experience migraines, epilepsy, and general motion sickness, are sensitive to motion. It can be brought on by animated gifs, or background videos and slide shows on websites.

Meryl suggests giving viewers control over motion. Taking Twitter as an example, their accessibility settings have options to reduce motion and turn off autoplay. “When an image with the Play button shows up on Twitter, it’s either a video or an animated GIF. Select the image and it plays. Select the image again and it stops.”

Meryl touches on the “reduce motion” accessibility setting in operating systems, which I covered in more detail in dai11y 12/12/2022.


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.

30 Mar

dai11y 30/03/2023 – Building inclusive products for trans people

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

Building inclusive products for trans people

Chiara Angori shares some great tips for building products that don’t exclude your trans users.

Some are obvious, such as allowing users to specify their pronouns, and not asking users for their ‘title’ (Mr, Mrs, etc). Titles have no legal bearing and there’s almost never a good reason to ask for them. Even offering a get out option like “Prefer not to say” can be problematic, as some user research towards the end of the article demonstrates. Participants were worried that that option sounds “almost accusatory” and also that they were worried they’d be discriminated against for choosing it.

If asking for something sensitive like sex, e.g. in a medical context, offer three options (male, female and intersex) and provide details around why you’re asking for it. The article shows a screenshot of how the NHS app approaches this.

If you need to know a user’s legal name (or birth name), provide users a way to set their ‘preferred name’, so that trans individuals who have not yet changed their name legally can specify the name they should now be referred by. Give users options to keep their legal name confidential.

Consider enabling ‘discreet’ notifications, e.g. the Trans Memo app that helps trans people track their intake of hormones. This app enables users to replace notification text with something of their choosing, so that anyone who happens to see their notification on a lock screen etc won’t be able to easily understand what is being notified about.

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.

Loading...