Accessibility - from concept to reality

UX Y'all 2021 Session with Jessie Huff

Transcript

1. Accessibility - from concept to reality Jessie Huff
2. 2 Understanding accessibility Keyboard Interaction Screen readers/ assistive technology Accessible Design Testing and follow-through Accessible Development Live demo Accessibility
3. Keyboard Interaction Can I navigate to everything on the page using the keyboard? Two general accessibility considerations: • Native • Custom
4. ◇ Differences between screen readers - NVDA, JAWS, VO ￭ Our PF strategy - pick one ◇ Sometimes easier to just open a screen reader ￭ Use guides to help you understand navigation and WCAG for interaction Screen Readers & Assistive Technology
5. VO Rotor Navigation (macOS) VO + U (VO=ctrl+opt) "Rotor" feature helps users quickly and easily access navigation actions, like menu options
6. One does not simply select headings based on size, style or color
7. Making Design Systems Accessible Screen reader demo Some blind users train themselves to listen at extraordinarily high speeds
8. Permanent Temporary Situational Deafness Blindness Non-verbal communication Paralysis, limb/digit loss Ear infection Had eyes dilated Sore throat Broken bones Dark environment Non-fluent speaker Hands full Loud environment Auditory Sight Speech Motor Designing for all users
9. Photo © Benjamin Von Wong Cool. Where do we start?
10. Visual Design Considerations Visual acuity or sharpness of vision ➔ Text size, font, style, capitalization, size of all elements ➔ Leading, letter spacing, word spacing, justification, margins and borders, spacing between elements ➔ Heading hierarchy Field of vision ➔ Design layout Central field loss Peripheral field loss Other field loss
11. Redesign for Field of vision A ticket machine that has poor clarity of layout viewed with normal vision, and the same ticket machine viewed with poor peripheral vision. This shows a redesigned layout for the same machine, which enables the overall layout to be perceived, even with a peripheral vision loss. *Example from University of Cambridge’s Inclusive Design Toolkit
12. Contrast and light sensitivity ➔ Combinations of colors Color perception ➔ Use of color Text: #EE0000 Background: #F3F3F3 Text: #EE0000 Background: #C9C9C9 Text: #EE0000 Background: #8B8B8B Text: #EE0000 Background: #4D4D4D Text: #EE0000 Background: #2E2E2E Contrast: 4.08 ❌ (Would pass for large text only) Contrast: 2.74 ❌ Contrast: 1.33 ❌ Contrast: 1.87 ❌ Contrast: 3.00 ❌ Full color perception (no disability) Complete red-green disability (protanopia) Complete green-red disability (deuteranopia) Complete color disability (achromatopsia) Complete blue-yellow disability (tritanopia) Color
13. Accessibility notes: ◇ Uses a basic formula that is easy for developers to follow ◇ Points out purpose, naming, interaction, etc. ◇ If possible, avoid hard coding names to allow for future localization. Example of accessible design mockup
14. When developing, think through these three questions: 1. Is it discoverable/perceivable by all users? 2. Is it interactable? 3. Is it understandable? P. O. U. R. Perceivable Operable Understandable Robust Basics of Accessible Development
15. Is it Understandable and Usable? ◇ The flow of information should make sense. ◇ ◇ Because screen readers navigate the page in DOM order, if you’ve used CSS to visually reposition elements, they may be announced in a nonsensical sequence. If you need something to appear earlier in the page, try to physically move it earlier in the DOM.
16. Labels Aria: ◇ If there is visible text then there doesn’t need to be an aria-label (aria aids in description to screen reader users, doesn’t have to reiterate or override what might already be there, check that your aria is useful) ◇ It’s important to understand that ARIA can only affect the semantics of an element; it has no effect on the behavior of the element. ￭ For example, while you can make an element hidden to screen readers with aria-hidden=”true”, that does not change the focus behavior for that element. ◇ Remember, your aria-labels are for humans! (Don’t use aria-label=”form-control-1”) How do you know if you need a label? Is it understandable and clear without one? Make sure the html is semantic first! First rule of aria! Only use labels when necessary to make it accessible
17. Use clear, concise link text “Read more about Kittehs’ ” “Read more about ‘Totes adorbs’ ” “Read more about ‘I wasn’t ignoring you, I was sleeping.’ ” “Read more, link” “Read more, link” “Read more, link” Examples: Link Labels
18. ◇ Validate your HTML ◇ Add a11y automation ◇ Manual testing with keyboard and screen reader ◇ Integration testing ◇ Teach a11y knowledge across the team Testing and Regressions
19. ◇ How axe can help - foundational issues ◇ Keyboard accessibility: skip to content, tabbing, interaction ◇ Test with VO Accessibility Demo
20. When you don’t know and it isn’t listed, where to go from there? ◇ Accessibility guide and other a11y resources ◇ Is there an established practice? (WCAG is the standard) ◇ Nothing firm? Article documenting someone has done it before ◇ Try and test ◇ If not a firm standard/practice, test across use cases and platforms: ￭ Keyboard ￭ One or more screen readers (VO, NVDA, JAWS, etc.) ◇ Stuck? Ask for help! - ￭ web-a11y slack channel and other communities Resources
21. Making Design Systems Accessible Let’s build something cool and accessible!!
22. Thank you! Mary Shakshober for a11y illustration (slide 15) Mark Caron, Jess Law, and Michael Spaxman for presentation inspiration Brian Dellascio for presentation design guidance The PatternFly team for all of their a11y efforts