The new HTML search element
My work colleague Ryan recently drew my attention to the new HTML
search element. This morning I read Scott O’Hara’s excellent primer. Scott worked on implementing
<search>, and his article cleared up my questions around what it is and when we can start using it.
Displaying tables on narrow screens
Responsive design for tables is tricky. Sure, you can just make the table’s container horizontally scrollable but that’s more a developer convenience than a great user experience. And if you instead try to do something more clever, you can run into challenges as I did in the past. Still, we should strive to design good narrow screen user experiences for tables, alongside feasible technical solutions to achieve them.
No Style Design System
Adam Silver’s collection of accessible form-related components – a companion to his book Form Design Patterns – is a brilliant reference.
Use the dialog element (reasonably), by Scott O’Hara
Here’s an important update on native modal dialogues. TL;DR – it’s now OK to use
A Designer’s Guide to Documenting Accessibility & User Interactions (by Stephanie Walter)
My teammate Colin just shared this brilliant designers’ guide to documenting accessibility and user interactions. It’s really thorough and includes some pretty clever annotation techniques.
The anatomy of visually-hidden - TPGi
This article is not about when or why you would use visually-hidden content. There’s a number of excellent articles that discuss these questions in detail, notably Scott O’Hara’s Inclusively Hidden. But most of them don’t go into much detail about the specific CSS involved — why do we use this particular pattern, with these specific properties? So today I’m going to dissect it, looking at each of the properties in turn, why it’s there, and why it isn’t something else.
Should I use the HTML title attribute?
People have used the HTML title attribute to achieve a native “tooltip” effect for many years. However accessibility experts have recommended that we should avoid this practice, and here I summarise my research on the topic.
Nordhealth’s Design System
There’s so much to admire in Nord Health’s Design System and specifically its reference website.
Whether I’m thinking about inclusive hiding, hamburger menus or web components one UI pattern I keep revisiting is the disclosure widget. Perhaps it’s because you can use this small pattern to bring together so many other wider aspects of good web development. So for future reference, here’s a braindump of my knowledge and resources on the subject.
Choosing a date - we want to know your use cases (a discussion re. gov.uk design system)
We want to find out if adding a 'date picker' component to the Design System is a good idea.
We're currently looking for: examples of date pickers in services: screenshots, prototypes, links to live services; use cases: explanations of why a 'date picker' was used in a service instead of a 'date input', or something else; research: how well 'date pickers' tested with users to complete different tasks.
How to build an accesssible autocomplete
At work there are plans afoot to reconcile various differing Autocomplete implementations into a single, reusable component. So far there’s been a written audit presenting all instances and how they differ in functional and technical respects. There’s also been design work to identify visual commonalities and avoid future inconsistencies. I’d now like to add another perspective: an investigation into which HTML materials and (if necessary) ARIA supplements are appropriate to ensure we build something accessible and resilient.
The ARIA presentation role
I’ve never properly understood when you would need to use the ARIA
presentation role. This is perhaps in part because it is often used inappropriately, for example in situations where
aria-hidden would be more appropriate. However I think the penny has finally dropped.
Thoughts on HTML over the wire solutions
Max Böck just tweeted his excitement about htmx:
Accessibility drives aesthetics by Alex Chen (on UX Collective)
This article is a couple of years old but just popped up on my radar again. UX Designer Alex Chen asserts that arguments which pit accessibility against aesthetics create a dangerous false equivalence… and I agree.
The article claims that if we are “too accessible” we will meet the needs of the minority but end up hurting those of the majority. This creates a false equivalence between having legitimate access needs and having a preference for a certain aesthetic.
Should I use a button or a link?
I’ve written previously about the important differences between buttons and links. While reviewing some “component refresh” design mocks at work yesterday I noticed the designs were a bit unclear in this regard so I sent the designers a little decision-tree, which I’m noting here for future reference.
Better accessible names | hidde.blog
Accessible names are used by assistive technologies to refer to elements on a web page. Hidde tells us how to word them so that they are more useful.
Because of how we use accessible names, we want to keep them functional and avoid naming controls after what they look like. Ideally, you do this in the imperative form, that makes it easiest to quickly grasp what a thing is going to do.
How to Fix Common iOS Accessibility Issues | Deque
Although I don’t work on native apps, I’ve recently been wondering about how accessibility considerations for them compare to those for websites. So this is a timely and useful reference.
iOS provides a lot of accessibility behavior for free, so it’s a great start to making a mobile application accessible. Unfortunately, accessibility is more complicated than the iOS behavior can address, and using only default behavior can actually cause the app to have additional issues.
Tabs: truth, fiction and practical measures
My colleague Anda and I just had a good conversation about tabs, and specifically the company’s tabs component. I’ve mentioned before that our tabs are unconventional and potentially confusing, and Anda was interested to hear more.
Editable table cells
Yesterday the Design System team received a tentative enquiry regarding making table cells editable. I’m not yet sure whether or not this is a good idea – experience and spidey sense tell me it’s not – but regardless I decided to start exploring so as to base my answer on facts and avoid being overly cautious.
Building the main navigation for a website (on web.dev)
learn about semantic HTML, accessibility, and how using ARIA attributes can sometimes do more harm than good.
Use CSS :has to set root-level styles based on a button’s state
Great tip here from Jhey. He advises using a
:root parent of the button when in “pressed” state and sets a root-level custom property to “on”.
We use too many damn modals (modalz modalz modalz dot com)
At our fortnightly Accessibility Forum at work, we just had a great discussion about modal dialogues. We started by discussing whether focus should be completely trapped within the modal or if the user should at least have access to the browser toolbar (we decided on the former). We then moved onto a general discussion on the pros and cons of modals, which led me to share MODALZ MODALZ MODALZ with the team.
Putting a full stop on truncation
At work we’ve recently been shown a couple of design proposals where truncation was presented as a solution to the perceived problem of long and unwieldy content, for example a long description in a table cell. However following good discussions, as a wider team we’re now leaning towards avoiding truncation as an approach. Truncation can present accessibility issues and as Karen McGrane says truncation is not a good content strategy. I reckon we should just let long content wrap, and design for that to look OK.
And when natural wrapping doesn’t cut it – like when you’re tackling very long words in confined spaces – reach for
overflow-wrap: break-word as suggested in Ahmad Shadeed’s excellent Handling Short And Long Content In CSS.
Inclusive user research: recruiting participants (by Ela Gorla on Tetralogical’s blog)
Tetralogical are doing a great series of articles on running inclusive research. Their latest is about recruiting participants and covers whether you should recruit people with disabilities as part of your testing and if so who, and how many, and how to recruit them.
Custom multi-checkbox and multi-radio controls
Our Design System team has recently received “new component requests” for some custom filtering controls. These look like custom-styled
<select>s however their “options” appear more like checkboxes and radio buttons. I think the inspiration was Carbon Design System’s Dropdown component and the idea is to bring consistency to filtering controls in forms. Although it’s not yet time to fully explore this and make a yay/nay decision on the request, I’ve been doing some initial thinking.
Simple input[type=range] styling, by Ana Tudor
Ana demonstrates how to achieve a range slider effect accessibly, using web standards and without needing to reach for libraries.
Perceived affordances and the functionality mismatch (by Léonie Watson)
Léonie tackles the prickly subject of “element re-purposing” in web development. This post follows a fantastic Twitter exchange started by Lea Verou regarding whether the common visual design request for “adjacent but mututally exclusive buttons” should be built as radio buttons or using
Using one element or set of elements (usually because of their functionality) and styling them to look like something else is a common pattern […but…] it creates a mismatch between the actions people expect they can take and the ones they actually can.
Refactoring a modal dialogue in 2022
My team will soon be refactoring our modal dialogue component. Ours has a few deficiencies, needs better developer experience and documentation, is not built to our Design System component standards, and could use a resilience boost from some progressive enhancement.
A better birthday input, by Vitaly Friedman
I recently signed up to Vitaly from Smashing Mag’s Smart Interface Design Patterns newsletter. This latest edition regarding “date of birth” inputs was interesting, and well timed as my work colleagues and I are about to revisit our form patterns. It’s a nice explainer on why we should approach UI for dates the user knows differently from UI for dates the user will choose.
Tables and pseudo-tables: lessons and tactics
At work I have to think about complex HTML tables a lot. The challenge with doing tables well is that 99% of online table tutorials use fairly simple examples… whereas in reality design and product teams often want to squeeze in lots more. It’s really hard to balance those needs against accessibility, systemisation, styling and responsiveness.
Heads up: I’ve published this post early while it’s still a work in progress because it’s better for me to have it available for reference than languishing in drafts and forgotten. Apologies if you read it in a temporarily rough state.
Improved focus indicators for keyboard navigation (on GitHub’s blog)
GitHub have recently done some good work on improving keyboard navigation for (and general usability of) their focusable elements such as links, buttons and form controls by improving focus indication. And then they wrote a short-but-sweet article about it, then tweeted to share that and their work is getting lots of positive recognition from all the right people. Nice job all round, GitHub!
Improving alternative text for images
Some colleagues at work have recently been asking interesting questions about “good/appropriate alternative text for images”. I definitely reckon it’s a topic worth revisiting because it feels like the landscape has changed a bit on this front over the years.
Skip to Content: Online Accessibility Insights from Léonie Watson
Here’s a lovely, short (13 min) interview from an accessibility expert with a really positive outlook—highly recommended.
Q: What’s just one thing that every single person can do in the progression toward an accessible internet?
A: When you’re talking to colleagues, peers… promote the notion that accessibility is just part of what we do because we’re good at our job. It’s not extraordinary, it’s not unusual, it’s not something you can drop because you’re pushing for launch.
My talk, “Hiding elements on the web” for FreeAgent’s tech blog
I recorded a talk on “Hiding elements on the web” for @freeagent’s tech blog. It’s a tricky #FrontEnd & #a11y topic so I try to cover some good practices and responsible choices. Hope it helps someone. (Also it’s my first video. Lots of room to improve!)
What open-source design systems are built with web components?
Alex Page, a Design System engineer at Spotify, has just asked:
What open-source design systems are built with web components? Anyone exploring this space? Curious to learn what is working and what is challenging. #designsystems #webcomponents
And there are lots of interesting examples in the replies.
GOV.UK introduce an experimental block link component
Here’s an interesting development in the block link saga: GOV.UK have introduced one (named
.chevron-card) on their Homepage, citing how it’ll improve accessibility by increasing mobile touch targets. It’s not yet been added to their Design System while they’re monitoring it to see if it is successful. They’ve chosen the approach which starts with a standard, single, non-wrapping anchor then “stretches” it across the whole card via some pseudo elements and absolute positioning magic. I’m slightly surprised at this choice because it breaks the user’s ability to select text within the link. Really interested to see how it pans out!
Collected web accessibility guidelines, tips and tests
At work, I’m sometimes asked accessibility questions or to provide guidelines. I’m with Anna Cook in considering myself an accessibility advocate rather than an expert however I have picked up lots of tips and knowledge over many years of developing websites. So I thought it’d be useful to gather some general web accessibility tips and tests in one place as a useful reference.
Caveats and notes:
- this is a living document which I’ll expand over time;
- I’m standing on the shoulders of real experts and I list my references at the foot of the article; and
- if I’ve got anything wrong, please let me know!
Collapsible sections, on Inclusive Components
It’s a few years old now, but this tutorial from Heydon Pickering on how to create an accessible, progressively enhanced user interface comprised of multiple collapsible and expandable sections is fantastic. It covers using the appropriate HTML elements (buttons) and ARIA attributes, how best to handle icons (minimal inline SVG), turning it into a web component and plenty more besides.
Buttons and links: definitions, differences and tips
On the web buttons and links are fundamentally different materials. However some design and development practices have led to them becoming conceptually “bundled together” and misunderstood. Practitioners can fall into the trap of seeing the surface-level commonality that “you click the thing, then something happens” and mistakenly thinking the two elements are interchangeable. Some might even consider them as a single “button component” without considering the distinctions underneath. However this mentality causes our users problems and is harmful for effective web development. In this post I’ll address why buttons and links are different and exist separately, and when to use each.
Broken Copy, on a11y-101.com
Here’s an accessibility tip that’s new to me. When the content of a heading, anchor, or other semantic HTML element contains smaller “chunks” of
em (etc), the VoiceOver screen reader on Mac and iOS annoyingly fails to announce the content as a single phrase and instead repeats the parent element’s role for each inner element. We can fix that by adding an inner “wrapper” element inside our parent and giving it
The accessibility of conditionally revealed questions (on GOV.UK)
Here’s something to keep in mind when designing and developing forms. GOV.UK’s accessibility team found last year that there are some accessibility issues with the “conditional reveal” pattern, i.e. when selecting a particular radio button causes more inputs to be revealed.
Accessibility Testing (on adactio.com)
In this journal entry, Jeremy Keith argues that when it comes to accessibility testing it’s not just about finding issues—it’s about finding the issues at the right time.
Accessible Color Generator
There are many colour contrast checking tools but I like this one from Erik Kennedy (of Learn UI Design) a lot. It features an intuitive UI using simple, human language that mirrors the task I’m there to achieve, and it’s great that if your target colour doesn’t have sufficient contrast to meet accessibility guidelines it will intelligently suggest alternatives that do.
Should I use the HTML5 section element and if so, where?
Unlike other HTML5 elements such as
nav, it’s never been particularly clear to me when is appropriate to use
section. This is due in large part to many experts having expressed that it doesn’t quite work as intended.
Inclusive language around buttons
@Amy_Hupe recently posed a great question on Twitter regarding inclusive language for buttons:
What's an inclusive way to describe what you do to a (digital) button, given it might be pressed with a mouse click, a screen tap, a key on a keyboard, and so on? I've tended to use "select" but wondering if that's right?
Changing visual order with CSS
When considering using Flexbox or CSS Grid to change the visual order of elements, remember that “with great power comes great responsibility”.
In Praise of the Unambiguous Click Menu (on CSS-Tricks)
Mark Root-Wiley explains why navigation menus that appear on click rather than hover are better.
Use Mac Zoom to show the text a screen reader gets
I picked up a good accessibility testing tip from my work colleague Max today.
On a Mac, if you open System > Accessibility > Zoom, you can enable “hover text”. This allows you to hold down command (cmd) and then whatever is under the mouse will be shown. This shows the same text that a screen reader sees so it’s good for checking if bits of the page respond to a screen reader.
Accessible interactions (on Adactio)
Jeremy Keith takes us through his thought process regarding the choice of link or
button when planning accessible interactive disclosure elements.
A tool for testing how accessible your experience is on various assistive technologies – perhaps “like BrowserStack but for screen readers”?
Assistiv Labs remotely connects you to real assistive technologies, like NVDA, VoiceOver, and TalkBack, using any modern web browser.
A11y is not “extra effort for people with disabilities”
Strong agree with these sentiments regarding accessibility expressed by Max Böck and Andrey Okonetchnikov on Twitter.
If you’re building UI, it’s your responsibility to make it work for everyone. Clients often tell me “we don’t care about accessibility” but in reality they do want keyboard support at the very least. So I just build my UI in a way it works without discussing it. It’s my job.
Creating websites with prefers-reduced-data (on polypane.app)
Even though more and more people get access to the internet every day, not all of them have fast gigabit connections or unlimited data. Using the media query prefers-reduced-data we can keep our sites accessible to everyone.
My Screen Reader Cheatsheet
Here’s a list of useful Screen Reader commands and tips for my reference and yours. This is a work in progress and I’ll update it as I go.
How-to: Create accessible forms - The A11Y Project
Here are five bite-sized and practical chunks of advice for creating accessible forms.
- Always label your inputs.
- Highlight input elements on focus.
- Break long forms into smaller sections/pages.
- Provide error messages (rather than just colour-based indicators)
- Avoid horizontal layout forms unless necessary.
The Atkinson Hyperlegible Font (Braille Institute)
Braille Institute launch a new, free typeface promising greater legibility and readability for low vision readers.
What makes it different from traditional typography design is that it focuses on letterform distinction to increase character recognition, ultimately improving readability.
How to hide elements on a web page
In order to code modern component designs we often need to hide then reveal elements. At other times we want to provide content to one type of user but hide it from another because it’s not relevant to their mode of browsing. In all cases accessibility should be front and centre in our thoughts. Here’s my approach, heavily inspired by Scott O’Hara’s definitive guide Inclusively Hidden.
Better Alt Text
I’ve just read The A11Y Project’s page on
As most of us know, the HTML
alt attribute is for providing “alternate text” descriptions of images to help ensure people do not miss out on information conveyed by graphics. This can help people using assistive technology such as screen readers, and in situations where images are slow or fail to load.
The article made some interesting points and even though I’ve been using the
alt attribute for years I found three common cases where I could improve how I do things.
Setting an accessibility standard for a UK-based commercial website
When advocating accessible web practices for a commercial website, the question of “what does the law require us to do?” invariably arises.
The difference between aria-label and aria-labelledby (Tink - Léonie Watson)
aria-labelledbyattributes do the same thing but in different ways. Sometimes the two attributes are confused and this has unintended results. This post describes the differences between them and how to choose the right one.
Inclusive Datepicker (by Tommy Feldt)
A human-friendly datepicker. Supports natural language manual input through Chrono.js. Fully accessible with keyboard and screen reader.
Sign-in form best practices (on web.dev)
Sam Dutton advises how to use cross-platform browser features to build sign-in forms that are secure, accessible and easy to use.
Best practice techniques for SVG Icons
Here’s how I’d handle various common SVG icon scenarios with accessibility in mind.
How to create accessible subtitles (on Go Make Things)
Here’s Chris Ferdinandi, introducing the ARIA
Accessibility (on adactio.com)
Here’s Jeremy Keith, making the moral case for accessible websites and why we shouldn’t use “you can make more money by not turning people away” as an argument:
I understand how it’s useful to have the stats and numbers to hand should you need to convince a sociopath in your organisation, but when numbers are used as the justification, you’re playing the numbers game from then on. You’ll probably have to field questions like ”Well, how many screen reader users are visiting our site anyway?” (To which the correct answer is “I don’t know and I don’t care” – even if the number is 1, the website should still be accessible because it’s the right thing to do.)
Striking a Balance Between Native and Custom Select Elements (on CSS-Tricks)
We’re not going to try to replicate everything that the browser does by default with a native select element. We’re going to literally use a select element when any assistive tech is used. But when a mouse is being used, we’ll show the styled version and make it function as a select element.
We’ve ruined the Web. Here’s how we fix it. (This is HCD podcast)
Here’s a brilliant discussion between Gerry McGovern and Jeremy Keith on that problem, suggesting tactics to help fix things such as performance budgets, introducing tactics at the design stage to mimic slow connections and other access constraints, optimising for return visits, progressive enhancement and more.
Finding participants for user research - Service Manual (GOV.UK)
It’s also important to do research with all the different kinds of people who may need your service, including those who: have disabilities or use assistive technologies; have limited digital skills or poor literacy; and may need help to use your service.
Block Links: A tricky UI Problem
You have a “card” component which includes a heading, some text, an image, and a link to the full article, and it’s working great. Then along comes a UX requirement that the full card (not just the button or link) should be clickable. This is where things get complicated.
HTML: The Inaccessible Parts (daverupert.com)
Here’s Dave Rupert, frustratedly rounding up the accessibility shortfalls in browser implementations of native HTML elements.
I’ve always abided in the idea that “HTML is accessible by default and then we come along and mess it up”. But that’s not always the case. There are some cases where even using plain ol’ HTML causes accessibility problems.
Why the GOV.UK Design System team changed the input type for numbers (Technology in Government)
<input type="text" inputmode="numeric" pattern="[0-9]*">(instead of
<input type="number") allows for a degree of separation between how the user enters data (“input mode”), what the browser expects the user input to contain (type equals number), and potentially how it tries to validate it.
Are My Colours Accessible?
Colour contrast and the use of colour is extremely important for certain groups of people with varying levels of visional impairment. Building upon the excellent Colorable, I wanted more context around the result. When you share the outcome with your colleagues, all the results, rules and what you’re aiming for, is easily understandable for when you have those awkward conversations with designers and marketers. Accessibility doesn’t have to be ugly.
The Contrast Triangle
Removing underlines from links in HTML text presents an accessibility challenge. In order for a design to be considered accessible, there is now a three-sided design contraint - or what I call "The Contrast Triangle". Your text, links and background colors must now all have sufficient contrast from each other. Links must have a contrast ratio of 3:1 from their surrounding text. By not using underlines, a design has to rely on contrast alone to achieve this.
BBC GEL Inclusive Components Technical Guide
The BBC Global Experience Language (GEL) Technical Guides are a series of framework-agnostic, code-centric recommendations and examples for building GEL design patterns in websites. They illustrate how to create websites that comply with all BBC guidelines and industry best practice, giving special emphasis to accessibility.
Responsive Type and Zoom (by Adrian Roselli)
When people zoom a page, it is typically because they want the text to be bigger. When we anchor the text to the viewport size, even with a (fractional) multiplier, we can take away their ability to do that. It can be as much a barrier as disabling zoom. If a user cannot get the text to 200% of the original size, you may also be looking at a WCAG 1.4.4 Resize text (AA) problem.
Design Better Forms (UX Collective)
As Andrew Coyle says, “Life is short. No one wants to fill out a form.”. Here, he presents a number of form design tips to make the user experience more bearable and increase completion rates.
Making a Better Custom Select Element (24 ways)
We want a way for someone to choose an item from a list of options, but it’s more complicated than just that. We want autocomplete options. We want to put images in there, not just text. The
optgroupelement is ugly, hard to style, and not announced by screen readers. I had high hopes for the
datalistelement, but it’s no good for people with low vision who zoom or use high contrast themes.
selectinputs are limited in a lot of ways. Let’s work out how to make our own while keeping all the accessibility features of the original.
Building an accessible show/hide disclosure component with vanilla JS (Go Make Things)
A disclosure component is the formal name for the pattern where you click a button to reveal or hide content. This includes things like a “show more/show less” interaction for some descriptive text below a YouTube video, or a hamburger menu that reveals and hides when you click it.
Who Can Use
It's a tool that brings attention and understanding to how color contrast can affect different people with visual impairments.
WAVE Web Accessibility Evaluation Tool
The featured article in this week’s Accessibility Weekly newsletter was on recent improvements to the WAVE suite of accessibility testing tools.
I can’t remember using WAVE before, however just one quick test of fuzzylogic.me using their online tool revealed an accessibility issue with the linked SVG logo in the header. A great catch, now fixed, from which I learned something new. I’ll certainly be adding WAVE to my accessibility testing toolbox from here on in.
WAVE is a suite of evaluation tools that help authors make their web content more accessible to individuals with disabilities. WAVE can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors, but also facilitates human evaluation of web content. Our philosophy is to focus on issues that we know impact end users, facilitate human evaluation, and to educate about web accessibility.
Why much of the internet is closed off to blind people – BBC News
Following the recent watershed Domino’s Pizza case, BBC News reports that retailers in the USA & Canada are struggling to make their websites accessible and consumers are taking them to court.
Colors – a nicer color palette for the web
Skinning your prototypes just got easier - colors.css is a collection of skin classes to use while prototyping in the browser.
Beyond Automatic Testing (matuzo.at)
Six accessibility tests Viennese Front-end Developer Manuel Matusovic runs on every website he develops, beyond simply running a Lighthouse audit.
U.S. Supreme Court Favors Digital Accessibility in Domino’s Case
Digital products which are a public accommodation must be accessible, or will be subject to a lawsuit (and probably lose).
Webfont loading strategies
When it comes to webfonts, if you want to serve an accessible and high performance experience across device types it’s not as straightforward as just specifying your fonts in CSS then hoping for the best.
Using aria-current is a win-win situation
The HTML attribute
aria-current allows us to indicate the currently active element in a sequence. It’s not only great for accessibility but also doubles as a hook to style that element individually.
Don’t set cursor: pointer on buttons
For many years I’ve been applying
cursor: pointer to buttons because it felt right and would improve the user experience.
Accessible modal dialogues in 2019
I previously noted Keith J Grant’s article on the HTML
dialog element which promised a native means of handling popups and modal dialogues. I’ve not yet used
dialog in production, partly because of spotty browser support (although there is a polyfill) but also partly because—for reasons I couldn’t quite put my finger on after reading the spec—it just didn’t feel like the finished article.
Using the tabindex attribute | TPG
Léonie Watson explains how the HTML tabindex attribute is used to manage keyboard focus. Of particular interest to me was a clarification of what
tabindex="-1" does (because I always forget).
See all tags.