Built-in accessibility: blessing or curse?
A presentation at JSHeroes in in Cluj-Napoca, Romania by Hidde de Vries
Hidde de Vries, JS Heroes, Cluj-Napoca, May 2025 “Built-in” accessibility: blessing or curse?
25 years ago…
Websites with sticky elements that cover everything when zoomed aren’t accessible codepen.io/hidde/pen/PovjPYV
Websites with FAQs that aren’t reachable by just a keyboard aren’t accessible codepen.io/hidde/pen/ExzXVmb
Websites with important election results in an image with no alternatives aren’t accessible
Disability is a spectrum
so is access
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
We need better websites…
(lack of) Accessibility is a website problem, not a user problem
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 •
Many of us “Are there opportunities to change the system to improve accessibility across the board?”
Managers “Can we integrate accessibility into our practices?”
Browsers “Can we display websites better?”
CMSes “Can we help content editors edit more accessible content?”
Standards bodies “Can we make standards that take accessibility into account”?
Built-in accessibility: blessing or curse?
Built-in accessibility: blessing and curse
Web Platform features CMSes Browsers Design Systems
Building accessibility into systems (1) Web Platform features
Building accessibility into systems (1) Web Platform features // features that make a11y possible, // e.g. support for alt text <img src=”” alt=”” />
Building accessibility into systems (1) Web Platform features // features that make a11y possible, // e.g. support for captions <video> <track>…</track> </video>
Building accessibility into systems (1) Web Platform features // features that do accessibility // semantics for you, like headings <h1>Top news</h1>
Building accessibility into systems (1) Web Platform features // features that do accessibility // semantics for you, like headings <h1>Top news</h1>
// 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>
// 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>
‘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/
‘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/
‘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/
‘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/
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/
// 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>
‘Built-in’: some focus management Not built-in: aria-expanded colour contrast zoom support etc etc
// 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 …
// 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 …
‘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
More web UI features are on the way to browsers (HTML/CSS). Consider what is built in, what is not.
“Horizontal review” in standards processes See: FAST w3c.github.io/apa/fast/
Self-review in TAG z Self-Review Questionnaire: Accessibility github.com/w3ctag/accessibility-questionnaire/blob/main/accessibility-questionnaire.md
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
Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html
Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html
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/
TAKEAWAY #1 We need web platform / HTML features that are accessible, implemented accessibly and/or include accessibility and it’s not trivial
Building accessibility into systems (2) CMSes
Video: Tyler Frisbee (youtube.com/watch?v=3G_uCbKoG5A) hidde.blog
Checks in Jooa11y, for Joomla (based on Sa11y)
Checks in Editoria11y v2, for Drupal (Based on Sa11y)
Contrast warnings in Gutenberg, for WordPress Checks in Editoria11y v2, for Drupal (Based on Sa11y)
Porta11y, accessible checks for Portable Text github.com/hidde/porta11y github.com/hidde/porta11y Checks in Editoria11y v2, for Drupal (Based on Sa11y)
TAKEAWAY #2 CMSes can be accessibility assistants and it’s (usually) not trivial
Building accessibility into systems (3) Browsers
user agents
agents for the user
What if browsers let us… https://booktravel.business Booktravel Visit Kinderdijk enforce contrast
What if browsers let us… ✓ https://booktravel.business Booktravel Visit Kinderdijk enforce contrast
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
f f “Could browsers ix more accessibility problems automatically?” talks.hiddedevries.nl/KKW74X/could-browsers- ix-more-accessibility-problems-automatically
TAKEAWAY #3 Browsers could intervene when the web content they serve is inaccessible and it’s (usually) not trivial
Building accessibility into systems (4) Design systems
Design systems can make your patterns repeatable
“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
Design systems can make good patterns repeatable
Design systems can good make good patterns d ba repeatable or
Design systems can teach the nuance between the components
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
“Built-in” accessibility It can be done. It’s worthwhile. It’s not trivial.
What are the or: questions constraints? you can ask
What could (possibly) go wrong?
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?
What decides the accessibility of a component?
Save
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
Who impacts the accessibility of a UI?
developer QA tester designer Who impacts the accessibility of a UI? researcher content editor
browser that renders it What impacts the accessibility of a UI? assistive technology CMS that is involved with managing it
A design system can impact through components and docs
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)
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
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
“Educate, don’t berate” — Meryl Evans (in “Progress over perfection“)
Used as-is Interpreted Components (excluding settings) Documentation Component settings
TAKEAWAY #6 Components that people reuse and documentation that people interpret are an opportunity to inspire quality
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
Wrapping up
Built-in accessibility: blessing and curse
“Built-in” accessibility It’s not trivial, not a oneoff, not a quick “fix”. It can be done. It’s worthwhile.
Tha n k you ! hidde.blog
