Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:
Don’t meddle with user input
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
maxlengthattribute 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)”.
Toggles suck!
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!
The only accessibility specialist in the room
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.
