Your fortnightly frequent11y newsletter, brought to you by @ChrisBAshton:
I thought this article was interesting to call out, as in my experience we still often assume captions should be an ‘opt in’ thing. But perhaps things have pivoted to them being ‘opt out’. Indeed, some captions are now ‘on’ by default on social media.
In a 2022 survey of 1,200 people, language learning company Preply determined that 50 percent of Americans used subtitles and closed captions the vast majority of the time they watch content.
According to Preply, 57 percent of all Americans watch shows or movies or videos in public on their mobile devices, but a very significant 74 percent of Gen Z do the same. Even if you’re (hopefully) using headphones while in public, it’s likely you’re getting poor audio quality… subtitles are practically a necessity.
The article also cites ‘habit’ as one of the main reasons. People are simply more used to using subtitles; the article cites that in 2020, nearly 30 percent of on-demand streaming was for non-US shows.
Finally, there are some modern technical issues that could explain why hearing dialogue is more difficult:
For some, the problem is the design of modern televisions; the majority of which place internal speakers at the bottom of the set instead of facing towards the audience, causing significantly worse audio quality. Other issues are caused by sound designs optimized for theatrical experiences, which can result in compressed audio when translated to home.
“Accessibility annotations” detail interaction design behaviours in UI designs. They communicate the intended experience for keyboard and screen reader users, allowing developers to implement the design just as they would implement a visual one. This speeds up the design QA and development process, but also ensures designers have thought about accessible interactions from the start.
The article shows screenshots of some annotated designs, with symbols clarifying the intended focus tab order of a component, or call-outs to screen-reader-specific text. Even the underlying semantics – whether a list should be ordered or unordered, for example – are clarified with markup annotations.
There is also a Jira ticket template “to facilitate design accessibility review discussions while reviewing the visual mockups”.
The article links to Deque’s downloadable accessibility annotations toolkit, which has files for Adobe Illustrator and Sketch as well as individual SVGs.
Martin Underhill describes Increased Contrast Mode (ICM) – a setting that users can opt into, and which website designers/developers can accommodate through a media query:
@media (prefers-contrast: more) {
/* High contrast styling goes here */
}
Not a lot of people know about this, or they don’t have it high on their list of priorities. It’s utterly reliant on the website creator to support.
Windows High Contrast Mode (WHCM), on the other hand, is a ‘forced colours mode’. It doesn’t rely on the website creator, and instead forces the chosen theme onto the website. It has a well supported media query like ICM, but only allows a handful of carefully selected things to be styled:
@media (forced-colors: active) {
/* WHCM styling goes here */
/* Limited to things like text colour, background colour and keyboard focus outline colour */
}
Martin has made the decision to not attempt to define styles for WHCM users, instead delegating this to the user’s operating system. It should mean they have a more consistent/familiar experience, and it will automatically support their choice of dark or light theme.
Martin Underhill warns against designs that manipulate user input, and the maxlength attribute in particular, which prevents users from typing anything beyond a certain character limit.
Whilst these features are often implemented with the best of intentions – to assist the user in inputting data in the correct format, for example – they’re not very accessible solutions.
Martin references the GOV.UK Design System’s Date Input component, which expects a format like 27 3 2007 but does not prevent users from typing longer numbers (or indeed typing a-z characters). Someone raised a GitHub issue to discuss adding maxlength to the fields, but Hanna Laakso responds:
If you use maxlength attribute on a form field to limit user input, users might not receive appropriate feedback of the limit. For instance, the user might not notice that not all the information they entered appeared in the form field … It is generally better to let users enter their information in a way that suits them and allow them to submit the form.=
Instead, using hint text to nudge the user in the right direction, alongside validation to tell the user how to fix the problem in any particular form field
, is the suggested way forward. Martin notes that “this should also help satisfy 3.3.2 Labels or Instructions and 3.3.3 Error Suggestion, respectively, from the Web Content Accessibility Guidelines (WCAG)”.
This somewhat inflammatory headline by AxessLab leads into a very long but enjoyable article about toggle design. The author argues that real world toggles (light switches) work well because:
- It’s clear whether it’s worked, via the context (the light immediately comes on)
- One can press the switch as many times as one wants, and have the same outcome (i.e. pushing down extra hard on the switch to make sure something comes on).
In the digital world, the design doesn’t carry over so well. For setting things like cookie preferences, there is no obvious visual feedback to enabling/disabling the setting. And activating the switch will flutter back and forth between ‘on’ and ‘off’.
There are lots of illustrations and screenshots in the article, highlighting that it’s often unclear what state a toggle is in. Designs vary, and whilst “most western designers seem to assume that “right = active””, that’s not always the case.
It is possible to make accessible toggles. The author links to articles by industry heavyweights: Heydon Pickering’s article on Toggle Buttons, an article on Toggle Switch design by Sara Soueidan, and Under Engineered Toggles by Adrian Roselli.
The author also cites examples of toggles done well. They show a screenshot of a toggle for filtering on Airbnb, where a toggle button limits the amount of available houses. “Users can understand by the reduced amount of houses that the filter is active, even if they don’t understand the toggle control. The number in the button is physically close to the toggle control, and many users will notice the change as it happens and draw the correct conclusion from context”.
But whilst Airbnb is a big name, other big names are content to not use toggles. The author shows screenshots of Amazon using plain old radio buttons, and Slack using plain old buttons. The author concludes with advice to “just use a checkbox or radio group”.
There were a few other bits of interesting info tangential to the theme of toggles.
“In our user tests, a majority of users will assume an empty text field is actually mandatory and expect an input to be made. So much so that we even recommend you to not use asterisks * to indicate mandatory fields, and instead mark optional fields as “optional”.”
Indeed, “the “filled in = active / touched / done” pattern is so well recognized that if a text input field is not empty, many users will believe it’s done and requires no more work. That’s why you should try to avoid placeholder text and labels that are positioned inside the input field like the commonly used Material UI component, even if it “moves away” on focus.”
A worthwhile read!
It’s hard being the only one in your organisation or team responsible for accessibility. If that sounds familiar, I salute you, and this one’s for you.
This article by Henny Swan might resonate with some of you. Henny has some advice:
- You are not the only person responsible for accessibility. You may be the only person with “accessibility” in your job title, but it’s everyone’s responsibility, from CEOs to content editors, designers and developers.
- Your role is as much about relationships as it is about accessibility. Look for the managers and decision makers who can make things happen, and look for the designers, developers, editors and testers that want to get into accessibility: they can be powerful advocates.
- Find ways to scale. Think about what questions you’re asked the most, and document your answers in shared spaces (Confluence, wiki, design system documentation, etc). Document processes that can be followed within teams, e.g. reviewing designs for accessibility, triaging a11y issues or writing user stories for accessibility.
- You can’t know everything. Tell people you will need to go and research something, and come back with options for them to consider. Get a consultant if specialist knowledge is needed. If you need a budget, invest some time in writing a business case for accessibility.
- Build a support network. Set up an a11y Slack channel. Join the Champions of Accessibility Network (CAN) on LinkedIn, and the WebAIM discussion list. Consider getting a mentor, e.g. at Accessible Community.
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.