1. CSUN 2017, San Diego
Bill Tyler
March 2, 2017
Rethinking Accessibility:
Role-Based Analysis of
WCAG 2.0

2. My Experience
30+ yrs. of UI/UX Design & Development
12+ yrs. in medical devices
15+ yrs. in plans & providers
2X dot-com survivor
Started Web 1996
Started Accessibility 2002
Materials Presented
3+ yrs. of ongoing accessibility research & analysis at Optum Technology
Background
2

3. The
Problem
3

4. No one thinks about accessibility
… EXCEPT the accessibility expert
Accessibility testing comes at END of development
…and LONG after other design decisions are made
All issues found are directed to DEVELOPERS to fix
…with help from accessibility expert
Final Result: “Sort of” Accessible Result
The Problem: The Usual Approach to Accessibility
4

5. 5
Typical Development Sequence (by Role)
Add
A11y
Here QA / A11y Testing
Developers
Content Author
Visual (Vx) Designer
Interaction (IX) Designer
Business Owner

6. 6
There’s something very wrong with this picture
Add
A11y
Here QA / A11y Testing
Developers
Content Author
Visual (Vx) Designer
Interaction (IX) Designer
Business Owner

7. The
Assumptions
7

8. The Assumptions are:
Developers…
…code accessibility…
using “accessibility-specific”
Knowledge.
8

9. Questioning the
Assumptions
9

10. Three Questions for Each Success Criterion
Who?
developer
When?
coding
10

11. Who?
11

12. Testing Roles
12

13. Decision Making Roles
• Standard
agile role
• Project
initiator
• Requirements
definer
• Result
approver
• Business
liaison
• Requirement
author
• Wireframe
creator
• UX / Usability
expert
• Presentation
owner
• Style expert
• Layout
creator
• Design
enforcer
• Style guide
author
• Design comp
artist
• Image file
producer
• Author of All
Text “Large &
Small”
Large: sections
Small: words
• Content
proofreader
• Includes time-
based media
• Script writer
• Audio & video
file creator
• Front-End
Programmer
• Last stop
before testing
• Primary target
for all defects
13

14. Of a like mind…
14
Accessibility Responsibility Breakdown
• Denis Boudreau / W3C / WAI-Engage Community, April 2012
Source: http://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown
– 12 Roles
Interactive WCAG 2.0
• Jeremy Fields / Viget, January 2015
Source: http://code.viget.com/interactive-wcag/
– 5 Roles
Accessibility is Everyone’s Job: A Role-Based Model for
Teams
• Mark Palmer / Simply Accessible, June 2016
Source: http://simplyaccessible.com/article/role-based-a11y
– 6 Roles

15. Differences in our approach
15
Decision Ownership
• Roles not just identified as part of process
RACI Model Levels
• Levels of ownership based on impact to deliverable
Additional Analysis
• Examined (much) more than just ownership (or phases)
Actionable
• Apply to enterprise distribution of work and responsibility

16. RACI (RASCI) Modeling
Responsible – Owns the issueR
Accountable – to Responsible “owner”A
Supportive – but not accountableS
Consulted – to address issueC
Informed – of results, but not consultedI
16
Source: http://www.valuebasedmanagement.net/methods_raci.html

17. Role Ownership Model
Primary – Individual role with “final approval”P
Secondary – actively involved in decisionS
Contributor – affect, but not deeply involvedC
17

18. Example: SC1.4.1 Use of Color
Visual Designer Interaction Designer Business Owner
18

19. Is it the Developer?
Who?
19

20. No.
20

21. 21
Primary Success Criteria Ownership
IX Designer: 37% (14)
Content Author: 24% (9)
Developer: 21% (8)
Vx Designer: 16% (6)
Business Owner: 3% (1)
Observations
Developers only own 1 in 5 criteria
Developers are third in ownership
Need to work with other roles

22. When?
22

23. Software Design Lifecycle Entry Points
Code (front-end development: HTML, CSS, JavaScript)
Content (text, terminology, and includes video & audio)
Design Comps (page or feature final presentation)
Style Guides (site presentation, branding, colors, logos)
Wireframes (structure of page, interface, interactions)
User Story / Standard Requirements
23

