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

Everyone Should Be Able To Use Your Software: A...

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.

Raquel Breternitz

August 29, 2018
Tweet

Other Decks in Design

Transcript

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

    people to enter a conference hall. Design Prompt
 2min
  2. 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!
  3. Le Corbusier created “Le Modulor”—an able- bodied man of ‘average’

    height and dimension, around whom standardized design should revolve.
  4. The best design is the one that works best, not

    the one that ‘looks nicest.’ well, actually…
  5. You can use an eraser on the drafting table, or

    a sledge hammer on the construction site.” Frank Lloyd Wright “
  6. 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
  7. 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!

  8. 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!
  9. 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?
  10. 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)

  11. 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.

  12. • 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