# data[].attributes.title
“Built-in” accessibility: blessing or curse?

# data[].attributes.blurb.html
“We’ll build in accessibility”, they say. But what does “built-in” actually mean? Whether it’s in standards, browser functionality, web platform features or design system components… the reality could be anywhere from an enormous opportunity to a huge disappointment. The stakes are high. And as an accessibility specialist, you should probably ask questions. In this talk, we’ll look at how “built-in” can be effective and how it helps NL Design System to remove barriers at scale.

# data[].attributes.slidedeck.data[].slides[].desc.html
Hidde de Vries, a11yTO, 3 October, Toronto “Built-in” accessibility: blessing or curse?

# data[].attributes.slidedeck.data[].slides[].desc.html
25 years ago…

# data[].attributes.slidedeck.data[].slides[].desc.html
“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

# data[].attributes.slidedeck.data[].slides[].desc.html
Websites with sticky elements that cover everything when zoomed aren’t accessible codepen.io/hidde/pen/PovjPYV

# data[].attributes.slidedeck.data[].slides[].desc.html
Websites with FAQs that aren’t reachable by just a keyboard aren’t accessible codepen.io/hidde/pen/ExzXVmb

# data[].attributes.slidedeck.data[].slides[].desc.html
Websites with important election results in an image with no alternatives aren’t accessible

# data[].attributes.slidedeck.data[].slides[].desc.html
We need better websites…

# data[].attributes.slidedeck.data[].slides[].desc.html
(lack of) Accessibility is a website problem, not a user problem

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
In defense of websites… Hard to ind good code examples • Conformance vs guidance • AT/browser support vs actual usability • WCAG often can’t tell you what to do (for reasons, but still) f •

# data[].attributes.slidedeck.data[].slides[].desc.html
Many of us “Are there opportunities to change the system to improve accessibility across the board?”

# data[].attributes.slidedeck.data[].slides[].desc.html
Managers “Can we integrate accessibility into our practices?”

# data[].attributes.slidedeck.data[].slides[].desc.html
Browsers “Can we display websites better?”

# data[].attributes.slidedeck.data[].slides[].desc.html
CMSes “Can we help content editors edit more accessible content?”

# data[].attributes.slidedeck.data[].slides[].desc.html
Standards bodies “Can we make standards that take accessibility into account”?

# data[].attributes.slidedeck.data[].slides[].desc.html
Built-in accessibility: blessing or curse?

# data[].attributes.slidedeck.data[].slides[].desc.html
Built-in accessibility: blessing and curse

# data[].attributes.slidedeck.data[].slides[].desc.html
Building accessibility into systems

# data[].attributes.slidedeck.data[].slides[].desc.html
Building accessibility into systems (1) Web Platform features

# data[].attributes.slidedeck.data[].slides[].desc.html
Building accessibility into systems (1) Web Platform features // features that make a11y possible, // e.g. support for alt text <img src=”” alt=”” />

# data[].attributes.slidedeck.data[].slides[].desc.html
Building accessibility into systems (1) Web Platform features // features that make a11y possible, // e.g. support for captions <video> <track>…</track> </video>

# data[].attributes.slidedeck.data[].slides[].desc.html
Building accessibility into systems (1) Web Platform features // features that do accessibility // semantics for you, like headings <h1>Top news</h1>

# data[].attributes.slidedeck.data[].slides[].desc.html
// features that do some accessibility // semantics for you, like popover <button popovertarget=”p”> Open popover </button> <div popover id=”p”> I am popover content </div>

# data[].attributes.slidedeck.data[].slides[].desc.html
// 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>

# data[].attributes.slidedeck.data[].slides[].desc.html
// 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>

# data[].attributes.slidedeck.data[].slides[].desc.html
‘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/

# data[].attributes.slidedeck.data[].slides[].desc.html
‘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/

# data[].attributes.slidedeck.data[].slides[].desc.html
‘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/

# data[].attributes.slidedeck.data[].slides[].desc.html
‘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/

# data[].attributes.slidedeck.data[].slides[].desc.html
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/

# data[].attributes.slidedeck.data[].slides[].desc.html
“Horizontal review” in standards processes See: FAST w3c.github.io/apa/fast/

# data[].attributes.slidedeck.data[].slides[].desc.html
Self-review in TAG z Self-Review Questionnaire: Accessibility github.com/w3ctag/accessibility-questionnaire/blob/main/accessibility-questionnaire.md

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
See: HTML, the inaccessible parts daverupert.com/2020/02/html-the-inaccessible-parts/

# data[].attributes.slidedeck.data[].slides[].desc.html
Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html

# data[].attributes.slidedeck.data[].slides[].desc.html
Chromium Blog, Updates to form controls and focus blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html

# data[].attributes.slidedeck.data[].slides[].desc.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/

