DMD 3998

Accessibility & Inclusion in Interactive Media

Broader Practice

Accessibility Toolkit

Practical tools and methods available throughout this course for testing, investigation, and evidence.

Overview

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.

Why It Matters

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.

UConn Accessibility Tools

UConn's central guide to university-supported accessibility tools, assistive technologies, browser testing tools, coding guidance, and validators.

Useful for

  • Finding the institutional starting point for supported tools and guidance
  • Locating assistive technologies and browser-based testing resources
  • Finding coding guidance and validator resources used by the university

What it cannot prove by itself

The UConn page is a starting point for institutional guidance and tools. It is not itself a classroom audit or a determination that an experience is accessible.

NVDA

Free, open-source screen reader for Windows. Use it in Module 05 to inspect headings, landmarks, links, controls, form labels, names, roles, states, and dynamic interface behavior.

Useful for

  • Testing structure and hierarchy
  • Listening to names, roles, and states
  • Navigation without a mouse
  • Understanding how a form communicates its purpose and requirements

What it cannot prove by itself

A screen-reader result is evidence from a test, not proof that an interface is accessible or inaccessible. Practice is required to become comfortable with the tool.

VoiceOver

Screen reader built into macOS and other Apple platforms. Use it in Module 05 to navigate page structure, controls, forms, images, and interface state without relying on the visual presentation.

Useful for

  • Testing page structure and content flow
  • Understanding form labels, names, and state announcements
  • Checking whether interface changes are communicated
  • Navigating without visual inspection alone

What it cannot prove by itself

A single VoiceOver pass is not the same as expert screen-reader usage. The goal is to understand the semantics and announcements that are exposed to users.

JAWS

Commercial Windows screen reader widely used by people who are blind or have low vision.

Useful for

  • Understanding the broader screen-reader ecosystem
  • Recognizing enterprise and professional testing contexts
  • Comparing institutional tool guidance against class practice

What it cannot prove by itself

JAWS is relevant as a technology reference, but this course uses NVDA as the primary Windows screen-reader path and does not require JAWS for assignments.

Accessibility Bookmarklets

Browser bookmarklets that expose otherwise hidden accessibility information such as headings, landmarks, labels, descriptions, and ARIA information.

Useful for

  • Making headings, landmarks, and controls visible on the page
  • Inspecting labels, image alternatives, and ARIA information
  • Comparing what is visible in the browser with what is exposed to assistive technology

What it cannot prove by itself

Investigation aid, not a compliance result.

Browser Accessibility Tools

Use the accessibility tools included in the browser you already have. The goal is to inspect what the browser exposes, not to learn every developer-tool interface.

Useful for

  • Inspecting the accessibility tree
  • Reviewing names, roles, states, and relationships
  • Checking how the interface exposes semantics to assistive technologies

What it cannot prove by itself

These tools reveal how the browser exposes semantics, but they do not tell you whether the task is usable for every person in context.

WAVE

WebAIM WAVE browser extension and evaluation tool.

Useful for

  • Identifying potential accessibility issues automatically
  • Visualizing page structure and heading hierarchy
  • Detecting missing alt text and form labels
  • Seeing at a glance how WAVE categorizes issues on a page

How to access/install

Use the online evaluation tool or install the browser extension for Chrome, Firefox, or Edge.

What it cannot prove by itself

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.

Siteimprove

University-supported web scanning and quality-assurance tool for accessibility, broken links, and content quality.

Useful for

  • Scanning for accessibility issues and quality concerns across a site
  • Reviewing repeated patterns and larger site health issues
  • Supporting institutional monitoring and QA efforts

How to access/install

Access may require a university request or institutional configuration.

What it cannot prove by itself

Siteimprove is useful supporting evidence, but it does not replace direct testing or standards interpretation.

Accessibility Insights

Microsoft accessibility checking and educational tool for evaluating common issues and understanding the context of findings.

Useful for

  • Reviewing common automated checks
  • Supporting accessibility learning in a familiar tool environment
  • Cross-checking key issues with a second tool

What it cannot prove by itself

It is not required for this course and should be used as supporting evidence, not as a substitute for direct testing.

axe

Developer-oriented automated accessibility testing toolkit used in many engineering workflows.

Useful for

  • Identifying common rule violations in code and browser tooling
  • Supporting engineering review and remediation
  • Cross-checking issues surfaced by other tools

Authoritative links

axe Deque

What it cannot prove by itself

Automated tools can identify some accessibility problems. They cannot establish that an experience is accessible.

W3C HTML Validator

HTML validator used to check whether markup is structurally valid.

Useful for

  • Checking document validity and obvious markup problems
  • Validating HTML structure
  • Supporting a broader review of implementation quality

Authoritative links

W3C HTML Validator W3C

What it cannot prove by itself

Valid HTML is not the same as accessible HTML. Validation helps, but it does not prove usability or full accessibility.

W3C CSS Validator

CSS validator used to check syntax and quality of stylesheets.

Useful for

  • Checking stylesheet validity
  • Checking for syntax problems and structural issues in CSS
  • Reviewing style-related problems attached to layout or contrast

Authoritative links

W3C CSS Validator W3C

What it cannot prove by itself

CSS validity is useful but secondary. It does not establish that the visual or semantic experience is accessible.

ARIA Authoring Practices Guide

W3C patterns, examples, and guidance for accessible widgets, names, landmarks, roles, states, and keyboard interaction.

Useful for

  • Understanding how accessible widgets should behave
  • Checking names, roles, state changes, and keyboard interaction
  • Finding examples of accessible patterns to compare with a custom component

What it cannot prove by itself

ARIA is a support mechanism, not a substitute for semantic HTML or good design. It requires careful patterns and verification.

Native HTML first. Add ARIA when the interface actually requires it. No ARIA is better than bad ARIA.

Course Sequence

  • Understand the task. What is this interface trying to help a person do?
  • Test normal use. Can the task be completed without visual dependence on the design alone?
  • Test keyboard operation. Can the task still be completed without a mouse?
  • Check visual presentation and contrast. What is easy to read and distinguish?
  • Evaluate meaningful media. What information is carried by images, audio, or video?
  • Inspect semantic structure. What do headings, landmarks, labels, and naming reveal?
  • Test with a screen reader. What does the interface actually announce?
  • Trigger errors and state changes. What happens visually and programmatically?
  • Use automated tools as supporting evidence. What do they reveal and what do they miss?
  • Verify findings against authoritative guidance. What is the actual standard or principle behind the observation?

Related Entries

WCAG Screen Readers ARIA UConn Accessibility Tools NVDA VoiceOver Accessibility Bookmarklets