Role-Based Accessibility in Government
•Download as PPT, PDF•
9 likes•2,413 views
The document discusses role-based accessibility in government projects. It argues that accessibility is everyone's responsibility, not just that of an accessibility consultant. Following the WCAG 2.0 POUR principles of accessibility, each role on a project, from managers to developers to writers, shares responsibilities to ensure projects are perceivable, operable, understandable and robust. The document provides examples of accessibility tasks for each role and advocates for collaboration across teams to integrate accessibility throughout the entire design and development process.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Role-Based Accessibility in Government
Similar to Role-Based Accessibility in Government (20)
More from Angela M. Hooker
More from Angela M. Hooker (11)
Recently uploaded
Recently uploaded (16)
Role-Based Accessibility in Government
- 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
Editor's Notes
- Some think if I’ve ticked all the boxes that the project is accessible. Done. “Why do more?”
- Instead of realizing that accessibility belongs in every step of a project
- Some people forget to consider all disability types.
- Automated accessibility testing tools such as … Tools can’t completely determine if a project is accessible—they only point to flags to check
- Your projects might suffer because one person is the accessibility champion. The recurring theme I hear throughout government is that one person is responsible for accessibility.
- Since many accessibility specialists get the work at the end of the project, it’s a never-ending cycle—one person can’t do it all at the end
- Don’t panic because I said that you need a team, because …
- You already have a team!
- The Section 508 refresh (see http://www.access-board.gov/sec508/refresh/draft-rule.htm) uses WCAG 2.0 guidelines
- Denis Boudreau of Coopérative AccessibilitéWeb presents on and promotes this topic Developed a tool based on WCAG 2.0; separates responsibilities into manageable blocks
- Upper management: I propose that there’s one other part that the tool doesn’t mention, simply because of the scope of the standard
- Tasks overview of each role or point in the process; note that some tasks overlap Some of this is technical Each role has a number of guidelines; they’re not evenly divided—it depends on the requirement Also, while it might seem that some roles have a large number of guidelines, some guidelines merely expand upon the depth of accessibility of an item—more work
- Conformance and accessibility: You can check the boxes, but still have an inaccessible, unusable product Assess the impact that the platforms, APIs, frameworks, etc. will have on accessibility, and choose appropriate ones
- Oversee the entire process As with any project, accessibility success falls on your shoulders Determine the degree of accessibility Document EVERYTHING: with lawsuits, you need to cover yourself and your organization
- 9 guidelines Developers, designers, content managers, usability specialists
- 9 guidelines Can be a content manager, librarian, and/or usability specialist to serve as info architect(s)
- 36 guidelines Designers, developers, usability specialists, content managers
- 32 guidelines Designers, developers—discuss
- Usually people wait for the quality assurance stage to use automated accessibility tools, but it’s helpful to do it now I recommend using some of the free accessibility toolbars for this purpose
- 21 guidelines “Other” content: text labels, error messages, player controls Be sure to have your content reviewed by someone well versed in plain language AND familiar with the needs of people with cognitive impairments
- 59 guidelines—don’t panic; you’ve dealt with many of these in the prototyping phase, so not much is new Also appropriate to use the accessibility toolbars for checking potential problems Validate code
- ALL 61 guidelines belong to the QA process At this point, the testing should be minimal—if the content is well written, the design is clear, the development done properly, then the testing at this point should be manual review, accessibility tools, assistive technology Cross-browser, cross-platform—what is accessible in one browser isn’t necessarily accessible in all or on other platforms Plain language specialist—not the person who wrote the content (editors need editors); someone with a development and/or design background to test
- Your stance is key for a successful accessibility program. If you react positively to accessibility, then we will, too. If you are negative toward accessibility, then we’ll spend too much figuring out how to get your buy-in. OR, we won’t do anything for accessibility.
- Requires a change in culture If there’s tension among your team members, do something about it Don’t be wimpy; manage the situation (but don’t micromanage)! Empower them to make the best decisions for your project’s users—not decisions that bow to the politics of your organization
- What if you have an outside vendor building a project for you—what do you do?
- You’ll need knowledge of the standards and ensuring functional accessibility If the vendor is responsible for delivering an accessible project (including testing) without any help from an accessibility specialist in your agency… They may not understand accessibility; they might think (as many people do) that using an automated accessibility tool will solve all accessibility issues
- Cooperating and negotiating I like to teach people not only how to cope, but encourage them to build relationships with other team members or departments so they can effect change in the organization's approach to accessibility, simply because this is radical and you’ll need management approval.
- It’s not going to be easy: people don’t always want to change—they’re comfortable; they might feel threatened; they don’t like being told that they’ve done something wrong; they might oppose you Be open about what you’re trying to do; let people know that these changes will benefit everyone Separate yourself from the process—it’s not about winning
- Show your colleagues that without accessibility, they can’t do their job if they had a temporary injury or developed a disability—empathy Curb cuts in sidewalks—everyone uses them; it’s the same with IT accessibility