Built-in accessibility: blessing or curse?

A presentation at JSHeroes in May 2025 in Cluj-Napoca, Romania by Hidde de Vries

Slide 1

Slide 1

Hidde de Vries, JS Heroes, Cluj-Napoca, May 2025 “Built-in” accessibility: blessing or curse?

Slide 2

Slide 2

25 years ago…

Slide 3

Slide 3

Slide 4

Slide 4

Websites with sticky elements that cover everything when zoomed aren’t accessible codepen.io/hidde/pen/PovjPYV

Slide 5

Slide 5

Websites with FAQs that aren’t reachable by just a keyboard aren’t accessible codepen.io/hidde/pen/ExzXVmb

Slide 6

Slide 6

Websites with important election results in an image with no alternatives aren’t accessible

Slide 7

Slide 7

Disability is a spectrum

Slide 8

Slide 8

so is access

Slide 9

Slide 9

Slide 10

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

Slide 11

We need better websites…

Slide 12

Slide 12

(lack of) Accessibility is a website problem, not a user problem

Slide 13

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

Slide 14

Many of us “Are there opportunities to change the system to improve accessibility across the board?”

Slide 15

Slide 15

Managers “Can we integrate accessibility into our practices?”

Slide 16

Slide 16

Browsers “Can we display websites better?”

Slide 17

Slide 17

CMSes “Can we help content editors edit more accessible content?”

Slide 18

Slide 18

Standards bodies “Can we make standards that take accessibility into account”?

Slide 19

Slide 19

Built-in accessibility: blessing or curse?

Slide 20

Slide 20

Built-in accessibility: blessing and curse

Slide 21

Slide 21

Web Platform features CMSes Browsers Design Systems

Slide 22

Slide 22

Building accessibility into systems (1) Web Platform features

Slide 23

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

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

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

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

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

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

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

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

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

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

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

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

Slide 35

‘Built-in’: some focus management Not built-in: aria-expanded colour contrast zoom support etc etc

Slide 36

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

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

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

Slide 39

More web UI features are on the way to browsers (HTML/CSS). Consider what is built in, what is not.

Slide 40

Slide 40

“Horizontal review” in standards processes See: FAST w3c.github.io/apa/fast/

Slide 41

Slide 41

Self-review in TAG z Self-Review Questionnaire: Accessibility github.com/w3ctag/accessibility-questionnaire/blob/main/accessibility-questionnaire.md

Slide 42

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

Slide 43

Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html

Slide 44

Slide 44

Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html

Slide 45

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

Slide 46

TAKEAWAY #1 We need web platform / HTML features that are accessible, implemented accessibly and/or include accessibility and it’s not trivial

Slide 47

Slide 47

Building accessibility into systems (2) CMSes

Slide 48

Slide 48

Video: Tyler Frisbee (youtube.com/watch?v=3G_uCbKoG5A) hidde.blog

Slide 49

Slide 49

Checks in Jooa11y, for Joomla (based on Sa11y)

Slide 50

Slide 50

Checks in Editoria11y v2, for Drupal (Based on Sa11y)

Slide 51

Slide 51

Contrast warnings in Gutenberg, for WordPress Checks in Editoria11y v2, for Drupal (Based on Sa11y)

Slide 52

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

Slide 53

TAKEAWAY #2 CMSes can be accessibility assistants and it’s (usually) not trivial

Slide 54

Slide 54

Building accessibility into systems (3) Browsers

Slide 55

Slide 55

user agents

Slide 56

Slide 56

agents for the user

Slide 57

Slide 57

What if browsers let us… https://booktravel.business Booktravel Visit Kinderdijk enforce contrast

Slide 58

Slide 58

What if browsers let us… ✓ https://booktravel.business Booktravel Visit Kinderdijk enforce contrast

Slide 59

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

Slide 60

f f “Could browsers ix more accessibility problems automatically?” talks.hiddedevries.nl/KKW74X/could-browsers- ix-more-accessibility-problems-automatically

Slide 61

Slide 61

TAKEAWAY #3 Browsers could intervene when the web content they serve is inaccessible and it’s (usually) not trivial

Slide 62

Slide 62

Building accessibility into systems (4) Design systems

Slide 63

Slide 63

Design systems can make your patterns repeatable

Slide 64

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

Slide 65

Design systems can make good patterns repeatable

Slide 66

Slide 66

Design systems can good make good patterns d ba repeatable or

Slide 67

Slide 67

Design systems can teach the nuance between the components

Slide 68

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

Slide 69

“Built-in” accessibility It can be done. It’s worthwhile. It’s not trivial.

Slide 70

Slide 70

What are the or: questions constraints? you can ask

Slide 71

Slide 71

What could (possibly) go wrong?

Slide 72

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

Slide 73

What decides the accessibility of a component?

Slide 74

Slide 74

Save

Slide 75

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 76

Slide 77

Slide 77

Who impacts the accessibility of a UI?

Slide 78

Slide 78

developer QA tester designer Who impacts the accessibility of a UI? researcher content editor

Slide 79

Slide 79

browser that renders it What impacts the accessibility of a UI? assistive technology CMS that is involved with managing it

Slide 80

Slide 80

A design system can impact through components and docs

Slide 81

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

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

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

Slide 84

“Educate, don’t berate” — Meryl Evans (in “Progress over perfection“)

Slide 85

Slide 85

Used as-is Interpreted Components (excluding settings) Documentation Component settings

Slide 86

Slide 86

TAKEAWAY #6 Components that people reuse and documentation that people interpret are an opportunity to inspire quality

Slide 87

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

Slide 88

Wrapping up

Slide 89

Slide 89

Built-in accessibility: blessing and curse

Slide 90

Slide 90

“Built-in” accessibility It’s not trivial, not a oneoff, not a quick “fix”. It can be done. It’s worthwhile.

Slide 91

Slide 91

Tha n k you ! hidde.blog