role-based accessibility in government

U.S. General Services Administration

Role-Based Accessibility in Government:

Everyone’s Responsibility

#RoleBasedA11y

Angela M. Hooker

DigitalGov University, November 2012

Hi! I’m Angela, your accessibility consultant.

2

You don’t need me …

3

You don’t need me … as much as you think.

4

We accessibility consultants are tasked with all the work to make sure projects are accessible.

5

Often, people think we only use a checklist, after a project is fully developed, to test for accessibility.

6

We’ve treated accessibility as an issue only relevant to development.

7

Or, sometimes people think that if we “test with JAWS” …

8

Or, some think if I run a project through WAVE, or the Web Accessibility Toolbar, or FireEyes, or aChecker, or …

9

But …

10

But … it’s not working.

11

One person can’t do it all …

12

One person can’t do it all … you need an accessibility team …

13

One person can’t do it all … you need an accessibility team … that you already have.

14

The key is your current staff can work together to create accessible projects.

15

It doesn’t matter if you’re … in upper management.

16

It doesn’t matter if you’re … a developer.

17

It doesn’t matter if you’re … a project manager.

18

It doesn’t matter if you’re … a usability specialist.

19

It doesn’t matter if you’re … an accessibility specialist.

20

If we’re to produce accessible projects …

21

We must change our process!

22

We must change our process! But, how?

23

… by using “P-O-U-R” principles from the Web Content Accessibility Guidelines (WCAG 2.0)

24

What is POUR?

WCAG 2.0 principlesof accessibility:

PerceivableOperableUnderstandable Robust

25

Accessibility responsibilities

• Accessibility Responsibility Breakdown

• Based on WCAG 2.0• Canadian

Government• Coopérative

AccessibilitéWeb

26

Accessibility responsibilities

• Project management• Analysis• Information architecture• Interaction design• Graphic design, including mockups• Prototype• Editing (content development)

27

Accessibility responsibilities

• Development• Quality assurance—testing• Upper management

28

Tasks

29

Project management

• Integrate and plan accessibility• Oversee tasks and responsibilities• Choose technical and functional

criteria• Distinguish between accessibility and

conformance with the law/guidelines• Know the limitations of the tools• Assess technology platforms’ impact

30

Project management

• Responsibilities from WCAG 2.0–Overseer: all guidelines–Successful results–Degree of accessibility–Documentation

31

Analysis

• Analysis of platforms, interfaces, etc.

• Solve problems/consider user interaction and behaviors– Prevent errors– Determine what happens upon error– When items receive focus/context– Timing, re-authentication– Contextual help

32

Information architecture

• Structure of pages and content–Relationships among info types–Page titles–How to navigate to each page–Headings and labels (including forms)

33

Interaction design

• Scripting, content changes, interactivity:–Design conveys content relationships—

headings, spacing, lists–Content is perceivable without regard

to location, size, shape, color–Keyboard navigation–Flashing content—3 times per second–Minimize errors

34

Graphic design

• The overall look and feel of every interface—including navigation, content

– Consistent behavior throughout– Logical design/reading order– Color contrast– Real text instead of graphics of text– Font size

35

Prototyping

• Building HTML and CSS templates–Separation of style from content–Page language–Alt text for all non-text items–Pages parse properly (compatibility)–Keyboard navigation

36

Content/editing

• Authoring the site’s written content, alternative text, and other content–Content structure–Plain language–Consistent behavior–Prevent errors/error text–Captions and audio descriptions

37

Development

• Integrating HTML and CSS; programming scripts and applications–Building from the prototype–Progressive enhancement/behavior–Captioning multimedia–Widgets–APIs

38

Quality assurance

• Verifying that the team followed the guidelines properly–Test with accessibility tools–Manual review/read code–Test with assistive technologies–Review content for readability

39

Quality assurance

• Checklists versus usability and access:–Use a checklist when testing, so you don’t forget anything

–You can satisfy every requirements and still have accessibility problems

–Don’t lose sight of your users’ ability to access your info and complete tasks

40

Upper management: You set the tone in your organization.

41

Upper management’s role

• Support accessibility• Require accessibility• Encourage teamwork• Make your environment conducive

to teamwork• Trust your team—let them do their

jobs and empower them

42

What about vendors?

43

Projects by vendors

• Make sure your contract requires accessible products built to your specifications and subject to your interpretation of accessibility

• Ask to see their process for building in accessibility, and require documentation for your project

