Accessibility Testing Tips for Non-Coders
Explore valuable insights on streamlining WCAG testing tools and techniques for non-coders, including key checkpoints and learning objectives to enhance efficiency and effectiveness in ensuring digital accessibility.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
Presentation Transcript
Accessibl Managed Accessibility Ops Accessibl , Managed Accessibility Ops
Streamlining WCAG Testing Tools and Tips for Non-Coders Jeff Rodgers, MS Ed Manager, Digital Accessibility, Accessibility Strategy Leader
Session Overview Questions may be asked of the attendees. Please respond in the chat if you are able. There will be time for a Q and A session at the end. The focus of this session is on general a11y testing for those who are non-web coders.
Learning Objectives Learning Objectives: Identify and prioritize WCAG criteria for educational testing. Identify user-friendly tools and techniques for WCAG testing. Apply tips and strategies for streamlining WCAG testing to improve efficiency and effectiveness.
The 411 of WCAG Testing The Web Content Accessibility Guidelines (WCAG) As of 10.5.23, WCAG 2.2! Three levels of WCAG (A, AA, & AAA) Four Principles of WCAG Perceivable Operable Understandable Robust
Testing Need to Know #1 Websites are built with three types of code Hyper-Text Markup Language (HTML) Building block code Like a building s frame Cascading Style Sheets (CSS) Visual code Like Paint and decorations JavaScript (JS) Makes things function or move Like the mechanics in a building
Testing Need to Know #2 AT interacts with the web browser s DOM, not the code. DOM = Document Object Model. How a web browser displays a page You can inspect web code by using the Inspect view Right-click and choose Inspect.
Ten Checks You Should Make Ten WCAG criteria that are the most critical to check for learners LO#1
Key Accessibility Checks 1. Text Alternatives All images, graphs, & charts have CORRECT alt text. 2. Headings and Structure Heading tags (H1, H2, H3) provide a clear and logical structure. 3. Keyboard Accessibility A keyboard can be used for all functions and interactive elements. 4. Focus Indicators A clear, visible focus indicator outlines all elements, buttons, and form fields.
Key Accessibility Checks page 2 5. Color and Contrast Sufficient contrast between the text and all backgrounds. ( 4.5:1) 6. Audio and Video Captions/Transcripts Provide transcripts for audio and video content (Podcasts, Lectures) Captions and transcripts are different. 7. Responsive Design Websites and materials show well on various screen sizes and devices 8. Forms and Interactive Elements Forms, buttons, links, etc., have clear labels, instructions, and error messages. All are accessible via keyboard alone.
Key Accessibility Checks page 3 9. Language and Readability Use plain language and avoid jargon. Define acronyms The content is organized on the page 10.Consistent Navigation The course and documents have a consistent layout and structure Predictable navigation is best Consistent layout
User-Friendly Testing Tools Jeff s go-to, easy-to-use tools. LO#2
Three Types of A11y Testing Tools Automated a11y tools Automated scanning or checking WAVE & Google Lighthouse NO: Overlays Manual testing tools Help an auditor test specific elements Accessible Name and Descriptor Indicator (ANDI) Assistive technology (AT) What end-users use JAWS Screen reader
Automated Tools Examples: WAVE, DevTools, ARC (Link to W3C s list at end) A11y Tublets MS Accessibility checker Facts: All must use an accessibility engine or ruleset. (AXE, ARC, Pa11y) Pro: Quickly scan a web page or document Great for getting general sense of a11y Cons: Not able to check ALL WCAG criteria! Lack of ability to understand context and purpose
Manual Tools Examples: ANDI and Digital A11y Tublets, & DevTools Pro Keyboard Color contrast checkers Facts: Requires more time than automated tools. Pro: Detect real problems (fewer false positives) Augments automated tools Con: It requires you to determine compliance.
Assistive Technology Examples: Screen readers, magnifiers, braille devices, and other controllers. Fact: Not all AT (screen readers) work the same Pro: A true test of accessibility! Con: Need to know how to use them like a REGULAR user!
Tool Takeaways Automated tools are best for quick checks Automated and manual tools cannot detect all issues Great if you have the time to use them Using AT is the best way to ensure accessibility! Just need to learn how to use them!
Jeffs Recommended Tools Auto-scanning Tools Google Lighthouse & WAVE for quick checks ARC Toolkit & AXE DevTools for more detailed scans Manual Tool Accessible Name and Description Indicator (ANDI) Color Contrast Analyser (CCA) DevTools and ARC Toolkit Assistive Tech Keyboard Screen Reader
Demonstration Time Time to see some of the tools in action on the ASU Accessibility Page.
Questions Please ask your questions in the chat.
Resources and weblinks Link to WCAG 2.2 Testing Tips Jeff s 10 Testing Tips document Recommended Automated Tools Google Lighthouse (built into Chrome) WAVE Chrome Browser Extension
Resources and weblinks page2 Recommended Manual Tools Accessible Name and Description Indicator (ANDI) Digital A11y Tublets Chrome Extension ARC TOolkit Chrome Extension TPGI Color Contrast Analyzer DevTools Chrome Extension
