Simple Accessibility: The Bare Minimum for Compassionate Development

As front-end developers, we bear significant responsibility to ensure that our teams’ creations can be used by real people. We’re often told that accessibility is a “nice idea,” but that it’s too costly to learn, implement, or validate, or that people who “need accessibility” can just ask someone to help them. We then build sites and apps for an audience of mythical people with exceptional eyesight and hearing, full range of motion in their bodies, impeccable memory, and as much attention span as we think they should have.

We can do better, and if we want to take pride in crafting quality software, we must. Learn what accessibility really covers, how to incorporate it into ongoing development, and how to verify we’re doing it correctly.

Transcript

1. Simple accessibility
   THE BARE MINIMUM FOR COMPASSIONATE DEVELOPMENT
   Melissa Avery-Weir
   @averymd
   

   View Slide

2. Our jobs, our passions
   oWe are creators
   oWe are empowered
   oWe are… constrained
   

   View Slide

3. Accessibility and “Disability”
   o Auditory: hard of hearing, deafness
   o Visual: low-vision, blindness, color blindness
   o Neurological or Cognitive: memory impairments,
   distractibility, learning disabilities
   o Motor: reduced response time, inability to use a
   mouse, lack of fine motor control
   

   View Slide

4. Bring forth the compassion
   “Deep awareness of the suffering of
   another, coupled with the wish to relieve
   it.”
   —Wiktionary
   

   View Slide

5. “They’ll have someone to help
   them do it.”
   —Someone I don’t want to work for
   

   View Slide

6. How do we do better?
   o Semantic markup and ARIA roles
   o Explicitly connect content with descriptors
   o Provide text alternatives
   o Keyboard accessibility
   

   View Slide

7. Accessible Rich Internet Applications
   “ARIA”
   o Part of Web Content Accessibility Guidelines (WCAG) 2.0
   o Provides optional roles, state information, and “live
   regions” for more semantic markup
   o Example roles: banner, navigation, search, main, form
   

   View Slide

8. ARIA roles example
   

   View Slide

9. Semantic markup and ARIA roles
   o Use h1-h6, p, ul/ol/dl, header, nav, aside, footer
   Why?
   1. Screenreaders will announce “landmarks”,
   headers, and lists
   2. Allows users to customize their view of pages
   

   View Slide

10. https://www.youtube.com/watch?v=jiA9RJBwXvw
    

    View Slide

11. Semantic Markup and Roles
    1. Use semantic HTML5 markup (headers, lists)
    2. Use the “role” attribute to indicate
    landmarks: banner, navigation, search, main,
    form
    

    View Slide

12. Connect content with descriptors
    Visual users have visual context
    

    View Slide

13. ARIA label, labelledby, describedby
    o aria-label: Text label for an object
    o aria-labelledby: ID references to elements that label
    a focusable object
    o aria-describedby: ID references to elements that
    describe an object
    

    View Slide

14. Split label – the better way
    

    View Slide

15. Provide text alternatives
    o Concise, accurate alt attributes on images
    o Don’t treat “title” on images as a text alternative
    o Descriptions of charts and diagrams
    o Encourage video/audio content creators to provide
    closed captioning and transcripts
    

    View Slide

16. Why provide text alternatives?
    o Screenreaders
    o Slow connections
    o Triggering content
    

    View Slide

17. Keyboard accessibility
    o Events that trigger on hover, mouseover, or
    mouseout should probably also trigger on focus and
    blur
    o onclick isn’t mouse-specific
    o Functionality should be available to keyboards
    o JS widgets get complicated
    

    View Slide

18. Widget Libraries
    o jQuery UI is not accessible
    o Kendo UI seems pretty awesome
    o Drag and Drop/Sortables: not accessible in the big
    libraries
    o You can hack extend toolkits by adding keypress
    event bindings
    

    View Slide

19. Our four techniques
    1. Use semantic markup and ARIA roles
    2. Associate content with descriptors
    3. Provide text alternatives
    4. Ensure keyboard access to all functionality
    

    View Slide

20. Are we doing it right?
    o Navigate the site/app without a mouse
    o Can you complete every form, navigate to any page?
    o Give yourself a custom stylesheet that overrides base
    styles
    o Turn off CSS
    o WAVE: Web Accessibility Evaluation Tool
    o JAWS has a 40-minute trial
    

    View Slide

21. Compassionate culture
    “Sympathetic consciousness of others' distress
    together with a desire to alleviate it.”
    —Merriam-Webster
    

    View Slide

22. Raising the bar
    o Video/audio captioning and transcripts
    o Care for color contrast
    o Use ARIA “live regions”
    o Eliminate time restrictions
    o Font scalability
    o Interactive element size
    o Clarity of interactive elements
    o Access keys
    o Skip links for repetitive content (nav)
    o Allow users to disable flashing content
    o Add breadcrumb trails
    o Give expect input formats
    o Link to or provide pronunciations
    o Allow undos or restores
    o Don’t disguise one element as another
    o Pursue accessibility certification
    

    View Slide

23. Resources
    o ARIA: http://www.w3.org/TR/wai-aria
    o WebAIM (Web Accessibility In Mind): http://webaim.org/
    o WAVE: http://wave.webaim.org/
    o SSB Bart Group: https://www.ssbbartgroup.com/index.php
    

    View Slide