Practical tools and methods available throughout this course for testing, investigation, and evidence.
No single tool can prove whether an experience is accessible. Different tools provide different evidence. This toolkit collects tools you will use in this course, describes what each tool can show you, and clarifies what each tool cannot prove by itself.
A tool can provide evidence. A tool does not determine whether an experience is accessible. Using multiple tools and methods gives you stronger, more defensible conclusions.
Built into modern browsers.
Press F12 or right-click → Inspect in most modern browsers.
Browser tools show structure but don't show how all users actually perceive or interact with content.
WebAIM WAVE browser extension and evaluation tool.
Use the online evaluation tool or install the browser extension for Chrome, Firefox, or Edge.
WAVE can identify many potential accessibility issues and expose page structure. Its output is not a determination that a page is accessible or inaccessible. WAVE cannot test keyboard interaction, zoom behavior, dynamic content, or real user experience.
No installation required.
Use the Tab, Enter, Space, and Arrow keys in your browser.
Keyboard testing shows whether interaction is possible without a mouse, but doesn't test speech input, eye tracking, or how assistive technology interprets structure.
No installation required.
Zoom and viewport resizing often reveal text readability issues, layout assumptions that break at different sizes, and mobile-first design problems.
Press Ctrl++ (Windows/Linux) or Cmd++ (Mac) to zoom in. Resize your browser window to test different viewport widths.
Zoom and reflow testing shows visual and layout accessibility, but doesn't test how assistive technology users navigate or whether the content is semantically structured.
Important testing method that you will learn more about later in this course.
Screen reader testing requires practice and familiarity with the tool. Early in the course, using other testing methods is appropriate.
You are not expected to master a screen reader during this module. Screen reader testing becomes central in later sessions when we focus on assistive technology and semantic structure.
Automated tools can flag potential issues, but they are not exhaustive.
Automated tools cannot test keyboard interaction, screen reader compatibility, user intent, or whether real people can actually use what you built. False positives are common. Automated results must be verified through investigation and testing.