24. Of a like mind…
24
Accessibility Responsibility Breakdown
• Government of Canada, April 2014
Source: https://wet-boew.github.io/themes-dist/GCWeb/demos/arb-rra/arb-rra-en.html
– 7 “Production Phases”
As with roles, we went further and added levels
• Levels based upon expected frequency

25. Entry Point Level Model
Primary – single, most significant (typical) entry pointP
Secondary – other significant entry pointsS
Impact – other minor sources of design inputI
25

26. When?
26
Is it Code?

27. No.
27

28. 28
Primary Success Criteria Entry Points
Wireframes: 50% (19)
User Story/Std. Req.: 24% (9)
Style Guides: 18% (7)
Code: 5% (2)
Content: 2% (1)
Design Comps: “0%”
Observations
95% of decisions come before code
Half are defined in wireframes
A quarter are in user stories
Nearly a fifth in style guide

29. What?
29

30. Three Criteria Types
30

31. What?
31
Is it Accessibility?

32. No.
32

33. 33
Success Criteria Types
Best Practices: 53% (20)
Primarily A11y: 39% (15)
User Stories: 8% (3)
Observations
• Over half of decisions are
best practices roles should
already know
• Accessibility training could
focus on topics they don’t

34. Examples
34

35. Example (of what NOT to do): “Press the green button on the right.”
Notes:
• Rare instance of single owner, no secondary owner or contributor
• Example of a “Never” event
SC1.3.3 Sensory Characteristics
35

36. Example: “Session times out in 5 minutes. Continue? Yes / No”
Notes:
• Business Owner’s only primary ownership criterion
• Rare Standard Requirement case
SC2.2.1 Timing Adjustable
36

37. Example: Search, Site Map, Breadcrumbs, Top-nav, In-page links
Notes:
• One of several Interaction Designer-only primary criteria
SC2.4.5 Multiple Ways
37

38. (Questionable) Example: “Blue on ‘light’ blue”
Notes:
• One of several Visual Designer primary ownership crits
• Visual Designer has no secondary ownership
SC1.4.3 Color Contrast (Minimum)
38

39. (Bad) Example: “Missing alt attribute in <img>”
Notes:
• Code reviews should already include code validation
SC4.1.1 Parsing
39

40. Changes
40

41. Opportunities to improve efficiency and quality for both new
and existing sites
Involvement should be early in the design process
• Includes project intake
• For more:
Success Criteria Dependencies & Prioritization: Implication & Use
Sean Kelly, Bill Tyler
3:20PM Old Town AB
Distribute and assign ownership (resolution) to other roles
All roles should have training tailored to their role
Checklists for reviewing all design deliverables before sign-off
Changes: General
41

42. Distribute most common issue remediation to roles
• Agile teams become more self-sufficient
• Design roles make better decisions preventing issues at the start
• Trained team members can identify and return issues at earlier steps
• Train QA to do basic a11y testing
Accessibility SME can focus on difficult issues that require
their expertise
Net Result: Reduce the total number of accessibility
SMEs across the enterprise
• Important for organizations with hundreds of sites
Changes: Accessibility Role
42

43. Integrate accessibility early in the design process
Distribute accessibility ownership to key decision makers
Targeted, role-based training
• Refresher on existing best practices
• Accessibility training only on topics they own or impact
Changes: New Projects
43

44. 44
New Approach for New Projects
QA / A11y Testing
Developers
Content Author
Visual (Vx) Designer
Interaction (IX) Designer
Business Owner
ADD
A11Y
HERE

45. As with new projects, all roles should have targeted role-
based training
As issues are found they should be directed to the correct role
owner, not simply the developer
• Issues directed to specific roles will demonstrate how previous
decisions impacted accessibility
Changes: Triage of Existing Sites
45

46. 46
New Approach for Triage Projects
QA / A11y Testing
Developers
Content Author
Visual (Vx) Designer
Interaction (IX) Designer
Business Owner
ADDRESS
A11Y HERE

47. 47

48. Contact information:
Thank you.
Bill Tyler
Sr. Digital Accessibility Engineer
btyler@optum.com
@billtyler
48