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

Everyone Should Be Able To Use Your Software: Accessibility for Balanced Teams

Everyone Should Be Able To Use Your Software: Accessibility for Balanced Teams

Given at PluralsightLIVE 2018 in Salt Lake City, Utah.

Much of the web is inaccessible or difficult to use. This hurts your user base, your market reach, and—most crucially—the people who use your products. Learn about the history and the basics of digital and web accessibility, as well as some ways to get started improving your products and services to be universally approachable and usable.

87efe879c4e351aef0cdaa310f866026?s=128

Raquel Breternitz

August 29, 2018
Tweet

Transcript

  1. None
  2. Accessibility for Balanced Teams Raquel Breternitz Senior Designer, Pivotal Labs

  3. OR…

  4. EVERYONE SHOULD BE ABLE TO USE YOUR SOFTWARE

  5. • Design a wheelchair ramp Design Prompt
 2min

  6. • Design a better way for both wheeled and walking

    people to enter a conference hall. Design Prompt
 2min
  7. It’s not enough to just be accessible. BEWARE THE COMPLIANCE

    MINDSET
  8. Accessible, not Inclusive Accessible AND Inclusive • Hard to find

    • Difficult to Navigate • Dangerous?? • Easy to find and use • Also helpful for: baby carriages, scooters… • Beautiful!
  9. Let’s talk history.

  10. Le Corbusier created “Le Modulor”—an able- bodied man of ‘average’

    height and dimension, around whom standardized design should revolve.
  11. None
  12. None
  13. Protesters took to the streets, smashing curbs to create their

    own accessible ramps.
  14. Time to do the same with inaccessible software.

  15. Some myths about digital accessibility

  16. MYTH #1 Accessibility is a fringe need.

  17. None
  18. None
  19. None
  20. We will all need different levels of access, whether now

    or later. WELL, ACTUALLY…
  21. Solving for the “extremes” makes better products for all.

  22. Accessibility makes design uglier and graphs harder. Myth #2

  23. None
  24. Piotr Kaczmarek (+Julie Rodriguez)

  25. The best design is the one that works best, not

    the one that ‘looks nicest.’ well, actually…
  26. Accessibility takes too long, so it’s not a business priority.

    Myth #3
  27. None
  28. None
  29. You can use an eraser on the drafting table, or

    a sledge hammer on the construction site.” Frank Lloyd Wright “
  30. The best workers and users will not fit your “default”

    well, actually…
  31. What do I do now? So…

  32. Empathy, empathy, empathy

  33. It’s the information era. Google it.

  34. https://accessibility-handbook.mybluemix.net/design/a11y-handbook/ http://accessibility.voxmedia.com/ https://accessibility.18f.gov/ Find great guides IBM Vox 18F

  35. Get everyone involved

  36. Design Desirability Product Viability Engineering Feasibility

  37. Setting up your problem space: • What are my best

    UX patterns? 
 What can I avoid for a more accessible solution?
 • Who’s your crisis scenario? 
 Whose needs will ensure you have the least friction for all other users? Map their journey.
 • Diversify your users! 
 Research with differently-abled people and ask for their pet peeves when working with your software or similar software.
 Design
 Desirability
  38. Design
 Desirability Testing Your Assumptions: • Order + Hierarchy: 


    Do the user journey’s actions make sense? 
 Can I tab through it easily? Can someone get stuck? • Cover the basics: 
 Does everything have enough contrast? 
 Is anything hidden in a hover state? 
 Am I using color alone? 
 Does my use of motion help or get in the way?
 Am I saying this in the simplest, most direct way?
 • Test with differently-abled users!

  39. Product
 Viability Setting up the team for success: • Learn

    to recognize accessibility issues
 When you test a story for acceptance, can you recognize accessibility issues? Can you bake them into your criteria? • Start with inclusion
 Help identify user bases that are being excluded in your existing product, and work to include them. Build accessibility into your stories and sprints. • Help source diverse users!
  40. Product
 Viability Advocating for accessibility: • Bring in stakeholders early

    and explain the ways accessibility is not optional 
 Establish that the product is not viable if it is not accessible. • Diversify markets through accessibility 
 Expand your user base to include disabled folks. Understand the concepts of temporary and momentary disability, and how they can expand your user base for accessible products. • Model the risk 
 How much does it cost to build accessibility into your cycles, versus how much it would cost to do it later? How about compared to a lawsuit?
  41. Engineering
 Feasibility Building the product • Use semantic HTML
 Define

    meaningful page components. Adopt “div-aphobia.” Make use of ARIA attributes (as option B) • Ensure images have descriptions for non-sighted users, and videos have captioning • Make sure every active element has a focus state that you can see • Beware of pre-packaging! 
 Often, out-of-the-box code snippets aren’t accessible (including copy/pasting from your own codebase)

  42. Engineering
 Feasibility Testing your work • Assistive Tech
 Familiarize yourself

    with screen-reader tech like VoiceOver, JAWS and NVDA. If you can, get an assistive technology lab and test out your software. If you can’t, improvise! • Content and naming
 Am I saying this in the simplest, most direct way? Do my error messages make sense and give the users a path forward? • Yes, you too
 Test with differently-abled users! • Automation
 Add automated a11y linter to your CI pipeline. Design automated tests with a11y in mind.

  43. • Get some reflexes
 Things you always check for: color

    contrast, tab order, hover styles, semantic html, etc.! • Find a favorite checklist
 A resource to check your gut: ARIA guides, WCAG standards, etc. • Build a posse: 
 Make an #A11y slack channel. Hire accessibility-literate people. Hold accessibility critiques. • F*ck the “golden path”: 
 No one uses your software in a perfect bubble. Complicate your scenarios. But Wait, There’s More: Extra Tips
  44. “Design depends largely on constraints.” Charles Eames

  45. BETTER FOR ALL!

  46. THANK YOU

  47. Any Questions?