Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Accessibility - from concept to reality

2618eb8fa459e5cef8f7a8d8f6a21c59?s=47 UX Y'all
September 29, 2021

Accessibility - from concept to reality

UX Y'all 2021 Session with Jessie Huff


UX Y'all

September 29, 2021

More Decks by UX Y'all

Other Decks in Design


  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