Role-based analysis of WCAG 2.1 success criteria further emphasizes how designers – not developers – own and make the decisions that impact website accessibility.

1. Bill Tyler
Principal Digital Accessibility Engineer
Accessibility Center of Excellence, Optum Technology
CSUN 2019, Anaheim
Thursday, March 14, 2018
Role-Based
Accessibility
Update:
WCAG 2.1 & More
@billtyler
btyler@optum.com
SlideShare: http://bit.ly/xxxxxx

2. My Experience
35+ yrs. of UI/UX Design and Development
12+ yrs. in medical devices
16+ yrs. in plans and providers
2X dot-com survivor
Started Web 1996
Started in Accessibility 2002
Full time Accessibility Engineer since December 2013
Material Presented
Update on role-based analysis of WCAG (2.0) since January 2013
including CSUN 2017 presentation on this same topic
Analysis of WCAG 2.1 starting with working draft of September 2017
Background
2

3. Agenda
Role-Based Accessibility
• WCAG Role-Based Background
– The Usual Approach
– The Assumptions
• Questioning the Assumptions (with WCAG 2.1 updates)
– Who owns them?
– What are they?
– When are decisions made?
• Shift Left: Applying Role-based Accessibility
• & More – Updates since 2017
– W3C Working Group Initiative

4. Role-Based
Accessibility
Overview

5. No one thinks about accessibility
… except the accessibility expert
Accessibility testing comes at end of development
…with testing done by the accessibility expert
All issues found are directed to developers to fix
…with help from accessibility expert
Final Result: “Sort of” Accessible Result
Problem: The Usual Approach to Accessibility
5

6. 6
Typical Development Sequence (by Role)
Add
A11y
Here

7. 7
There’s something very wrong with this
Add
A11y
Here

8. Need to Shift Left
QA & A11y – too little, too late
• Roles are focused on testing – not design
– Testing is at end of Software Development Lifecycle (SDLC)
– Design is at start
Input needed earlier
• Who needs to know what when?
– Who: Role
– What: Knowledge
– When: Deliverable
• Testing needed when design decisions are made, not code
• Role-based analysis helps provide rationale for more a11y
training of all roles

9. The
Assumptions
9

10. The Assumptions are:
Developers…
…code accessibility…
using “accessibility-specific”
knowledge.
10

11. Questioning
the
Assumptions
11

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

13. Who?
13

14. Analysis Process – Ownership Roles
Question 1: Who owns it, and to what level?
The Design 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
(section) and
small (words)”
• Content
proofreader
• Includes time-
based media
• Script writer
• Audio and
video file
creator
• Front-End
Programmer
• Last stop
before testing
• Primary target
for all defects

15. Analysis Process – Ownership Levels
Question 1: Who owns it and to what level?
The Levels
• Not Standard RACI model
– Responsible
– Accountable
– Consulted
– Informed
• Levels of Ownership Used
– Primary – The owner ultimately responsible for the decision
– Secondary – Actively involved with primary owner
– Contributor – “Gives some input” but is not deeply involved

16. Is it the Developer?
Still “no.”
Who?
16

17. WCAG 2.1 Primary Ownership (New SC only)
User Experience Designers #1
• UX Designer: +8 criteria (67%)
• Visual Designers: +3 criteria (25%)
• Content Author: +1 criterion (8%)

18. 18
WCAG 2.1 Primary Ownership
UX Designer: 44% (22)
Content Author: 20% (10)
Visual Designer: 18% (9)
Developer: 16% (8)
Business Owner: 2% (1)
Observations
Developers have less ownership
• Developers only own a little more
than 1 of 6 criteria (was 1 of 5)
• Developers moved from third to
fourth in ownership
• WCAG 2.1 adoption should
increase training for all roles

19. What?
19

20. Analysis Process – Type
Question 2: What is it?
• Accessibility-specific Knowledge
– Non-accessibility roles probably do not know these
– Additional training, often minor, will be needed for roles
• Best Practice
– Roles should know these and already do them, especially primary owner
– Minor adjustments maybe needed to revise or apply more of them
• Standard Feature
– Something so common roles will make the right choice with little or minor
changes

21. What?
21
Is it Accessibility?
Still “no.”

22. WCAG 2.1 Types (New SC only)
Best Practices still edge out Accessibility
• Best Practices: +7 criteria (58%)
• Accessibility-specific Knowledge: +5 criteria (42%)

