One no, many yeses—sharing responsibility for accessibility
•Download as PPTX, PDF•
2 likes•601 views
This document discusses how to distribute responsibility for accessibility across project teams. It suggests that each part of a project team that can influence accessibility should do so positively. It provides examples of tactics that different roles like development, UX design, and content strategy can use to take responsibility for accessibility. The key message is that accessibility requires both distributing responsibility across roles and giving each role the authority to positively impact accessibility.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to One no, many yeses—sharing responsibility for accessibility
Similar to One no, many yeses—sharing responsibility for accessibility (20)
More from David Sloan
More from David Sloan (20)
Recently uploaded
Recently uploaded (20)
One no, many yeses—sharing responsibility for accessibility
- 1. One no, many yeses Sharing responsibility for accessibility David Sloan @sloandr Edinburgh UX Meetup, August 22nd 2016
- 2. A consultant’s perspective on accessibility in UX
- 3. Example of accessibility audit spreadsheet
- 5. The project manager with responsibility for accessibility but no clear idea of what is needed (and is possible)
- 6. The Rumpelstiltskin developer Image credit: Flickr user Shardayyy https://www.flickr.com/photos/shardayyy/6060374429
- 7. The accessibility specialist who speaks, but does anyone listen?
- 8. So. How can we best distribute responsibility—and authority— for accessibility?
- 9. One no. We will not deliver a digital product or service that hasn’t taken into account the needs of disabled people
- 10. Many yeses. Each part of a project team that can influence accessibility does so positively, and embraces accessibility as a key quality
- 11. Responsibility as part of accessibility maturity
- 12. Accessible Design Maturity Continuum An Accessible Design Maturity Continuum, uxfor.us/mature-it
- 13. “By concentrating solely on the bulge at the center of the bell curve we are more likely to confirm what we already know than learn something new and surprising.” Tim Brown, Change by Design
- 15. QA testing and responsibility for accessibility
- 16. Tactics • Test accessibility as early as possible • Automate accessibility tests that lend themselves to automation • Write tests that correspond to WCAG SCs – Keyboard operation – Name, role, state – Accessible notifications and updates – Semantic structure
- 17. Development and responsibility for accessibility
- 18. Tactics • Prioritize using native elements over relying on ARIA to polyfill accessibility • Focus on: – device-independent interaction – flexible display • Make sure accessibility informs selection and use of third party frameworks and players • Query designs that cannot be delivered accessibly
- 19. UX/UI design and responsibility for accessibility
- 20. Tactics • Visual design: colors, fonts, use of icons • UI design: Select appropriate UI patterns for interactions • Resources: – Style guides that reference best practice in accessibility – Annotate design artifacts with accessibility guidance • Focus on handing over designs that can be implemented accessibly
- 21. Content strategy and responsibility for accessibility
- 22. Tactics • Appropriate plain language • Consistency in: – Terminology – Alternative text provision • Labelling, instructions, error messages • Accessible video, audio, animation
- 23. User research and responsibility for accessibility
- 24. Tactics • Up-front user research: – Understand a problem space from a disabled person’s perspective – Include disability in personas, scenarios, user stories • Usability evaluation: – Focus on the user experience of key interactions for people with different disabilities
- 25. Project/product management and responsibility for accessibility
- 26. Tactics • Processes: – Ensuring all team members understand responsibility for accessibility – Ensuring there are exception processes for defining and dealing with unavoidable issues – Communicating progress and best practice • Standards: – Ensuring technical standards are established to be met by all code and content produces
- 29. Things to do now • Use accessibility audits to find out reasons for existence of barriers • Communicate progress internally and externally • Standardise on solutions, and share them • Identify accessibility points of contact, and grow a network • Use pilot projects to demonstrate value of integrating accessibility
- 31. “When people feel successful taking baby steps they often find themselves want to make big changes, including their environment.” —BJ Fogg
- 32. Want more? Accessibility Scotland, 16th September: http://accessibility.scot/ Accessibility Meetup Edinburgh
Editor's Notes
- One no, many yeses—with apologies to Paul Kingsnorth http://paulkingsnorth.net/books/one-no-many-yeses/
- I work for The Paciello Group (TPG). Too often we get called in when things have gone wrong.
- Accessibility often looks like this—an audit spreadsheet documenting failures
- Personas we encounter in our work, an indication that responsibility for accessibility is not adequately distributed
- Don’t panic!
- Asked to turn ssss—straw into gold
- Dr Seuss’s The Lorax speaks for the trees, but nobody listens. The Accessibility Lorax speaks for disabled people, but who listens?
- Identify Auditing and repair (if possible), Focusing on conformance with standards Responsibility is QA/Dev Prioritise Still auditing and repairing, but focus is on key user journeys, task completion People over standards Responsibility moves to include UX/PM Inject Adding accessibility into design and development processes and practices Responsibility widened to include: visual design, content authors Integrate Accessibility influences innovation, service/product definition
- Disability as a trigger for innovation
- Executives Marketing and branding HR Procurement IT
- Draft matrix mapping WCAG SCs to roles
- Persuasive design principles
- Dave