Hidde de Vries, JS Heroes, Cluj-Napoca, May 2025
“Built-in” accessibility: blessing or curse?
Slide 2
25 years ago…
Slide 3
Slide 4
Websites with sticky elements that cover everything when zoomed aren’t accessible
codepen.io/hidde/pen/PovjPYV
Slide 5
Websites with FAQs that aren’t reachable by just a keyboard aren’t accessible
codepen.io/hidde/pen/ExzXVmb
Slide 6
Websites with important election results in an image with no alternatives aren’t accessible
Slide 7
Disability is a spectrum
Slide 8
so is access
Slide 9
Slide 10
People will -
zoom in use high contrast modes use a screenreader not use a mouse use voice recognition be unable to turn their device
W3C/WAI, How People with Disabilities Use the Web
https://www.w3.org/WAI/people-use-web/tools-techniques
Slide 11
We need better websites…
Slide 12
(lack of)
Accessibility is a website problem, not a user problem
Slide 13
In defense of websites… Hard to ind good code examples
•
AT/browser support vs actual usability
•
WCAG often can’t tell you what to do (for reasons, but still)
f
•
Slide 14
Many of us
“Are there opportunities to change the system to improve accessibility across the board?”
Slide 15
Managers
“Can we integrate accessibility into our practices?”
Slide 16
Browsers
“Can we display websites better?”
Slide 17
CMSes
“Can we help content editors edit more accessible content?”
Slide 18
Standards bodies
“Can we make standards that take accessibility into account”?
Slide 19
Built-in accessibility: blessing or curse?
Slide 20
Built-in accessibility: blessing and curse
Slide 21
Web Platform features
CMSes
Browsers
Design Systems
Slide 22
Building accessibility into systems (1)
Web Platform features
Slide 23
Building accessibility into systems (1)
Web Platform features // features that make a11y possible, // e.g. support for alt text <img src=”” alt=”” />
Slide 24
Building accessibility into systems (1)
Web Platform features // features that make a11y possible, // e.g. support for captions <video> <track>…</track> </video>
Slide 25
Building accessibility into systems (1)
Web Platform features // features that do accessibility // semantics for you, like headings <h1>Top news</h1>
Slide 26
Building accessibility into systems (1)
Web Platform features // features that do accessibility // semantics for you, like headings <h1>Top news</h1>
Slide 27
// features that do some // accessibility semantics // for you, like popover
I am popover content
<button popovertarget=”p”> Open popover </button> <div popover id=”p”> I am popover content </div>
Slide 28
// features that do some // accessibility semantics // for you, like popover
I am popover content
<button popovertarget=”p”> Open popover </button> <div popover id=”p”> I am popover content </div>
Slide 29
‘Built-in’: aria-expanded state
I am popover content
See: On popover accessibility: what the browser does and doesn’t do https://hidde.blog/popover-accessibility/
Slide 30
‘Built-in’: aria-expanded state aria-details relationship (if apt)
I am popover content
See: On popover accessibility: what the browser does and doesn’t do https://hidde.blog/popover-accessibility/
Slide 31
‘Built-in’: aria-expanded state aria-details relationship (if apt)
I am popover content
group fallback role (if apt)
See: On popover accessibility: what the browser does and doesn’t do https://hidde.blog/popover-accessibility/
Slide 32
‘Built-in’: aria-expanded state aria-details relationship (if apt)
I am popover content
group fallback role (if apt) some focus management
See: On popover accessibility: what the browser does and doesn’t do https://hidde.blog/popover-accessibility/
Slide 33
Not built-in: colour contrast zoom support
I am popover content
etc etc
See: On popover accessibility: what the browser does and doesn’t do https://hidde.blog/popover-accessibility/
Slide 34
// features that do some // accessibility semantics // for you, like commandfor <button command=”show-modal” commandfor=”d”> Open my modal dialog </button> <dialog id=”d”> My modal content </dialog>
Slide 35
‘Built-in’: some focus management
Not built-in: aria-expanded colour contrast zoom support etc etc
Slide 36
// or accordions // features that do some accessibility
<details>
1. Tell the truth. 2. Act now
// semantics for you, like accordions
<summary>Tell the…</summary> <details> …
Governments must act now to halt biodiversity loss and reduce greenhouse gas emissions to net zero by 2025.
3. Go beyond pol t cs
<summary>Tell the truth</summary>
… </details> </details> <details open> <details open> <summary>Act now</summary> … <summary>Act now</summary> </details> …<details> <summary>Go beyond policy</summary> </details> … <details> </details>
<summary>Go beyond…</summary> i
i
…
Slide 37
// or exclusive accordions // features that do some accessibility
<details name=”xr”>
1. Tell the truth. 2. Act now
// semantics for you, like accordions
<summary>Tell the…</summary> <details> …
Governments must act now to halt biodiversity loss and reduce greenhouse gas emissions to net zero by 2025.
3. Go beyond pol t cs
<summary>Tell the truth</summary>
… </details> </details> <details open> <details open name=”xr”> <summary>Act now</summary> … <summary>Act now</summary> </details> …<details> <summary>Go beyond policy</summary> </details> … <details name=”xr”> </details>
<summary>Go beyond…</summary> i
i
…
Slide 38
‘Built-in’: 1. Tell the truth. 2. Act now Governments must act now to halt biodiversity loss and reduce greenhouse gas emissions to net zero by 2025.
i
i
3. Go beyond pol t cs
aria-expanded state
Slide 39
More web UI features are on the way to browsers (HTML/CSS). Consider what is built in, what is not.
Slide 40
“Horizontal review” in standards processes
See: FAST w3c.github.io/apa/fast/
Slide 41
Self-review in TAG
z
Self-Review Questionnaire: Accessibility github.com/w3ctag/accessibility-questionnaire/blob/main/accessibility-questionnaire.md
Slide 42
Implementations in browsers can have accessibility bugs
It’s Mid-2022 and Browsers (Mostly Safari) Still Break Accessibility via Display Properties adrianroselli.com/2022/07/its-mid-2022-and-browsers-mostly-safari-still-break-accessibility-via-display-properties.html
Slide 43
Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html
Slide 44
Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html
Slide 45
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 46
TAKEAWAY #1 We need web platform / HTML features that are accessible, implemented accessibly and/or include accessibility and it’s not trivial
Checks in Editoria11y v2, for Drupal (Based on Sa11y)
Slide 51
Contrast warnings in Gutenberg, for WordPress
Checks in Editoria11y v2, for Drupal (Based on Sa11y)
Slide 52
Porta11y, accessible checks for Portable Text github.com/hidde/porta11y github.com/hidde/porta11y Checks in Editoria11y v2, for Drupal (Based on Sa11y)
Slide 53
TAKEAWAY #2 CMSes can be accessibility assistants and it’s (usually) not trivial
Slide 54
Building accessibility into systems (3)
Browsers
Slide 55
user agents
Slide 56
agents for the user
Slide 57
What if browsers let us…
https://booktravel.business
Booktravel
Visit Kinderdijk
enforce contrast
Slide 58
What if browsers let us…
✓
https://booktravel.business
Booktravel
Visit Kinderdijk
enforce contrast
Slide 59
Designer
I want the focus outline to be 1px light gray User
Actually, I want to see where I am, let me see a focus outline User agent (the user’s agent)
Ok, I’ll make it 10px black
Slide 60
f
f
“Could browsers ix more accessibility problems automatically?” talks.hiddedevries.nl/KKW74X/could-browsers- ix-more-accessibility-problems-automatically
Slide 61
TAKEAWAY #3 Browsers could intervene when the web content they serve is inaccessible
and it’s (usually) not trivial
Slide 62
Building accessibility into systems (4)
Design systems
Slide 63
Design systems can make your patterns repeatable
Slide 64
“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 65
Design systems can make good patterns repeatable
Slide 66
Design systems can good make good patterns d ba repeatable or
Slide 67
Design systems can teach the nuance between the components
Slide 68
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 69
“Built-in” accessibility
It can be done. It’s worthwhile. It’s not trivial.
Slide 70
What are the or: questions constraints? you can ask
Slide 71
What could (possibly) go wrong?
Slide 72
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 73
What decides the accessibility of a component?
Slide 74
Save
Slide 75
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 76
Slide 77
Who impacts the accessibility of a UI?
Slide 78
developer
QA tester
designer Who impacts the accessibility of a UI? researcher
content editor
Slide 79
browser that renders it What impacts the accessibility of a UI? assistive technology
CMS that is involved with managing it
Slide 80
A design system can impact through components and docs
Slide 81
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 82
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 83
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 84
“Educate, don’t berate” — Meryl Evans (in “Progress over perfection“)
Slide 85
Used as-is
Interpreted
Components (excluding settings)
Documentation Component settings
Slide 86
TAKEAWAY #6 Components that people reuse and documentation that people interpret are an opportunity to inspire quality
Slide 87
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 88
Wrapping up
Slide 89
Built-in accessibility: blessing and curse
Slide 90
“Built-in” accessibility
It’s not trivial, not a oneoff, not a quick “fix”. It can be done. It’s worthwhile.