23. 23
WCAG 2.1 Success Criteria Types
Best Practices: 54% (27)
Primarily A11y: 40% (20)
User Stories: 6% (3)
Observations
• Percentages barely changed
from WCAG 2.0
• Still over half of decisions are
best practices
• Accessibility training should
continue to focus on topics
roles don’t know

24. When?
24

25. Analysis Process – Introduction: Deliverables
Question 3: When is it made?
• When is the decision first made?
– Identify first deliverable or point in product lifecycle
– Also identify secondary and less common cases
• 6 Deliverables
1. User Story / Requirements core specifications and functionality
2. Wireframes structure of page, interface, interactions
3. Style Guides site presentation, branding, colors, logos, layout
4. Design Comps page or feature final presentation
5. Content text, terminology, includes video and audio
6. Code front-end development: HTML, CSS, JavaScript

26. When?
26
Is it Code?
Still “no.”

27. WCAG 2.1 Deliverables (New SC only)
Still NOT the code…
• User Story / Requirements : +8 criteria (67%)
• Style Guide: +3 criteria (25%)
• Content: +1 criterion (8%)

28. 28
WCAG 2.1 Deliverables
Wireframes: 38% (19)
User Stories: 34% (17)
Style Guides: 20% (10)
Code: 4% (2)
Content: 4% (2)
Design Comps: “0%”
Observations
• 96% of decisions before code
• Wireframes down from over 50%
• User Stories up to full third (was 24%)
• Full fifth in style guide (was 18%)
• Code now equal to Content at 4%

29. Examples
29

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

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

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

33. (Bad) Example: “Blue on ‘light’ blue” to indicate button or link
Notes:
• One of several Visual Designer primary ownership crits
• Visual Designer has no secondary ownership
SC1.4.11 Non-Text Contrast
33

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

35. Looking for WCAG 2.0-only Analysis?
See earlier presentations
• Rethinking Accessibility: Role-Based Analysis of WCAG 2.0
• Accessible by Design (2018)
– YouTube: https://www.youtube.com/watch?v=8ovXWPxkA4c
– SlideShare: bit.ly/2HJea3e
• CSUN (2017)
• Minnebar (2015)
• UXPA-MN (2014)

36. Applying Role-based
Accessibility
Shifting Left
36

37. Opportunities to improve efficiency and quality for both
new and existing sites
Involvement should be early in the design process
• Includes project intake
Distribute and assign ownership (resolution) to other
roles
All roles should have training tailored to their existing
knowledge and skills
Checklists for reviewing all design deliverables before
sign-off
Shift Left: General Changes
37

38. 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
Shift Left: Accessibility Role
38

39. 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
Success criteria ownership applies most effectively
applied to new projects and design cases
Shift Left: New Projects
39

40. 40
Shift Left: Accessibility in New Projects
QA / A11y Testing
Developers
Content Author
Visual Designer
UX Designer
Business Owner
ADD
A11Y
HERE

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

42. 42
Shift Left: Accessibility in Project Triage
QA / A11y Testing
Developers
Content Author
Visual Designer
UX Designer
Business Owner
ADDRESS
A11Y HERE

43. Checkpoint ownership does not equal success criteria
ownership
Checkpoints used in testing can be heavily impacted by
how they are written
• The more detail in the checkpoint the more clearer the ownership
• Multiple checkpoints under same SC can have different owners
Remediation testing often assumes intended design
understood
• Assignment of issues affected original design decisions
• If incorrectly or not documented at all – Designers & Author roles likely own
• If documented correctly – Developer likely owns
Ownership Differences New vs. Existing Sites
43

44. Updates since 2017
“More”
44

45. 2017 CSUN Presentation on WCAG 2.0 led to:
Met Denis Boudreau (Deque)
• Discussing role-based work in common
Accessibility Roles & Responsibilities Mapping (ARRM)
• W3C Initiative in Education & Outreach working group (EOWG)
• 2018 officially joined EOWG as invited experts
• Project plan extending into 2020
ARRM Deliverables
• Expanded role definitions
• DIY decision tree (flowchart) for teams of all types and roles
• Large set of examples applied to checkpoints in addition to SC
• Many, many more documents

46. Questions?
46

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

48. 48