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

Lists

• A Jeremy Keith entry from his journal. Lists are helpfully announced to screen readers when they are navigated to (e.g. “List: six items”). However, Webkit browsers such as Safari don’t announce lists if the lists’ bullets have been removed using CSS (just like it doesn’t announce content that has been visually hidden with display: none). There’s a Twitter thread explaining why, but it boils down to this: “If a sighted user doesn’t need to know it’s a list, why would a screen reader user?”
• If you’ve removed bullets but your content is a list (you may have used some visual replacement for bullets, e.g. image markers), you can force screen readers to treat your content as a list by adding role="list".
• There’s an interesting point about “pixel perfection” across browsers, too. It’s widely considered to be an unattainable or undesirable goal nowadays; why should we demand the aural equivalent? Websites don’t need to sound identical in every screen reader.

VoiceOver Preview for macOS Firefox

• Mozilla have worked hard over the past year to deliver VoiceOver support for Firefox on macOS – something that had been lacking for 15 years. It’s now ready to try in the Firefox 85 Beta and Mozilla are calling on volunteers to try it out and report any bugs they encounter. Other than a few known issues, it is hoped to be fairly stable.

Equal Entry Guidelines for Describing 360-Degree Video

• An interesting set of guidelines describing the challenges of audio-describing a 360 degree video (which will become more prevalent as VR grows). You should divide the video into scenes, write a brief introductory description for each scene, then write audio descriptions for each direction a viewer could face during the scene. Consider ‘forward’, ‘left’, ‘right’, ‘backward’, ‘up’ and ‘down’ views. See the demo on YouTube.

Below I summarise not one, not two, but three articles. It’s my attempt to clarify what seems quite a contradictory issue: whether you should ‘try on’ a disability to build empathy, and/or build better products and services. As someone who has written a series of articles on using the web under various constraints, it’s a subject close to my heart and an important conversation to have.

Article 1: Why I won’t “try on” disability to build empathy in the design process (and you should think twice about it.)

• Amelia Abreu describes how accessibility workshops that, for example, have able-bodied participants trying to navigate a high street with wheelchairs to gain awareness of shortage of ramps, can be counter-productive. A research paper concluded that short-term mimicking of the effects of a disability can a) result in fear, apprehension and pity, b) fail to account for diverse coping mechanisms people develop over time, and therefore, c) cause participants to underestimate the true capabilities of persons with disabilities.
• Instead, Amelia suggests we build relationships with real people with disabilities. Get to know their diverse interests and accessibility concerns, and ask how you can be an ally for disability rights. Also, to draw upon your own experiences. In the wheelchair example, Amelia developed an awareness of the inaccessibility of infrastructure when she had to take her daughter around in a stroller.

Article 2: Going Colorblind: An Experiment in Empathy and Accessibility

• This article appeared a month before the first, and on the same website! Sara Novak describes her colleague Peter’s deuteranomalous colour blindness, affecting 5% of men. It means he has a hard time differentiating greens from other colours. Sara admits she was sympathetic, rather than empathetic, so talked to Peter and decided to see what it’s like to be colourblind for three days, using Chrome extension See.
• Sara realised she’d been colour-coding her responses in emails, and that this was difficult to decipher. She realised why Peter bolded important info in emails rather than rely on colour, and she started to do the same. She also encountered inaccessible web forms which used colour alone to convey error state.

Article 3: Get the Funkify Out: A Neat Accessibility Tool/Disability Simulator

• Michael Larsen writes about the “Funkify Disability Simulator” Chrome extension, which attempts to simulate what it’s like to browse the web with dyslexia, astigmatism, jittery hands and high distraction (much like GDS’s own accessibility personas). With it, Michael was able to create a custom profile that makes a page look “very much like it would without my reading glasses”.

In conclusion, I’m not convinced I have a definitive answer. These were all useful articles and I learned something from each, but this is still a topic on which I’m uneasy and am keen to keep learning about.

Can I use a screen reader and know exactly what it’s like to be a blind person? No, of course not – there are all manner of lived differences.

Can I use a screen reader to test my product? Yes, of course – without testing, we’ve no hope of finding and fixing accessibility issues.

Can I use a screen reader to build empathy? This is more complex. In Sara’s case, it seems she did build empathy for her colourblind colleague through use of a simulator. Perhaps the key is that she didn’t empathise in isolation; she was engaged with Peter and able to ask questions and compare her simulated world view with his. In contrast, I can see how a first time screen reader user with no point of reference could be overwhelmed and unable to navigate, and in turn develop a misguided view of what a blind person is capable of doing.

The articles above were hand-picked from various accessibility newsletters I’m subscribed to. If there are other articles that you recommend, please do send them my way!

---

State-Switch Controls: The Infamous Case of the “Mute” Button

• An article exploring the design of ‘mute’ buttons on the iPhone ‘call’ screen, on Zoom, and on WebEx. Two of the three use fill colour alone to denote state: the universal microphone icon has a dash through it, regardless of what state you’re in, making it difficult to know whether your microphone is currently muted. Zoom is the one that gets it right, as it removes the dash from the microphone when your mic is active, and has a label on the button to indicate what will happen when you press it.
• Aside: I still struggle with Zoom’s implementation, and have yet to find one that doesn’t confuse! Perhaps the best I’ve seen is Google Hangouts’ version, but that could just be down to familiarity as I use it every day.

WordPress adds support for video captions and subtitles

• WordPress v5.6 “Simone” introduces WebVTT support for its videos. This is a big deal considering WordPress powers around 4 out of 10 websites. It means you can upload .vtt files containing subtitles, to enable closed captions on the video. The article gives a nice example of a VTT file, which is just text formatted in a particular way.
• Many WordPress hosting providers aren’t actually well suited for streaming videos, so the author Jon Henshaw recommends uploading the video itself to a CDN, even if you self-host the VTT file.

The lang attribute: browsers telling lies, telling sweet little lies

• Manuel Matuzović shares some useful CSS that can alert you to a missing, empty or incorrect page-level lang attribute. For example:
• html:not([lang]) { border: 10px dotted red; }
• Manuel explains why setting the right value is important for screen reader support, as well things like auto translate.
• There’s an interesting section on quotation marks, highlighting the difference in style between English, German and French quotation mark notation. I wasn’t aware they were different!

Interaction Media Features and Their Potential (for Incorrect Assumptions)

• A really interesting CSS-Tricks article by Patrick Lauke, exploring the Media Queries Level 4 Interaction Media Features.
• In theory, they enable the detection of things like if the user is using a mouse or a touch screen (@media (pointer: fine|coarse) {), which you could use to decide whether to make buttons and touch targets bigger. It also exposes hover support: @media (hover: hover|none).
• In practice, these queries only expose what the browser thinks is the primary input. The user may have a mouse but choose to use their touch screen, or may have an iPhone but primarily navigate via a Bluetooth linked keyboard.
• There is another set of media queries that report on all available inputs: any-pointer and any-hover. If any of the inputs has hover support, for example, then any-hover: hover will be matched.
• We can combine queries for educated guesses. @media (pointer: coarse) and (any-pointer: fine) suggests the primary input is touchscreen, but that there is a mouse or stylus present.
• We risk breaking the user experience by optimising for the wrong input type. We should follow a progressive enhancement approach, e.g. always listen to mouse/keyboard events but also listen for touchstart events if a coarse pointer is detected. Another option is to provide users an explicit choice of ‘Mouse’ vs ‘Touch’.

---

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.