• Schedule checkpoints where you verify their work

44

Pitfalls to avoid and lessons to learn

45

It doesn’t work

• Not training team members in accessibility

• Having the accessibility champ do all the testing at every interval

• Putting the work before relationships• Forgetting that guidelines overlap• Not involving upper management• Thinking the process won’t evolve

46

It doesn’t work

• Focusing only on “checklist accessibility” rather than “functional accessibility”

• Allowing the accessibility program to be personality driven—it must outlive you and me

47

Cooperating with your colleagues

48

You and your colleagues

• What can you do to bridge the gap between people, departments, and philosophies?–Sometimes an accessibility consultant has to be a counselor, evangelist, educator, and/or a maverick (among other roles)

–Make sure you’re not being a nag

49

You and your colleagues

–Stand against any existing “us versus them” vibe

–Create a “no shame; no blame” atmosphere

–Take every opportunity to educate your colleagues

50

You and your colleagues

• Negotiate with your team and management– Come armed with research, statistics,

analytics—whatever they’ll respond to– Think of it as finding the best outcome for

users—it’s not about winning– Be forthright, but be careful– See Carol Smith’s “

Empower Yourself: Negotiate for the User”

51

You and your colleagues

• You know these principles, but we assume management does, too—they might not–Save time: It takes time to implement accessibility, but it’s faster than remediating

–Save money: It takes money to implement accessibility, but it’s cheaper than remediating

52

You and your colleagues

– It’s the law–It’s the right thing–You might need it

53

Final words

54

In a nutshell …

• Start small• One person may have many roles• Adapt this process to your organization

and its culture—keep it evolving• Build rapport within and among teams—

talk• Negotiate—don’t be afraid• It’s about what’s best for users

55

Resources

56

P-O-U-R

• WCAG 2.0 Principles of Accessibility, World Wide Web Consortium

• Constructing a POUR Website, WebAIM

57

Project management

• Integrating Accessibility in the Organization’s Web Development Life Cycle, Denis Boudreau

• Accessibility for Project Managers, Henny Swan

• Managing Accessibility Compliance in the Enterprise, Karl Groves

• Plan for Accessibility, Option Keys

58

Project management

• Planning Accessibility, Government of Canada

• Just Ask: Integrating Accessibility Throughout Design, Shawn Lawton Henry

• Disability types/issues– Visually, cognitively, motor, and hearing

impaired; neurological/seizure disorders; elderly and aging

59

Writing content

• Accessibility for Web Writers, 4 Syllables

• Content and Usability: Web Writing, WebCredible

• Clear Helper – resources to produce accessible content for people with cognitive disabilities

• Readability Test, Juicy Studio

60

Design

• Web Accessibility for Designers, WebAIM

• Just Ask: Integrating Accessibility Throughout Design, Shawn Lawton Henry

• Design Considerations, WebAIM

61

Design

• Color Contrast Checker, WebAIM• Accessibility Color Wheel• Vischeck Color Contrast Photoshop

Plug-in• Trace Photosensitive Epilepsy Anal

ysis Tool (PEAT) – tests flashing content

62

Prototyping/development

• Build a library of accessible code!• Use code generators (see the

tools at Accessify)• W3C Mobile Web Best Practices• Web Accessibility Gone Wild,

WebAIM

63

Prototyping/development

• Accessibility testing tools– Juicy Studio Accessibility Toolbar (Firefox)—reviews ARIA, data tables, and color contrast

–FireEyes, Deque–WAVE, WebAIM–Web Accessibility Toolbar (WAT; IE and Opera), The Paciello Group

64

Quality assurance

• Accessibility Evaluation Resources, W3C-Web Accessibility Initiative

• Evaluation, Testing, and Tools, WebAIM

• WCAG 2.0 Checklist, WebAIM• Wickline Color Blind Web Page

Filter

65

Quality assurance

• Favelets for Checking Web Accessibility, Jim Thatcher

• Trace Photosensitive Epilepsy Analysis Tool (PEAT) – tests flashing content

• Evaluating Websites for Accessibility, Web Accessibility Initiative (WAI)

66

Quality assurance

• Central Office of Information, Delivering Inclusive Websites

• Establishing a Screen Reader Test Plan, Henny Swan

• Web Accessibility Gone Wild, WebAIM

• Template for Accessibility Evaluation Reports, W3C-WAI

67

Thank you!

Angela Hookerangela.hooker@gsa.gov@AccessForAll

68