# data[].attributes.slidedeck.data[].slides[].desc.html
TAKEAWAY #1 We need web platform / HTML features that are accessible and/or include accessibility and it’s not trivial

# data[].attributes.slidedeck.data[].slides[].desc.html
Building accessibility into systems (2) CMSes

# data[].attributes.slidedeck.data[].slides[].desc.html
Checks in Jooa11y, for Joomla (based on Sa11y)

# data[].attributes.slidedeck.data[].slides[].desc.html
Checks in Editoria11y v2, for Drupal (Based on Sa11y)

# data[].attributes.slidedeck.data[].slides[].desc.html
Contrast warnings in Gutenberg, for WordPress Checks in Editoria11y v2, for Drupal (Based on Sa11y)

# data[].attributes.slidedeck.data[].slides[].desc.html
Porta11y, accessible checks for Portable Text github.com/hidde/porta11y github.com/hidde/porta11y Checks in Editoria11y v2, for Drupal (Based on Sa11y)

# data[].attributes.slidedeck.data[].slides[].desc.html
TAKEAWAY #2 CMSes can be accessibility assistants and it’s (usually) not trivial

# data[].attributes.slidedeck.data[].slides[].desc.html
Building accessibility into systems (3) Browsers

# data[].attributes.slidedeck.data[].slides[].desc.html
f f “Could browsers ix more accessibility problems automatically?” talks.hiddedevries.nl/KKW74X/could-browsers- ix-more-accessibility-problems-automatically

# data[].attributes.slidedeck.data[].slides[].desc.html
Untruncate text Force focus indication Force colour contrast Suppress autoplay of gifs and videos

# data[].attributes.slidedeck.data[].slides[].desc.html
TAKEAWAY #3 Browsers could intervene when the web content they serve is inaccessible and it’s (usually) not trivial

# data[].attributes.slidedeck.data[].slides[].desc.html
Building accessibility into systems (4) Design systems

# data[].attributes.slidedeck.data[].slides[].desc.html
Design systems can make your patterns repeatable

# data[].attributes.slidedeck.data[].slides[].desc.html
“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

# data[].attributes.slidedeck.data[].slides[].desc.html
Design systems can make good patterns repeatable

# data[].attributes.slidedeck.data[].slides[].desc.html
Design systems can good make good patterns d ba repeatable or

# data[].attributes.slidedeck.data[].slides[].desc.html
Design systems can make patterns repeatable so we’d better ensure they’re good

# data[].attributes.slidedeck.data[].slides[].desc.html
Design systems can teach the nuance between the components

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
“Built-in” accessibility It can be done. It’s worthwhile. It’s not trivial.

# data[].attributes.slidedeck.data[].slides[].desc.html
What are the or: questions constraints? you can ask

# data[].attributes.slidedeck.data[].slides[].desc.html
What could (possibly) go wrong?

# data[].attributes.slidedeck.data[].slides[].desc.html
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?

# data[].attributes.slidedeck.data[].slides[].desc.html
What decides the accessibility of a component?

# data[].attributes.slidedeck.data[].slides[].desc.html
Save

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Who impacts the accessibility of a UI?

# data[].attributes.slidedeck.data[].slides[].desc.html
developer QA tester designer Who impacts the accessibility of a UI? researcher content editor

# data[].attributes.slidedeck.data[].slides[].desc.html
(it’s the whole team)

# data[].attributes.slidedeck.data[].slides[].desc.html
browser that renders it What impacts the accessibility of a UI? assistive technology CMS that is involved with managing it

# data[].attributes.slidedeck.data[].slides[].desc.html
A design system can impact through components and docs

# data[].attributes.slidedeck.data[].slides[].desc.html
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)

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
“Educate, don’t berate” — Meryl Evans (in “Progress over perfection“)

# data[].attributes.slidedeck.data[].slides[].desc.html
Used as-is Interpreted Components (excluding settings) Documentation Component settings

# data[].attributes.slidedeck.data[].slides[].desc.html
TAKEAWAY #6 Components that people reuse and documentation that people interpret are an opportunity to inspire quality

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
NL Design System

# data[].attributes.slidedeck.data[].slides[].desc.html
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.

# data[].attributes.slidedeck.data[].slides[].desc.html
Collaboration through “Relay Model” with quality checks in each of four stages.

# data[].attributes.slidedeck.data[].slides[].desc.html
Lessons learned

# data[].attributes.slidedeck.data[].slides[].desc.html
Make it concrete

# data[].attributes.slidedeck.data[].slides[].desc.html
Make it concrete

# data[].attributes.slidedeck.data[].slides[].desc.html
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”

# data[].attributes.slidedeck.data[].slides[].desc.html
Make it concrete: do’s and don’ts

# data[].attributes.slidedeck.data[].slides[].desc.html
Back guidance up with research

