Practical First Steps for Achieving Web Accessibility and Avoiding Liability
•Download as PPTX, PDF•
0 likes•643 views
This webinar will provide you with a guidance-based approach to injecting accessibility into your web development process.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Practical First Steps for Achieving Web Accessibility and Avoiding Liability
Similar to Practical First Steps for Achieving Web Accessibility and Avoiding Liability (20)
More from 3Play Media
More from 3Play Media (20)
Recently uploaded
Recently uploaded (20)
Practical First Steps for Achieving Web Accessibility and Avoiding Liability
- 1. 1 Practical First Steps Toward Web Accessibility and Reducing Legal Risk https://convergeaccessibility.com
- 2. 2 Presenter Jeff Singleton Co-Founder of Converge Accessibility • Over two decades of evaluating and supporting information and communication technology • In depth knowledge of accessibility guidelines, standards and assistive technologies • Lectures on accessibility topics at National and International Disability and Technology Conferences
- 3. 3 Key Takeaways • Why an Accessibility Statement is important • Where to being in addressing website accessibility • How to create a self-sustaining culture of web accessibility
- 5. 5 How to Create an Accessibility Statement Accessibility Policy • Sets forth the organization’s commitment • Identifies plans for achieving and ensuring accessibility Ma Contact Information • A telephone number or email address • Information about response time • Critical to follow through to achieve “effective communication” per ADA Best Practice: Feedback Mechanism • Optional, but useful • Online form or email contact • Encourages feedback on accessibility and the organization https://www.w3.org/WAI/planning/statements/
- 6. 66 Manual Testing of Key Use Cases and Templates
- 7. 7 Getting Started Creating your plan of attack • Ask yourself, “why do people go to our website?” • Identify most visited page • Identify page templates • Identify critical user scenarios • Even complex sites often reduce to less than 30 pages that require manual testing.
- 8. 8 Manual Testing Requires multiple passes • Keyboard • Screen Reader • Screen Magnifier • Voice Command
- 10. 10 What to Test: “High Risk” Accessibility Issues Four key accessibility issues • Missing alt text for images • Missing alt text in image maps • Improper data table markup • Missing label in forms Why automated testing should include these • Common to most web accessibility complaints • Likely used by private plaintiffs in “drive by” web accessibility lawsuits
- 11. 1111 Creating a Culture of Accessibility
- 13. 13 Better Requirements … but the real secret is 1.Defined. How those requirements are defined (and for whom)? 2.Delivered. How those requirements are allocated and delivered?
- 14. 14 STEP 4 Create Training and Resources for Each Core Concept STEP 3 Parse Role- Specific Guidance into Job-Specific Checklists STEP 2 Further Break Core Concepts down to Role- Specific Guidance STEP 1 Break WCAG into “Core Concepts” Defining Requirements Delivering Requirements
- 15. 15 STEP 4 Create Training and Resources for Each Core Concept STEP 3 Parse Role- Specific Guidance into Job-Specific Checklists STEP 2 Further Break Core Concepts down to Role- Specific Guidance STEP 1 Break WCAG into “Core Concepts”
- 16. 16 STEP 1 Break WCAG into “Core Concepts” • Carefully read success criteria and all techniques– what are the main ideas? • Approach Differs: Three Types of Success Criteria 1. Easy and Straightforward (e.g., 2.4.2 Page Titled) 2. Deceivingly Complex (e.g., 2.3.1 Three Flashes or Below Threshold) 3. Overly General (e.g., 1.3.1 Info and Relationships)
- 17. 17 STEP 1 Break WCAG into “Core Concepts” Success Criteria 1.3.1 (“information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text”) Seven Core Concepts in Success Criteria 1.3.1 • 1.3.1.1 Header Structure • 1.3.1.2 Using ARIA Landmarks and Regions • 1.3.1.3 Data Versus Layout Tables • 1.3.1.4 Data Tables Shall Identify Header and Data Cells • 1.3.1.5 Grouping Related Elements • 1.3.1.6 Programmatically Labeled Forms • 1.3.1.7 Use Markup Consistent with Intended Purposes
- 18. 18 STEP 1 Break WCAG into “Core Concepts” 1.3.1.1 Header Structure ”Structure in headers follow a proper hierarchy of header tags,”
- 19. 19 STEP 4 Create Training and Resources for Each Core Concept STEP 3 Parse Role- Specific Guidance into Job-Specific Checklists STEP 2 Further Break Core Concepts down to Role- Specific Guidance STEP 1 Break WCAG into “Core Concepts”
- 20. 20 STEP 2 Further Break Core Concepts down to Role- Specific Guidance Three Basic ”Roles” • Pre-Production (e.g., copy authors, UX designers, and media artists) need requirements written in a straightforward non-technical manner. • Production (e.g., developers, programmers, etc.) need requirements written in a technical code-specific manner. • QA/Testing need requirements translated into a functional test process in a technical manner often similar to production staff.
- 21. 21 STEP 2 Further Break Core Concepts down to Role- Specific Guidance Pre-Production “When headings are used in web content, make sure to use header tags. Furthermore, follow a consistent and proper hierarchy starting either with level 1 (only one level 1 heading should exist) or level 2.” Production “Ensure that the Document Object Model uses a consistent hierarchy of <H1>, <H2>, … , <H6> tags. If necessary, you can mix and match aria-level attributes (e.g. role=”heading” aria- level=”7”) with <Hn> tags, provided that these levels respect a proper and consistent hierarchy.” QA/Testing “Ensure heading levels follow a consistent hierarchy beginning with an <H1> or <H2> tag, via code inspection or using a scanning tool or browser extension. If <Hn> is not used, make sure headings use aria- level and that these levels respect a consistent and proper hierarchy. If <Hn> and aria-level are used concurrently, ensure that all such heading respect a common, consistent, and proper hierarchy.” Role-Specific Guidance for 1.3.1.1 (Header Structure)
- 22. 22 STEP 4 Create Training and Resources for Each Core Concept STEP 3 Parse Role- Specific Guidance into Job-Specific Checklists STEP 2 Further Break Core Concepts down to Role- Specific Guidance STEP 1 Break WCAG into “Core Concepts”
- 23. 23 STEP 3 Parse Role- Specific Guidance into Job-Specific Checklists • Simple exercise of dividing role-specific guidance (Step 2) into checklists based on organization-specific roles • Useful division • Pre-Production Requirements get divided between • copy authors, • UX engineers (wireframe designers), and • graphics or media artists. • Production Requirements go straight to web developers and programmers. • QA/Testing Requirements go straight to QA and testing team members.
- 24. 24 STEP 4 Creates Training and Resources for Each Core Concept STEP 3 Parse Role- Specific Guidance into Job-Specific Checklists STEP 2 Further Break Core Concepts down to Role- Specific Guidance STEP 1 Break WCAG into “Core Concepts”
- 25. 25 STEP 4 Create Training and Resources for Each Core Concept • Important to focus resources at the Core Concept Level (Step 1) and not the Role-Specific Level (Step 2) • Core Concepts are granular enough that each one can be covered in 10-15 minutes. • Teaching technical and non-technical teams together reinforces interdependencies and fosters teamwork. • Easier to write and maintain 70-80 web pages than 210-240 web pages!
- 26. 26 STEP 4 Create Training and Resources for Each Core Concept STEP 3 Parse Role- Specific Guidance into Job-Specific Checklists STEP 2 Further Break Core Concepts down to Role- Specific Guidance STEP 1 Break WCAG into “Core Concepts”
- 27. 2727 50 WCAG A/AA Success Criteria
- 28. 2828 50 WCAG A/AA Success Criteria “Core Concepts” Pre-Production Guidance Production Guidance QA/Testing Guidance Media Checklist Dev Checklist QA Checklist Copy Checklist UX Checklist Training and Resources Step 1 Step 2 Step 3 Step 4
- 30. 30 Transform Web Accessibility From An Individual Frustration Into A Team Win!
- 31. 31 Key Takeaways • Why an Accessibility Statement is important • Where to being in addressing website accessibility • How to create a self-sustaining culture of web accessibility
- 32. 32 Helpful Links • Converge Accessibility: https://convergeaccessibility.com/ • W3C’s Accessibility Statement resource: https://www.w3.org/WAI/planning/statements/ • Better Requirements for Web Accessibility Whitepaper: https://convergeaccessibility.com/whitepaper13/ • WebAlign Info: https://convergeaccessibility.com/services/webalign/
- 33. 33 Thank you!