It’s been a little while since my last month11y, partly because Mailchimp have recently upped their prices, meaning I’m no longer within the free tier. I’ve been procrastinating moving to a different provider, but will give that some more thought. I’ll also be on annual leave for a while now, so you won’t hear much more from me until June/July.
With that out of the way, onto this month’s issue!
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.
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.
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.
AI-Generated Images from AI-Generated Alt Text
Adrian Roselli explores the topic of AI and accessibility, as claims are being made that AI could make up for things like a lack of human-provided alt text. He feeds several different images into the following browsers/software and has them generate alt text descriptions for the images:
- Microsoft Edge
- Google Chrome
- Apple iOS VoiceOver Recognition
- Microsoft Office
He then feeds the generated alt text into AI image generators, Craiyon and Midjourney, to see what they create from the alt text. He does the same with his own manually created alt text, to compare the image outputs.
This is an exercise to highlight that automated alt text still isn’t particularly good, and that the quality of alt text greatly influences the quality of generated images (a metaphor for how a screen reader user uses the web and relies on good alt text to be able to properly understand an image).
There’s a follow-on article, AI-Generated Images from AI-Generated Prompts, which explores the idea of feeding images into tools that then spout out AI prompts you can use to try to generate new images (very cyclical!).
Also cool to note that the opening image of each article was generated by AI, using the title of the post as the seed phrase.
Washington Post Design System
The world is divided into people who like perusing design systems, and those who don’t. I actually fall into the latter category – I find that these systems require a lot of time sunk into them, and often just reinvent the wheel – but even so, here’s the Washington Post version.
It’s worth a quick click through to see the accessibility checklist, the screen reader shortcuts, and the pretty comprehensive overview of alt text (from a technical implementation and content writing perspective).
10 Ways Designers and Researchers Can Meaningfully Engage With Disabled People in 2023
A thought-provoking article with some really useful takeaways.
Some tips are practical/logistical:
- Bring disabled people into your process “from the very beginning”, before you’ve locked in your design problem or research questions. Doing so allows you to make the best use of these community members, allowing them to lend their expertise and be true collaborators, rather than just ‘rubber-stamping’ your design.
- Offer remote and asynchronous participation. “Can you offer to do interviews over instant messaging or email? Can you run a focus group on Slack or Teams chat? Can you provide workshop materials and interview questions in advance so that your participants have extra time for cognitive processing?”
- Consider what changes you can make to properly reward your participants.
Others are a change in mindset:
- Reframe your design thinking: instead of “designing for” trust, you should “design against” abuse and exploitation. “Designing against” helps to avoid feature creep and lets you focus on just “the structural factors that are really, materially shaping those problems”.
- “Be Deliberate About How You Categorize / Segment Disability”, i.e. instead of asking “what kind of disability do you have?”, ask “which of these things are difficult or inaccessible for you?”. Understand that some people don’t yet have a medical diagnosis for their disability. Ask about barriers and difficulties rather than disabilities.
- Related: how should you hire disabled people in the first place? Traditional networking and going through large-scale disability charities is not inclusive, says the author. Instead, they propose hiring “a couple of disabled people as outreach coordinators”: people who are “politically engaged enough to be connected to small grassroots organizations, to be aware of current and ongoing issues within disability communities and how those need to be reflected in design research questions and recruitment profiles for research participants”.
- There are also sections in the article about “thinking about power”, stopping “ignoring invisibilized disability”, and “thinking about accessibility in terms of time and energy, not just space and matter”.
Progress Over Perfection: The Better Way for Communication and Accessibility Advocacy
This article by Meryl Evans really resonates with me.
Accessibility is big and daunting. It needs to be considered in every facet of an organisation: “HR needs to ensure the hiring and employee benefits processes are accessible. Procurement needs to ensure the company buys accessible products and services”. People will inevitably make mistakes – even Accessibility Advocates!
Progress isn’t always a straight line – sometimes it will go backwards. They key is to get started and keep moving. You can start with something as simple as an accessibility statement on your website, giving people an avenue for reporting accessibility issues. Don’t spend years trying to perfect everything behind the scenes before launching your 100% accessible product – be iterative.
One exception that muddies the rule a bit is the use of overlays. Whilst these have the feel of “progress over perfection”, they make your product less accessible, not more so. Better to ask companies to remove these overlays, through educating rather than berating. Meryl follows these four steps:
- Show gratitude for what they do right.
- Provide the suggestion.
- Explain the reason for the suggestion.
- End on a high note or with a thank you.
“Progress over perfection”, and being kind, gets results.
Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.
