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.

Loading...