It would be easier to have an accessible web if all we did with it was publish documents. Blobs of text, images here and there. But modern sites (or “applications”) do a lot more than documents. Often for better, sometimes for worse. To improve accessibility of the web as it is today, I feel we dearly need accessibility guidance that is holistic, well tested and easy to use.
Web sites or applications often come with menus, tooltips, dialogs, drag and drop, tabs and emoji pickers. Some say this is unnecessary and argue interfaces must be simpler. Sometimes they are right—a lot of interfaces can benefit from being simpler. Yet, complex UI components are often genuinely helpful to users. Like, it's good if not all information is always visible at the same time. Hiding less important stuff in less prominent places can help hierarchy. It can be good if, instead of selecting a city from a <select> of thousands, there's some comboboxing going on. ‘No that's an input!’, you say… yeah, maybe, but it could be important for the business to have a city chosen out of a predefined list of options. And that can give certainties that are beneficial to users too.
So, complex UI patterns (widgets, components, etc) are sometimes needed. A lot of sites have them, for reasons ranging from good to bad. A lot of organisations hand-build these components as part of a design system effort, to make their investments reusable. Reusable components can have a huge impact on accessibilility. Because reuse means repetition: of good patterns, bad patterns, accessible patterns, inaccessible patterns… the stakes are high!
Over the years I've seen and heard a lot of developers talk about building components. I heard them speak about the developer experience of building these components. When I was working on guidance at WAI, I listened extra carefully. From what I gathered, many actually want to truly invest in the quality of their components, including the accessibility of those components. But the official guidance they can find is lacking: WCAG's supporting documents are often unclear (with reading levels, for what they are worth, up to professor grade), unpractical (a lot more words than concrete advice) and outdated (eg still recommending the title attribute). WCAG still works best for the web as a series of documents.
In other words, to better match the realities of people making websites, I feel the W3C's accessibility guidance should be more holistic, well-tested and easy to use.
Holistic
The closest to a guide on building accessible components is the ARIA Authoring Practices Guide (“APG”). It's a super useful resource for finding how to build components with ARIA, but it isn't “holistic”.
By holistic advice, I mean advice that considers the reader within their entire environment as a developer. Advice that builds on the best that can be done with HTML, CSS, JavaScript, WAI-ARIA and SVG (technologies websites commonly rely upon). The WAI-ARIA Authoring Practices Guide isn't holistic in that sense: it focuses on patterns built with ARIA only. From developer-who-wants-advice or user-who-needs-a-good-experience perspectives, that's not ideal. As accessibility specialists learn again and again, WAI-ARIA isn't what makes components accessible, it's merely one of the languages (ok, an ontology) that can help us build accessibly (see also: the first rule of ARIA). I don't mean to say any of these specificiations is inherently better, I mean the most accessible component is always some combination of these specs.
If that's the case, you may wonder, why does APG focus on ARIA only? There's no bad intent here… I think it is simply because it is written by a subgroup of the ARIA Working Group. That Working Group specifies ARIA and it has a deliverable to show how to use it. This makes good sense. But again, it isn't ideal if the intention is guidance that helps developers build the very best for users with disabilities (which I think is the goal we should really want to optimise for). Nobody seems to have that as a deliverable.
There is a W3C/WAI resource that is holistic in the way I described: WAI Tutorials. Shoutout to the great work of Eric Eggert and EOWG! It's a good resource, but it did not get expanded or updated much after the initial release.
There are resources outside of W3C/WAI that I can recommend, such as:
- Sarah Higley's posts on tooltips and custom selects
- Sara Soueidan on icon buttons and custom checkboxes/radiobuttons
- Accessible Components by Scott O'Hara
- Adrian Roselli's “Under-Engineered” series
- A complete guide to accessible front-end components by Vitaly Friedman
Well tested
Web accessibility ultimately is about whether people can use a thing. Some friends in the accessibility community like to emphasise that it's about people, not meeting standards. I get that sentiment, but there's a false dichotomy at play: making the web more usable for people with disabilities is a central goal for accessibility standards at organisations like W3C/WAI) They are a means to the same end. Either way, web accessibility is all about people. So, yes, user testing matters. We've got to find out which specific patterns are mostly to work well for people.
While it's essential and beneficial to involve people with disabilities in user tests, there can be challenges:
- just like one single user doesn't speak for all users, one person with a disability doesn't speak for everyone with that disability; you'll want larger samples;
- there are many disabilities; sometimes people with different disabilities could even have “competing” needs. For instance, high contrast benefits some, but could constitute a barrier to others;
- it may be more difficult to recruit users with disabilities and ensure the group you recruit for a given project is the right group in terms of what you want to test;
My friend Peter has documented some of his approach to testing with disabled users and WAI itself has a great page on involving users with disabilities too. Others have blogged about their user testing efforts: Fable tested Loom's video clipping functionality and the GOV.UK Design System team documented what they found testing conditionally revealing questions. These posts show there is a lot of nuance in determining if a complex pattern is accessible. But they also show this nuance can be described and help inform people.
As an aside: another aspect of testing guidance for accessible components is how well they perform across different browsers and assistive technologies. Bocoup, Meta and others are doing great work in this area in the ARIA-AT effort: they define tests (over a thousand drafted), but also pioneer ways to test assistive technologies automatically. I believe the plan is (was?) to show the results of this project next to code examples, which is great.
Easy to use
‘Developer experience’ is a phrase sometimes frowned upon, especially when contrasted with user experience. If we had to choose between them, of course, user experience would be the first choice. But the choice isn't binary like that. If the stars are aligned, one can lead to the other. Companies that make developer-focused products (like CMSes, versioning control, authentication, payment providers, databases etc) usually have a dedicated “developer experience” department that ensures developers can use the product well. Among other things, they try to reduce friction.
Friction could result in income loss for these companies. If the tool constantly displays unhelpful error messages, has code examples that are tricky to follow or documentation that is out of date, developers might look for a different tool. And the opposite is true too: if this payment provider makes it super easy to implement secure payments, a developer will likely want to use it again.
Friction could also cause a product to be “used wrong”. For instance, large groups of developers easily got started with this cool new authentication product, but the docs were so unclear that they missed important security steps? Or, in a CI/CD product, developers manage to get started quickly, but a majority does it in a way that uses way too many resources, because the example projects do? If the company charges overages unexpectedly, it may upset customers, if it doesn't, it could end up costing the company too much.
I'll admit it is a bit of a stretch: what if both of these frictions are at play with accessibility standards? And instead of looking for different standards, developers choose the “easier” route of inaccessibility? This could happen in places where leadership or organisational procedures don't enforce accessibility. They'll get away with it. It could also happen in places that do have a mature accessibility program or even a handful of accessibility-minded individual developers. If the most accessible solution isn't easy to learn (e.g. they get lost between different kinds of guidance), it could still result in inaccessibility, even with the best intentions.
I believe effective accessibility guidance answers “how easy will this make it for people to get it right”, and probably also ”how will this avoid that people take the wrong turn”.
Some examples of what could constitute good developer experience (dreaming aloud here):
- easy to copy examples that closely match real-world components people are building, like privacy setting banners and comboboxes (just to name two examples of major barriers I saw blind users encounters in a user test)
- full example projects for some popular frameworks and languages, eg here's how to build an accessible blog with Next.js, or how to report errors in a form in vanilla JS + 5 popular frameworks
- a specific focus on eliminating inconsistencies in documentation (“boring” work, maybe, but inconsistencies inevitably creep into any set of content—the more inconsistencies are avoided, the more effective documentation is)
While these examples are developer focused, the same kind of focus could be applied other roles like quality assurance and design (see also Roles involved in accessibility, which is a great document, though still in draft status).
I suspect many people with disabilities among us have a mental list or accessibility barriere they encounter most often. Many who do regular accessibility audits will have a list of things they find often. Many developers will have a list of components they are unsure how to build accessibly. Et cetera, et cetera. If I had a magic wand, I would try and put all of these people in one room.
In summary
In this post, I've tried to lay out what my ideal accessibility guidance looks like. The gist of it is: make it easier for people to get accessibility right. And the opposite, too: make it harder to get it wrong. I feel the closer we can get to that, the more accessible interfaces can become. I think this is the way to go: guidance that is holistic, well-tested and optimised for developer experience (or, more broadly, the experience of anyone touching web projects in a way that can make or break accessibility).
And to be clear, this is not an invite for people to care less or circumvent the responsibilities and duties they have. Accessibility needs to be part of one's MVP. But it is an invite for people to rethink our collective efforts in improving web accessibility: WCAG 3.0 may not be it, the world may benefit more from better guidance than from better testing methodologies.
My expectations are probably a tad unrealistic. I probably missed my chance to try and materialise them more when I worked for WAI. Yet, I hope the perspective is helpful to some. Get in touch if you have thoughts!
Thanks to Job van Achterberg for helpful comments on an earlier draft.
Comments, likes & shares (70)
Michelle Barker, Ash, Arthur Rigaud - also at @arigaud_ca@a11y.info, Colin, Wouter de Boer, Brent Morton, muffindev, Dave Rupert, Ryan Randall :OpenAccess: :hc:, 🌸 oscar 🌸, William Comfort Anderson, Philippe Vayssière, Rodney, Johnny Taylor, Michael Wheeler, sara, Juhis, Anuradha Kumari, NickiTheNoodle, Melanie, Una Kravets, Winnie-a11y member, Calvin Brown | #softwarekang, Shelley Williams, Jorge, Vadim Makeev, muan, Corbin Otwell, Shemzone, Alena Nikolaeva, James Bateson, Accesibilidad del software, Eric Eggert, Joe Lanman, Josh, Eric Eggert, Dylan Tackoor, Florian Geierstanger, Tamas G, Steve Faulkner, Todd, Eric Eggert and Svenja liked this
Michelle Barker, Brent Morton, Dave Rupert, Flo, Bhupesh Singh, Reuben Walker, WebOverhauls.com, Winnie-a11y member, Melanie, Accesibilidad del software, Marco Zehe, Steve Faulkner, Todd, Eric Eggert and katherine reposted this
@hdv great read, another thing to add to the list of “things i’ve needed this whole time and never even knew”
@hdv @deanbirkett @wai Yeah, I like all these resources, but I have also seen them making things unclear and confusing at times. I think we have to re-think how to communicate about accessibility from the core. (It would help if the official quickref would be even more useful, but it’s a taboo to simplify WCAG in other “official” documents, which is understandable.)
And even well visited resources barely make a dent.
@hdv @deanbirkett @wai The tutorials get 2.5m visits every year. Most top issues are mentioned there. Some impact, for sure. But is educating and posting resources really the best thing we can do? Or can we change the system, so that it is the logical thing that an output is accessible?
@hdv Thanks for sharing! I've learned a lot from talking with @bkardell, and your experience with Open UI is fascinating.
This is where I feel like a layer _on top of_ HTML helps alleviate some of the issues that standards bump into. Standards understandably need to be comprehensive, and with this approach there's kinda a "here's the 80% use case" pragmatism to it.
@hdv @bkardell All to say, it would be great to be able to create solutions for the obvious and most common use cases without being held hostage by some of the gnarlier edge cases.
It's not easy to build very good UI components. A global effort to try and find the best qualities of components would be a great opportunity to improve components everywhere.
Aren't design systems ultimately a quest to collect the best UI practices across an organisation? Or across multiple organisations, or for anyone in general. This kind of work brings excellent opportunities to improve quality across some scope, organisationally or more widely. And if we do that, why not try and aim for the widest possible scope and go global? In A Global Design System, Brad Frost suggests this:
I can only agree with that. With so many design systems out there, it makes a lot of sense to look at the commonalities between them.
As Brad mentions, we've been doing this at Open UI. The goal of this group is to make it easier for developers to build and style UI controls on the web, by improving the web technologies and standards that they are built with. So far, this lead to features like popover (in Baseline today) and styleable selects (in active development).
How a global design system might work
Brad suggested in his post that we could work towards “common library containing common UI components”, with code and designs and documentation. In his follow up, Greg Whitworth suggests to create a test suite. I like how concrete these ideas are, and I am sure they will help tonnes of developers make better components. But what if we look at this idea more a more abstract way?
There are clearly teams who just want to use concrete components, as-is. But in my work and conversations, I hear demand for something else: to have a way to validate what is good. A lot of teams want to build their own components and systems. Or they have to, because of their organisation's specific constraints.
Finding qualities
To me, it seems a lot of developers want acceptance criteria and holistic guidance, rather than built components. There's a lot of example components already, why not try and collect what's already built and seek consensus about what qualities components need?
I'm thinking things like:
This is information that is relatively hard to find, especially for more rare components, and especially in a format that developers can trust to base their decision making on.
In my ideal world, a global design system isn't primarily concerned with making a set of components. Instead, it would focus on finding the best qualities of components. What are the qualities they must have, in order to be solid, accessible, internationalisable, privacy-friendly, secure component?
Benefits
With this approach, these qualities can become checks for everyone who wants to make these components themselves. And at the same time, they can be checks for everyone who wants to quality-assure or accessibility-assess websites that use these patterns. (Plus, folks could still build an example library of components that adhere to the qualities; but I think there are always going to be multiple ways).
Defining qualities rather than concrete components also helps with another problem we've seen at Open UI a lot: that there are many ways that lead to Rome. For example, there are many ways to build a tab. With qualities, we would avoid the search for the true one way to do something. Instead, we could deem multiple implementations of tabs “ok”. The Org X tab is cool, the Org Y is wildly different, but it is also cool, the Org Z tab is… hm, not great, because it lacks a, b and c.
Lastly, it would help with the myth of the accessible component. There is only so much we can build in, there will always be acccessibility considerations that depend on usage (see my talk on built-in accessibility). Both how you use of the component and the context you use it in determine whether the experience is accessible or not. There's no “use this component and your thing will be accessible“. Paraphrasing Scott O'Hara: a component is accessible until you use it somewhere.
What global comparisons unlock
Aren't we lucky that we're now in a phase of design systems that there are a lot to compare between? Comparing different design systems can unlock a number of things, but these are some things I find particularly interesting:
Each of these is, in its own way, a benefit of including diverse perspectives. Which is what the W3C has been doing for almost (this year!) 30 years.
A national global design system
Brian Kardell shared his idea for moving components through stages. In it, he says:
He suggests folks submit components, that then get reviewed, which will lead to a catalog of components that have been checked and for which everyone can publicly see how many of the checks they meet.
I liked a lot about this proposal and feel it will be fruitful to primarily focus on checks. I also noticed some similarities to what we're doing at NL Design System, a project I'm involved in for the Dutch government, so I wanted to end this post with describing a bit about our process.
At NL Design System, different governmental organisations collaborate on defining the best components, patterns and guidelines. The core team, that I'm a part of, facilitates this collaboration. It may end up being a kind of national global design system, a standard for building good digital government services.
Relay Model
So how do we work? Each organisation in our community has their own design system. In principle, they use a shared architecture, build components that meet their own needs and open source them under the same license. Components that seem suitable for standardisation are put on a track that we call “Relay Model” (see also this excellent presentation on the Relay Model (Dutch, English subtitles available) by my colleague Yolijn van der Kolk).
In relay racing competitions, runners take a baton and hand it over to the next person. With our Relay Model for components, different people can take a component to different stages.
(Note: there are patterns and guidelines too, but here I'll focus on components specifically.)
In this process, components (their “blueprint”, eg “Button”) can have one of four statuses:
There's also two more informal statuses: components that are likely to have just the one use case for one organisation, one-offs, are deemed “Snowflake”, and components that are unlikely to result in accessible, user-friendly components are deemed “Discouraged”.
During any time, components can exist in multiple organisations, so City X, Government Agency Y and Province Z could all have a Button that meet their needs. The “Hall of Fame” Button is the common denominator version of it, where we've tried to remove all the org-specific stuff and stick with features that multiple organisations need. User research is an essential part of all this and we encourage organisations to share theirs as open source Markdown.
Benefits we see include:
We're currently stewarding components through the first stages, and don't have a “Hall of Fame” yet. But the process already demonstrates value today, for everyone involved: teams are using one another's components and are benefiting from each other's perspectives, accessibility knowledge and user research.
Summing up
In conclusion: I think there's a lot of value in trying to find which qualities make for very good components, using a standardisation-like process that involves a broad range of stakeholders and avoids blessing-by-a-few. In my ideal world, this can bring us to a place where web developers can get more confidence in how to make their components very good. Recent conversations within Open UI make me hopeful we'll get closer to that.
Thanks to Robbert Broersma and Yolijn van der Kolk for feedback on earlier drafts.Yesterday, I was at State of the Browser in London. It was great to catch up with friends and make new ones, and the talks were once again very well curated. In this post, I'll share some notes from the day and the takeaways that stood out to me the most.
Think about funding the web ecosystem
Stephanie Stimac kicked us off with a brilliant talk on how to fund the critical infrastructure that is the web ecosystem. We couldn't browse the web without browsers, and they wouldn't exist without engines, that are hard to make, and to fund. In the current model, browsers get large amounts of money from search deals. For instance, in 2021, Google paid almost 20 billion (not a typo) to Apple to make its search engine the default (but a US federal judge ruled that such payments unlawfully limit competition). It's a lot of money, but as that money goes primarily to the browser companies, not the engines, and may go away if search deals are deemed illegal, we need to think about new ways to fund browser engines, Stephanie urged us. They could include donation based systems, tax breaks or a Web Levy. For more context, see Stephanie's slides and in the comments of w3c/breakouts-day-2024#20.
Participate in accessibility standards
Next up was fashion designer and web accessibility advocate Steve Faulkner. He shared some of his own web standards stories and gave practical tips around how to participate. Without naming (many) names, Steve very accurately explained some of the different types you'll find in standards meetings: there are well-meaning, argumentative, axe to grind, practical, clueless, old school, helpful, true-believing, revisionist and lurking type of people. There are a number of ways people do participate: you can file issues (like in w3c/wcag), comment on issues, file PRs, comment on PRs, join a Community Group or join a Working Group. Only for that very last one, you actually need to represent a W3C Member. What you do need to do, Steve warned, is to know when you don't know. It's fine to just listen before having strong opinions. Now, starting to participate can be hard and/or daunting, so to anyone reading this: feel free to slide in my DM/email, we can (always) use more perspectives.
Advocate for the open web
Stuart Langridge shared the story of how he and others at Open Web Advocacy ended up talking to regulators about anti-competitive behaviour in our industry, including the fact that iOS doesn't allow for other browsers than Safari. Their work has had an enormous impact, as it helped regulators understand the nitty gritty details of what they were regulators. “The web is ours”, Stuart said and anyone who believes the same can join and help out at Open Web Advocacy, or do their own advocacy for an open web. Amen to that!
Make impact
Gayle Ngozi shared how the non-profit Code your Future works with refugees and disadvantaged people to get skills in software engineering to close the gap between them and the job market, specifically in the tech industry. She said we can all make impact by contributing stuff like laptops, time by teaching and/or opportunities by working together to launch new tech careers.
Make little web components
Personal website innovator David Darnes finally explained the inner workings of that cool button on his site that announces his name spoken by different people every time you press it. He didn't cover why it has a bias towards his father's recording, but it was very interesting nonetheless. There's one component that upgrades the standard
<audio>element to be a fancy button, another that randomises the source used and one more that makes the playing state available as an attribute so that it can be used in styles. Are Web Components just for little bits? No, Dave showed that it's also used in fairly complex applications he worked on, including at Nordhealth, that has both Nuxt and Django apps using the same components. The technology, Dave said, works so well because is versatile and forgiving.Make standards open
Katie Fenn is a huge Daft Punk fan, so she used her talk slot to play their “Around the world” with web technologies: the WebMIDI and WebAudio APIs specifically. MIDI is a technology and technical standard specced in the 80s that allows you to pass messages and information between musical instruments, like notes and special effects. Because it was, just like the W3C's web standards, completely open and royalty-free, it's changed music production forever, especially electronic music: yay open standards. You should watch this talk when it comes out. I can't wait to go play with the MIDI-enabled devices in my home.
Automate more of assistive technology support testing
Lola Odelola showed how web standards work happens by using the ARIA-AT program (and ghost detection ????) as an example. Many developers will be familiar with the ARIA Authoring Practices Guide. I am very happy for this to exist, but also see gaps in user testing (do real users actually; understand how to use the patterns?) and AT testing (do the patterns work in AT and is that consistent?). ARIA-AT, Lola showed, addresses the latter, and does so really well: there is a Selenium-like protocol called AT Driver to automatically test how the ARIA patterns work in different assistive technologies, with lots of reports as a result. Loved hearing Lola talk about this important project, that I hope can be built out further.
Use fluid scales
Richard Ruttter showed us how to use fluid scales for typography and spacing, I feel inspired to go and try that out on this website when I get a chance. See also what I wrote about that talk at Patterns Day.
Summing up
It was a lovely day, with great talks and conversations. One of the recurring themes was how much extreme capitalism affects the ecosystem we all clearly share a love for, we learned about various concrete ways in which this is at play. At the same time, we shouldn't forget to focus on what is valuable in and of itself: making music, fun buttons and UIs that include everyone. Priorities matter!
@hdv @marco @tink @SteveFaulkner +1 to the keyboard interaction guidance being the really useful bit.
If it's helpful, one of the reasons I did include the content the way I did is that complicated components combined with exotic ARIA declarations tend to, ah, fall apart, and I was hoping to help instruct that to non-a11y wonks.
I know y'all know that, but in the same breath I gotta shoot my shot ????