An intro to Accessible Web-Apps

Hi 👋 • Marcus Herrmann • Freelance Front-end Developer, Accessibility Consultant • Co-organizer A11y Meetup Berlin • @_marcusherrmann • marcus.io

Creators of web-apps should have accessibility in mind.

How can they improve accessibility?

Get the basics right

Web Apps

Accessibility Basics • Document and heading structure • Visible Focus • Semantics • Landmark Regions • Page Titles • Document Language • Color contrast • Providing multiple ways of finding content • Bypass Blocks • Accessible names and meaningful labeling • …

Accessibility Basics • Document and heading structure • Semantics • Page Titles 👉 • Color contrast w . w w w / s:/ p t t re: h e h t Star • Visible Focus / g n i p o l e v e d / s p i t / I A • Landmark regions W / g r o . 3 • Bypass Blocks • Accessible names and meaningful labeling • Document Language • Providing multiple ways of finding content • …

Aside: Screen Readers • Screen readers read out the document - if not stopped - from top to bottom • In practice, users navigate by headlines, links, forms, landmark regions, etc. • One more reason to create • a meaningful document outline • meaningful link texts • an useful form structure with labelled inputs

Consider Web App characteristics

Web Apps

› The general distinction […] is unclear. Web sites most likely to be referred to as ‘web applications’ are those which have similar functionality to a desktop software application, or to a mobile app. ‹ – Wikipedia

Characteristics of web-apps • Loading content asynchronously • Submitting content asynchronously • often times consist of custom widgets for inputting data • often have dialogs or modal windows

Ways to tackle these challenges:

Ways to tackle these challenges: 1. Programmatically Changing focus

Ways to tackle these challenges: 1. Programmatically Changing focus 2. Using ARIA Roles, States, Properties responsibly

Notifications • Use ARIA live regions • Announce state changes • Without programmatically moving focus • Without reloading the page • assertive = interrupting the screen reader • polite = waiting

Code Example <div aria-live=”polite” id=”notice”> <!— My content will be changed with Javascript —> </div> <button type=”button” id=”save”>Save</button> <script> document.getElementById(‘save’).addEventListener(‘click’, function () { // Code for saving here (…) // When successful: document.getElementById(‘notice’).textContent = ‘Document has been saved’; }); </script>

🎞 https://youtu.be/3oocKYah1LA

Specific roles • role=”status”, role=”log” correspond to aria-live=”polite” • role=”alert” corresponds to aria-live=”assertive”

Routing

Usual screen reader behavior 1. User navigates to link 2. Clicks it 3. New page is loaded 4. Once finished, screen reader starts to read out the page title

🎞 https://youtu.be/aMDThPdnHIk

Possible solutions • After successful navigation: • Sending a notification to the screen reader via live region: “About page has loaded” • Programmatically moving focus

About moving focus • Usually: don’t mess with focus • Make sure the element is actually there • Make the element focusable with tabindex="-1" • element.focus()

Dialogs A dialog box is a piece of UI that asks or requests the user for a response.

Modal dialogs A dialog box forcing an interaction, makes it mandatory to interact with

× Do you want to continue this presentation? SURE! NAH….

Code example 1 <div role=”alertdialog” aria-labelledby=”title” aria-modal=”true”> <h1 id=”title”>Supermodal!</h1> <!— Modal content, buttons and such —> </div>

Code example 1 <div role=”alertdialog” aria-labelledby=”title” aria-modal=”true”> <h1 id=”title”>Supermodal!</h1> <!— Modal content, buttons and such —> </div> Unfortunately, there’s a bug with aria-modal in Apple’s VoiceOver….

Code example 2 <div aria-hidden=”true”> <main role=”main”> <p>content</p> <button type=”button”>Open modal</button> </main> </div> <div role=”alertdialog” aria-labelledby=”title”> <h1 id=”title”>Supermodal!</h1> </div> <!— In short: blocked content and modals are siblings, not nested! —>

3 steps of dialog focus management • Once the modal opens, send focus to it: on the first interactive item or on the close button • Again: trap focus in the open modal • After the modal closes, send focus back to the activating button

Buttons

Buttons or: Just because I can make a span clickable that doesn’t mean I should

Interactive vs. non-interactive Is it an interactive element, but not an input? YES <a /> or <button /> NO <whatever-is-reasonable />

Buttons vs. Links Does it change the location in the browser history, or does it jump to other parts of the page? <a /> Does it change the page’s state, does it open a modal, does it toggle or submit something? <button />

Please don’t do this <a href=”#” onClick=”someThing();”>To be or not to be</a> <a href=”javascript:someThing();”>That is the question</a>

Real buttons: Advantages • Is focusable by default, no need for tabindex=”0” • Click Event fired on click, spacebar, return key press • Semantic meaning for all user agents: interactivity, without having to add role=”button” • Disabled state: Disables click events, key events, focusability, has own disabled style • Is able to submit and reset forms

Button style reset button { -webkit-appearance: none; margin: 0; padding: 0; border: none; border-radius: 0; font: inherit; color: inherit; background: none; }

Don’t reinvent HTML inputs • Look for “HTML primitives” first • Common Input Elements • input[type=”range”], Details/Summary, datalist • Try to style them - it got better! • If there’s no other way: look for ARIA authoring practices and for tutorials at w3.org

Word of warning about ARIA • Adding the WAI-ARIA to it roles does not automatically enable the component’s functionality or keyboard behavior. • ARIA is a promise! • “Using ARIA is a bit like using spices and seasoning when you’re cooking - use lightly and well” – Leonie Watson

Creators of web-apps should have accessibility in mind. So should creators of web-app frameworks

Check framework accessibility

React • Dedicated documentation page: reactjs.org/docs/accessibility.html • Accessible component libraries • Reach project, Reakit, Tenon UI • designsystem.gov.au • Accessibility Community (Almero Steyns, Marcy Sutton, Ryan Florence, …) • react-axe

Angular • Angular Material component library • Angular Material A11y Tools: • Keyboard usage • Focus (including Focus traps) • Accessible Announcements

Vue • Component libraries: bootstrap-vue, vuematerial.io (Material UI for Vue) • No mention of accessibility in the official docs - yet • vue-a11y project • vue-announcer • vue-skip-link • vue-axe

Conclusion Creators of web-apps should have accessibility in mind. So should creators of web-app frameworks The accessibility community should help both parties by sharing their knowledge

accessible-app.com

› For people without disabilities, technology makes things convenient, whereas for people with disabilities, it makes things possible ‹ – Judith Heumann

Thanks! Slides and resources: noti.st/marcus