Testing & Tools

How to test digital content for accessibility — what to run, what to check by hand, and how to test with a screen reader.

The Three Tiers of Testing

Work through these in order. Each tier catches a class of problem the tier before it cannot see.

Tier 1 — Siteimprove (UC System Tool)

UC Merced participates in the UC-wide Siteimprove program, which regularly crawls campus websites and generates accessibility, quality assurance, and SEO reports.

The tool helps site owners detect WCAG violations, broken links, content issues, and more. Crawls generally occur every five days under the UC license. To request scan coverage or dashboard access for your site, submit a request through our Report a Technology Barrier form.

Tier 1 — Browser Plugins

Browser-based testing catches issues a site-wide crawler will not surface on the page you are actually working on.

Tier 2 — Manual Checks

These are the checks no scanner can perform, because each one requires a judgement about meaning rather than markup. Work through them in order on any page you are responsible for.

Keyboard

• Unplug or ignore your mouse. Can you reach every interactive element using Tab, Enter, Space, the arrow keys, and Esc?
• Does the focus outline stay visible the whole way through?
• Does focus move in an order that matches the visual layout?
• Can you get out of every menu, modal, and embedded widget without a mouse? A place you can tab into but not out of is a keyboard trap, and it stops the page dead.
• Does a "Skip to content" link appear on first tab?

Content and meaning

• Read the link text aloud with no surrounding sentence. Does it still say where it goes? "Click here" and a bare URL both fail this.
• Check alt text against purpose, not appearance. A scanner confirms alt text exists; only a person can confirm it is the right alt text.
• Are headings in a real, unskipped hierarchy — one H1, then H2s, then H3s — rather than text that has been made big and bold?
• Is any instruction relying on colour, shape, or position alone? "Fields in red are required" fails; "required fields are marked with an asterisk (*)" passes.
• Do data tables have real header cells, and do they read sensibly row by row?

Zoom and reflow

• Zoom the browser to 200%. Is anything cut off, overlapping, or lost?
• Is there horizontal scrolling at 400% zoom or on a narrow window?
• Does the page work in both portrait and landscape orientation?

Media

• Do videos have captions that are accurate, including punctuation and speaker identification — not raw auto-captions?
• Is there a transcript for audio-only content?
• Does anything play, move, or auto-advance without a way to pause it?

The places testing usually forgets

• Content behind a login. Site-wide crawlers cannot reach it, so it is almost never scanned. Test it by hand.
• Attached documents. An accessible page linking to an inaccessible PDF is still a barrier. See PDF Accessibility Guidance.
• Error states. Submit a form incorrectly on purpose. Is the error announced, described in text, and tied to the field it belongs to?
• Embedded third-party widgets. Maps, forms, calendars, and video players are frequently the least accessible thing on an otherwise fine page.
• Email and social posts. Covered by the content checklists.

Tier 3 — Screen Reader Testing

Screen reader testing answers a question no other method can: is this page actually usable? You do not need to be an expert user. Twenty minutes of listening to your own page will teach you more than any report.

If you are starting from zero: VoiceOver on a Mac is already installed (press Cmd + F5), and NVDA on Windows is a free download. Either is enough to begin.

A first screen reader test, in five checks

1. Listen to the page title first. Does it identify this page, or is it the same as every other page on the site?
2. Pull up the headings list. Every screen reader can list a page's headings. Does that list read like a sensible outline of the page? If it does not, your heading structure is wrong — and this is the single most common finding.
3. Pull up the links list. Are there several entries reading "click here", "read more", or a raw URL? Out of context, those are useless.
4. Tab through the interactive elements. Is each one announced with a name and a role — "Search, edit text", "Submit, button" — or does it announce as just "button" with no name?
5. Listen to the images. Does each announcement tell you what the image is doing there? Decorative images should be silent; informative ones should convey their information.

Developers Corner

Developers should validate deeper semantic and interactive behaviours. Key practices:

• Use semantic HTML and proper landmarks — header, nav, main, footer, article, section.
• Apply ARIA roles and properties only when native semantics do not suffice. See the W3C WAI-ARIA specification.
• Test scripting for keyboard support, event handling, focus management, and dynamic updates.
• Announce dynamic content changes through live regions, and move focus deliberately after a route change or modal open.
• Include accessibility tests in CI pipelines using tools such as axe-core.
• Ensure custom components expose a name, a role, and a state — a div styled to look like a button is not a button.

What Tools Cannot Tell You

Every item below passes automated testing and still fails a real user:

• Alt text that exists but describes the wrong thing
• Headings applied for size rather than structure
• A logical-looking tab order that does not match the visual reading order
• Captions that are present but inaccurate
• Link text that is unique in the markup but meaningless out of context
• An accessible page that links only to an inaccessible document

This is why the tiers exist. Run the scanner, then look with your own eyes and listen with your own ears.

Next step: run a Tier 1 scan on your highest-traffic page, then work through the Tier 2 list on the same page. If anything is unclear, request a consultation.