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.

Transcript

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