More software should have accessibility built in
A presentation at Joy of Coding in in Rotterdam, Netherlands by Hidde de Vries
Today I want to convince you of two things:
- it’s worthwhile to try and build accessibility into our systems
- we shouldn’t overestimate that, and realise it’s not trivial and not a one-off thing that we do, and then we’re done and we walk away, that’s not how it goes
As of last month it is 25 years ago that the first version of the Web Content Accessibility Guidelines were published, an effort from the W3C to explain to web developers how to make their sites more accessible.
25 years later, the glass is half full, this standard and especially its latest iterations are hugely successful and part of the law in some form or another all over the globe.
The glass is also somewhat half empty, there’s still accessibility problems on websites today.
There’s websites with sticky elements…
… where no content is visible whenever it is zoomed in, because the sticky elements block everything.
Or websites where some parts of the UI cannot be accessed with just a keyboard.
Thing is… we need better websites…
because (lack of) accessibility is a website problem, not a user problem.
So websites should improve. And, in addition, what we can also do is look for opportunities.
We can try and find opportunities to build accessibility into systems.
Let me give you some examples where that can work.
Does anyone remember Clippy, the assistant in Microsoft Word that would tell you how to make your documents better. I want CMSes to be an accessibility assistant, spot problems, warn content creators before they press publish.
Or we can build accessibility into web platform features. To some extent. See this post I wrote for more context, but the TLDR is: yes we can add some things that the browser can take care of if you use this features, guardrails, so to say. But also, at the same time, these don’t guarantee accessibility, there is still things a developer would need to do themselves, like ensure good colour contrast, to just name one.
See: On popover accessibility: what the browser does and doesn’t do (that I co-wrote with Scott O’Hara)
// features that do some accessibility // semantics for you, like popover
<button popovertarget="p"> Toggle popover </button> <div popover id="p"> … </div>
Or we could build accessibility into browsers… make user agents more like agents for the user… they could enhance content on behalf of the user, so regardless of whether a website wants that, they could increase contrast when they see it is low, or add a focus indicator when the website doesn’t have one. It’s a user agent, not a designer agent.
Or we could build accessibility into design systems… at NL Design System, a project I work on for the Dutch government where we get design system teams to work together, we store design decisions in code, using so-called design tokens.
Code example:
--nl-button-border-color: #2446AE;
--nl-button-color: #2446AE;
--nl-button-background-color: #ffffff
“Built-in” accessibility
“Built-in” accessibility It’s not trivial, not a oneoff, not a quick “fix”.
“Built-in” accessibility It’s not trivial, not a oneoff, not a quick “fix”. It can be done.
“Built-in” accessibility It’s not trivial, not a oneoff, not a quick “fix”. It can be done. It’s worthwhile.
Thanks! @hdv in most places
A lot of organisations, government and private corporations, are required to make their websites accessible to people with disabilities. But few do, and many struggle. What if we built more guidance and checks into software? In this talk, we’ll look at some ideas for putting accessibility where people are. to make their life’s and those of end users easier.
Resources
The following resources were mentioned during the presentation or are useful additional information.
-
Revised Charter: Web Content Guidelines Working Group
-
On popover accessibility: what the browser does and doesn’t do
-
Framework for Accessible Specification of Technologies (FAST)
-
accessibility-spec-questionnaire by Steve Faulkner
-
HTML - the inaccessible parts by Dave Rupert
-
More accessible defaults, please!
-
Chromium Blog, Updates to form controls and focus
-
Improving Web Accessibility with Web Platform Tests
-
Porta11y, accessible checks for Portable Text
-
HTML, the inaccessible parts by Dave Rupert
-
Self review questionairre
-
On popover accessibility: what the browser does and doesn’t do by Hidde de Vries and Scott O’Hara
-
“Could browsers fix more accessibility problems automatically?”
-
Building conscious design systems by Amy Hupe
-
Dashboard Digitoegankelijk
-
GOV.UK Service Standard - Make sure everyone can use the service
-
NL Design System
-
Jooa11y for Joomla
-
editoria11y for Drupal
-
porta11y for Sanity Studio
