Have you ever heard someone say “we can build in accessibility?”. In this room I think there will be people working on a project that “builds in” accessibility… if you are or you’re not, maybe in this talk you’ll hear about some ways to try and build accessibility in.
Slide 1
Slide 2
For the Dutch government, I work on a project called NL Design System, opinions are my own. I am also in some accessibility related groups at the W3C and have my own blog, on hidde dot blog.
Slide 3
As of last month, it is 25 years ago that the W3C released a document in the wild called Web Content Accessibility Guidelines, version 1.0. I personally didn’t know what the web was back then…
To prepare this talk I looked back at the charter of hte group that made these… the goal of these guidelines was to give web developers advice about how to make their work accessible to people with disabilities.
Slide 4
And to be fair, that was still the goal in all the versions that followed it.
As my friend Eric Eggert said: “in the grand scheme of things it’s always the same principles and guidelines” — Eric Eggert (in post about WCAG)
See: Do we need WCAG 3 now? yatil.net/blog/do-we-need-wcag-3-now
Slide 5
If we reflect back on those 25 years, we can see how WCAG changed accessibilility forever, it’s been incredibly successful in the sense that it’s now part of legislation globally.
But there’s also still problems in websites today.
Slide 6
There are websites with sticky elements that cover everything when zoomed in, and they aren’t accessible. (Video played of page showing exactly that)
Slide 7
There are still websites with FAQs that aren’t reachable by just a keyboard aren’t accessible.
Slide 8
On Thursday we had European elections here in the Netherlands. When a major news site published the preliminary results, I could not help myself and tried if I could find out the predicted seats per party using a screenreader. Turns out there’s no alt on the image.
Websites with important election results in an image with no alternatives aren’t accessible.
Slide 9
My point is… we still need better websites…
Slide 10
Because lack of ccessibility is a website problem, not a user problem. That could be the end of the talk.
But to be fair, it is also an information and education problem. There’s quite a lot to know about accessibility.
Slide 11
It can be a maze of acronyms, and maybe the seasoned among you know what all of these are, but when you start out that’s a lot to take in.
(WAI-ARIA TECHNIQUES UNDERSTANDING COGA ACT-RULES WCAG 2.1 LEVEL A/A/AAA ATAG AXE LOW VISION ASSISTIVE TECH ACCESSIBLE VR XAUR UAAG ACT MATURITY MODEL WEBVTT AGWG LAWS & POLICIES SEMANTICS CONFORMANCE EVALUATION EARL AUTHORING PRACTICES WCAG-EM ACCESSIBILITY STATEMENTS)
Slide 12
So, in defense of websites… for developers, can be hard to find good code examples. There’s plenty of them, but it can be tricky to dinstinguish between low and high quality).
People also commonly misunderstand the diffference between conformance and guidance, WCAG being the normative document for conformance, and documents like the Authoring Practices being merely guidance.
Working with developers, I often see them struggle with finding out how well ATs and browsers support features. There’s some support charts, but they’re not part of bigger initiatives like Baseline. And that’s not even including actual usability, your perfect ARIA tabs may confuse users if they don’t know the keystrokes, I’ve seen this in user tests.
And then there’s the thing that WCAG often doesn’t tell you what to do. That’s for a reason, if WCAG was very concrete it would need thousands of guidelines and criteria, that would go out of date real quick.
Slide 13
Anyway, this is the situation, even 25 years after WCAG we still have a lot of inaccessible websites. And it’s not trivial for people who make websites.
Many of us, probably incliuding you must have wondered… “Are there opportunities to change the system to improve accessibility across the board?”
Slide 14
Or maybe your manager asked, “Can we integrate accessibility into our practices?”?
Slide 15
Browsers have looked at this too: “Can we display websites better?”
Slide 16
CMSes have also considered this… “Can we help content editors make more accessible content?”
Slide 17
And this is a question for standards bodies too… “Can we make standards that take accessibility into account”?
Slide 18
So this talk is called built-in accessibility: blessing or curse?
Slide 19
And the TLDR is that it really is a bit of both, it can be a blessing and curse.
Slide 20
In the next bit, I’ll show you some ways that accessibility can be built into systems.
Slide 21
Let’s start with Web Platform features
Slide 22
There are features that make a11y possible, e.g. support for alt text in the image tag.
<img src="" alt="" />
Slide 23
And features that do accessibility or semantics for you, like headings, they have a built in role:
<h1>Top news</h1>
Slide 24
A more complex example of that is popover, a recent addition to HTML that has a bunch of accessibility properties built in. Thanks to a lot of effort from Scott O’Hara in particular, aria-expanded is set, and aria-details too in specific cases, and keyboard behaviour is taken care of too.
See this post I co-wrote with Scott O’Hara: On popover accessibility: what the browser does and doesn’t do.
Code example:
<button popovertarget="p"> Toggle popover </button> <div popover id="p"> … </div>
Slide 25
To make sure that standards don’t cause accessibility problems the W3C has a “horizontal review” process, it takes care of things like security and privacy as well, but also accessibility. One interesting project in that area is FAST, an accessibility checklist for specifications.
Still, the standards process can be messy, for lack of a better word, it’s very well possible that features make it into specifications and/or browsers while their accessibility is lacking, which could be both due to lack of consideration or unexpected problems found out afterwards.
Slide 26
this is how far I got transcribing what I said… will update in the future
Slide 27
Slide 28
Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html
Slide 29
Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html
Slide 30
Improvements re making accessibility tree testable >1000 Web Platform Tests labeled “accessibility” See: Improving Web Accessibility with Web Platform Tests webkit.org/blog/15400/improving-web-accessibility-with-web-platform-tests/
Slide 31
TAKEAWAY #1 We need web platform / HTML features that are accessible and/or include accessibility and it’s not trivial
Slide 32
Building accessibility into systems (2) CMSes
Slide 33
Slide 34
Checks in Jooa11y, for Joomla (based on Sa11y)
Slide 35
Checks in Editoria11y v2, for Drupal (Based on Sa11y)
Slide 36
Contrast warnings in Gutenberg, for WordPress Checks in Editoria11y v2, for Drupal (Based on Sa11y)
Slide 37
Porta11y, accessible checks for Portable Text github.com/hidde/porta11y github.com/hidde/porta11y Checks in Editoria11y v2, for Drupal (Based on Sa11y)
Slide 38
TAKEAWAY #2 CMSes can be accessibility assistants and it’s (usually) not trivial
Slide 39
Building accessibility into systems (3) Browsers
Slide 40
f f “Could browsers ix more accessibility problems automatically?” talks.hiddedevries.nl/KKW74X/could-browsers- ix-more-accessibility-problems-automatically
Slide 41
Untruncate text Force focus indication Force colour contrast Suppress autoplay of gifs and videos
Slide 42
TAKEAWAY #3 Browsers could intervene when the web content they serve is inaccessible and it’s (usually) not trivial
Slide 43
Building accessibility into systems (4) Design systems
Slide 44
Design systems can make your patterns repeatable
Slide 45
“Not only is this work not inherently valuable, it is also not inherently harmless” — Amy Hupe Building conscious design systems amyhupe.co.uk/articles/building-conscious-design-systems
Slide 46
Design systems can make good patterns repeatable
Slide 47
Design systems can good make good patterns d ba repeatable or
Slide 48
Design systems can make patterns repeatable so we’d better ensure they’re good
Slide 49
Design systems can teach the nuance between the components
Slide 50
TAKEAWAY #4 Design Systems make code and principles repeatable, ensure you repeat the right things f and it’s (de and initely) it’s not trivial
Slide 51
What are the or: questions constraints? you can ask
Slide 52
What could (possibly) go wrong?
Slide 53
Does the icon disappear in dark mode? Will the tabs break with too many items? What if all buttons in a group are named the same? How do we ensure there’s useful text in <FormFieldError>? f Can we force the label component to be used whenever the text ield component is used?
Slide 54
What decides the accessibility of a component?
Slide 55
Save
Slide 56
The quick brown fox jumps Where does she jump? Over the lazy dog? Well, there is really only one way to ind out… f Find out
Slide 57
Slide 58
Who impacts the accessibility of a UI?
Slide 59
developer QA tester designer Who impacts the accessibility of a UI? researcher content editor
Slide 60
(it’s the whole team)
Slide 61
What impacts the accessibility of a UI?
Slide 62
browser that renders it What impacts the accessibility of a UI? assistive tech (that some of your users use) CMS that is involved with managing it
Slide 63
What impacts the accessibility of a UI? design systems?
Slide 64
A design system can impact through components and docs
Slide 65
What design system components can do • User preference support (dark/forced color mode, text spacing, zoom support) • Accessibility semantics (roles, states, properties) • Keyboard support • Focus management • Support for accessibility features (images: alt support, video players: caption support, etc)
Slide 66
What design system docs can do • All variables/settings documented • Theme validator (colour f contrast, spacing etc) • Full lows: how do components work together? • Showing the right way
Slide 67
What design system docs can do • All variables/settings documented • Theme validator (colour f contrast, spacing etc) • Full lows: how do components work together? • Showing the right way
Slide 68
“Educate, don’t berate” — Meryl Evans (in “Progress over perfection“)
Slide 69
Used as-is Interpreted Components (excluding settings) Documentation Component settings
Slide 70
TAKEAWAY #6 Components that people reuse and documentation that people interpret are an opportunity to inspire quality
Slide 71
What design system marketing should do Avoid overpromising the accessibility impact Say “makes it easier to” instead of “will take care of” ff Emphasise the role of design system in a continuous e ort
Slide 72
NL Design System
Slide 73
Community of 500+ web professionals in all layers of Dutch government who work together. We collect the best components, guidelines, patterns and user research for digital services.
Slide 74
Collaboration through “Relay Model” with quality checks in each of four stages.
Slide 75
Lessons learned
Slide 76
Make it concrete
Slide 77
Make it concrete
Slide 78
Make it concrete “Add error messages for forms into a live region” “Only use assertive live regions when information requires the user’s attention immediately”
Slide 79
Make it concrete: do’s and don’ts
Slide 80
Back guidance up with research
Slide 81
Accessibility audit reports as input for guidelines organisation X organisation Y organisation Z Design Open Hour
Slide 82
Most reported issues as input for guidelines FUT URE
Slide 83
User research as input for patterns
Slide 84
Make it open source More perspectives lead to better quality • Easier to report issues • Easier to steal • Most e ective against reinvention of wheels • Instigates collaboration ff •
Slide 85
Work in the open
Slide 86
Threads in public channels so that people can peak (low-treshold)
Slide 87
Public bi-weekly meetings that are also publised afterwards
Slide 88
Test with people and share the results
Slide 89
Test with users and share the results Because accessibility is more than WCAG
Slide 90
Test with users and share the results Because not everyone will test, your results likely have some use for others
Slide 91
gebruikersonderzoeken.nl
Slide 92
Open design decisions up for automated scrutiny
Slide 93
Save
Slide 94
—nl-button-border-color: #2446AE —nl-button-color: #2446AE Save —nl-button-background-color: #ffffff
Slide 95
—nl-button-border-color: #2446AE —nl-button-color: #2446AE Save —nl-button-background-color: #ffffff
Slide 96
—nl-button-border-color: #2446AE —nl-button-color: #cccccc Save —nl-button-background-color: #ffffff
Slide 97
—nl-button-border-color: #2446AE —nl-button-color: #cccccc Save 🚨 —nl-button-background-color: #ffffff
Slide 98
Verify with process
Slide 99
Verify with process: GOV.UK
Slide 100
Verify with process: NL Design System “Relay Model”
Slide 101
Do handover to consumers with test steps
Slide 102
Handover: USWDS • Explain which tests you’ve done • Explain what consumers of the components should test themselves
Slide 103
Make it concrete Back guidance up with research Make it open source Work in the open Test with users, share the tests Test design tokens Verify with process Handover with test steps
Slide 104
Wrapping up
Slide 105
Built-in accessibility: blessing and curse
Slide 106
Built-in accessibility: blessing and curse “Built-in” is not trivial and not a one-off or quick “fix”. But it’s worth pursuing carefully and in addition to your org’s accessibility work.
Slide 107
What would you do or ask?
Slide 108
Thank you! hidde.blog @hdv@front-end.social Slides: talks.hiddedevries.nl
