1. U.S. General Services Administration
Role-Based Accessibility in
Government:
Everyone’s Responsibility
#RoleBasedA11y
Angela M. Hooker
DigitalGov University, November 2012

2. Hi! I’m Angela, your
accessibility consultant.
2

3. You don’t need me …
3

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

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

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

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

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

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

10. But …
10

11. But … it’s not working.
11

12. One person can’t do it all …
12

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

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

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

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

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

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

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

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

21. If we’re to produce accessible
projects …
21

22. We must change our
process!
22

23. We must change our
process! But, how?
23

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

25. What is POUR?
WCAG 2.0
principles
of
accessibility:
Perceivable
Operable
Understandable
Robust
25

26. Accessibility responsibilities
• Accessibility Responsibility Breakdown
• Based on WCAG 2.0
• Canadian
Government
• Coopérative
AccessibilitéWeb
26

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

28. Accessibility responsibilities
• Development
• Quality assurance—testing
• Upper management
28

29. Tasks
29

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

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

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

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

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

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

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

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

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

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

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

41. Upper management: You set
the tone in your
organization.
41

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

43. What about vendors?
43

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

45. Pitfalls to avoid and
lessons to learn
45

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

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

48. Cooperating with your
colleagues
48

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

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

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

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

53. You and your colleagues
–It’s the law
–It’s the right thing
–You might need it
53

54. Final words
54

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

56. Resources
56

57. P-O-U-R
• WCAG 2.0 Principles of Accessibility
, World Wide Web Consortium
• Constructing a POUR Website,
WebAIM
57

58. Project management
• Integrating Accessibility in the Organization’s , Denis Boudreau
• Accessibility for Project Managers,
Henny Swan
• Managing Accessibility Compliance in the Enterprise
, Karl Groves
• Plan for Accessibility, Option Keys
58

59. Project management
• Planning Accessibility, Government of
Canada
• Just Ask: Integrating Accessibility Throughout , Shawn Lawton Henry
• Disability types/issues
–Visually, cognitively, motor, and hearing
impaired; neurological/seizure disorders;
elderly and aging
59

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

61. Design
• Web Accessibility for Designers,
WebAIM
• Just Ask: Integrating Accessibility Throughout , Shawn Lawton Henry
• Design Considerations, WebAIM
61

62. Design
• Color Contrast Checker, WebAIM
• Accessibility Color Wheel
• Vischeck Color Contrast Photoshop Plug-• Trace Photosensitive Epilepsy Analysis Tool
(PEAT) – tests flashing content
62

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

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

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

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

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

68. Thank you!
Angela Hooker
angela.hooker@gsa.gov
@AccessForAll
68