Rethinking Accessibility: Role-Based Analysis of WCAG 2.0 - CSUN 2017

CSUN 2017, San Diego Bill Tyler March 2, 2017

Rethinking Accessibility: Role-Based Analysis of WCAG 2.0

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

The Problem

3

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

Typical Development Sequence (by Role)

Add A11y Here QA / A11y Testing

Developers

Content Author

Visual (Vx) Designer

Interaction (IX) Designer

Business Owner

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

The Assumptions

7

The Assumptions are:

Developers…

…code accessibility…

using “accessibility-specific” Knowledge.

8

Questioning the Assumptions

9

Three Questions for Each Success Criterion

Who? developer

When? coding

10

Who?

11

Testing Roles

12

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

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

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

RACI (RASCI) Modeling

Responsible – Owns the issue R Accountable – to Responsible “owner” A Supportive – but not accountable S

Consulted – to address issue C Informed – of results, but not consulted I

16

Source: http://www.valuebasedmanagement.net/methods_raci.html

Role Ownership Model

Primary – Individual role with “final approval” P Secondary – actively involved in decision S

Contributor – affect, but not deeply involved C

17

Example: SC1.4.1 Use of Color

Visual Designer Interaction Designer Business Owner

18

Is it the Developer?

Who?

19

No.

20

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

When?

22

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

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

Entry Point Level Model

Primary – single, most significant (typical) entry point P Secondary – other significant entry points S

Impact – other minor sources of design input I

25

When?

26

Is it Code?

No.

27

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

What?

29

Three Criteria Types

30

What?

31

Is it Accessibility?

No.

32

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

Examples

34

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

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

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

(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

(Bad) Example: “Missing alt attribute in <img>”

Notes: • Code reviews should already include code validation

SC4.1.1 Parsing

39

Changes

40

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

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

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

New Approach for New Projects

QA / A11y Testing

Developers

Content Author

Visual (Vx) Designer

Interaction (IX) Designer

Business Owner

ADD A11Y HERE

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

New Approach for Triage Projects

QA / A11y Testing

Developers

Content Author

Visual (Vx) Designer

Interaction (IX) Designer

Business Owner

ADDRESS A11Y HERE

47

Contact information:

Thank you.

Bill Tyler Sr. Digital Accessibility Engineer btyler@optum.com @billtyler

48