# data[].attributes.slidedeck.data[].slides[].desc.html
“Accessibility isn’t just about meeting standards, it’s about usability too” — Vasilis van Gemert (this morning)

# data[].attributes.slidedeck.data[].slides[].desc.html
User research as input for patterns

# data[].attributes.slidedeck.data[].slides[].desc.html
Accessibility audit reports as input for guidelines organisation X organisation Y organisation Z Design Open Hour

# data[].attributes.slidedeck.data[].slides[].desc.html
Most reported issues as input for guidelines FUT URE

# data[].attributes.slidedeck.data[].slides[].desc.html
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 •

# data[].attributes.slidedeck.data[].slides[].desc.html
Work in the open

# data[].attributes.slidedeck.data[].slides[].desc.html
Threads in public channels so that people can peak (low-treshold)

# data[].attributes.slidedeck.data[].slides[].desc.html
Public bi-weekly meetings that are also publised afterwards

# data[].attributes.slidedeck.data[].slides[].desc.html
Test with people and share the results

# data[].attributes.slidedeck.data[].slides[].desc.html
Test with people and share the results Because accessibility is more than WCAG

# data[].attributes.slidedeck.data[].slides[].desc.html
Test with people and share the results Because not everyone will test, your results likely have some use for others

# data[].attributes.slidedeck.data[].slides[].desc.html
gebruikersonderzoeken.nl

# data[].attributes.slidedeck.data[].slides[].desc.html
Open design decisions up for automated scrutiny

# data[].attributes.slidedeck.data[].slides[].desc.html
Save

# data[].attributes.slidedeck.data[].slides[].desc.html
—nl-button-border-color: #2446AE —nl-button-color: #2446AE Save —nl-button-background-color: #ffffff

# data[].attributes.slidedeck.data[].slides[].desc.html
—nl-button-border-color: #2446AE —nl-button-color: #2446AE Save —nl-button-background-color: #ffffff

# data[].attributes.slidedeck.data[].slides[].desc.html
—nl-button-border-color: #2446AE —nl-button-color: #cccccc Save —nl-button-background-color: #ffffff

# data[].attributes.slidedeck.data[].slides[].desc.html
—nl-button-border-color: #2446AE —nl-button-color: #cccccc Save 🚨 —nl-button-background-color: #ffffff

# data[].attributes.slidedeck.data[].slides[].desc.html
Verify with process

# data[].attributes.slidedeck.data[].slides[].desc.html
Verify with process: GOV.UK

# data[].attributes.slidedeck.data[].slides[].desc.html
Verify with process: NL Design System “Relay Model”

# data[].attributes.slidedeck.data[].slides[].desc.html
Do handover to consumers with test steps

# data[].attributes.slidedeck.data[].slides[].desc.html
Handover: USWDS • Explain which tests you’ve done • Explain what consumers of the components should test themselves

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Wrapping up

# data[].attributes.slidedeck.data[].slides[].desc.html
Built-in accessibility: blessing and curse

# data[].attributes.slidedeck.data[].slides[].desc.html
Re: in defense of websites… 💡 • Hard to ind good code examples • Conformance vs guidance • AT/browser support vs actual usability • WCAG often can’t tell you what to do (for reasons, but still) f 💡 💡 💡 💡

# data[].attributes.slidedeck.data[].slides[].desc.html
“Built-in” accessibility It’s not trivial, not a oneoff, not a quick “fix”. It can be done. It’s worthwhile.

# data[].attributes.slidedeck.data[].slides[].desc.html
Tha n k you ! hidde.blog/slides @hdv in most places

# data[].attributes.slidedeck.data[].slides[].desc.html
Thank you! hidde.blog @hdv@front-end.social Slides: talks.hiddedevries.nl

# data[].attributes.resources.data[].title
It’s Mid-2022 and Browsers (Mostly Safari) Still Break Accessibility via Display Properties

# data[].attributes.resources.data[].title
On popover accessibility: what the browser does and doesn’t do

# data[].attributes.resources.data[].title
Framework for Accessible Specification of Technologies (FAST)

# data[].attributes.resources.data[].title
HTML - the inaccessible parts by Dave Rupert

# data[].attributes.resources.data[].title
Chromium Blog, Updates to form controls and focus

# data[].attributes.resources.data[].title
 Improving Web Accessibility with Web Platform Tests

# data[].attributes.resources.data[].title
Porta11y, accessible checks for Portable Text

# data[].attributes.resources.data[].title
HTML, the inaccessible parts by Dave Rupert

# data[].attributes.resources.data[].title
On popover accessibility: what the browser does and doesn’t do by Hidde de Vries and Scott O’Hara

# data[].attributes.resources.data[].title
“Could browsers fix more accessibility problems automatically?”

# data[].attributes.resources.data[].title
Building conscious design systems by Amy Hupe

# data[].attributes.resources.data[].title
GOV.UK Service Standard - Make sure everyone can use the service