Cross-Browser Accessibility Testing: What to Check

Cross-browser accessibility testing means checking the browsers, platforms, and assistive technologies your audience uses, then verifying that people can complete important tasks in each environment. Build the test matrix from your users rather than assuming there is one universal browser and screen-reader list. In every selected environment, check keyboard operation, focus, semantic structure, labels, text alternatives, contrast, hidden and dynamic content, and complete workflows. Pair automated scans with manual evaluation and, where possible, usability testing with disabled users.

An automated pass or a successful check in one browser cannot establish that a site is accessible everywhere. W3C says that testing WCAG success criteria involves both automated testing and human evaluation, and recommends usability testing that includes users with disabilities. W3C Understanding Conformance

1. Choose a test matrix that reflects your audience

There is no universally sufficient set or number of browser and assistive-technology combinations. Start with evidence about your audience, supported platforms, and important workflows. The relevant environment is a combination of user agent, platform, assistive technology, versions, and how people use them. Accessibility support can vary across these combinations, and known limitations should be documented. W3C guidance on documenting accessibility support

Build the matrix

1. List the browsers and platforms your product officially supports and those represented in audience or support data.
2. Identify the assistive technologies and input methods relevant to your users and workflows. Consider screen readers, magnification, speech input, keyboard-only use, and mobile accessibility features where they apply.
3. Prioritize combinations around high-impact tasks, user needs, and known compatibility risks. Cover the combinations that matter most before adding lower-priority ones.
4. Record exact browser, operating system, and assistive-technology versions. Include language and configuration when these affect the experience.
5. Repeat critical checks after browser, operating-system, assistive-technology, or major application changes. Compatibility observations age as software changes.

Page or workflow	Browser and platform	Assistive technology and input	Versions and language	Priority and reason
Sign in	Record actual target	Keyboard and relevant screen reader	Record exact versions	Required account task
Checkout or booking	Record actual target	Relevant screen reader, keyboard, and zoom	Record exact versions	High-impact complete workflow
Navigation and search	Record actual target	Relevant input and assistive technology	Record exact versions	Core discovery task

This is a template, not a prescribed compatibility list. Choose the actual combinations from your audience and support commitments; W3C does not specify a universal count of assistive technologies that must be tested.

2. What to check in each environment

Use the same checklist and task steps in each matrix row. Capture both whether a control is technically exposed and whether a person can successfully use it.

Keyboard access and focus

• Complete the workflow using only the keyboard. Tab and Shift+Tab should reach interactive controls in a logical order; Enter and Space should activate controls according to their expected behavior.
• Check that focus is visible, not obscured by sticky headers, dialogs, or overlays, and moves predictably when a dialog opens and closes.
• Confirm there are no keyboard traps and that menus, tabs, custom widgets, validation errors, and autocomplete interactions can be operated without a pointer.
• Verify that skip links and other keyboard shortcuts, if provided, work in the target browser.

Semantics, names, and structure

• Check headings, landmarks, lists, tables, and page language for meaningful structure and order.
• Confirm links and buttons have names that make sense out of context and controls expose the right role, name, value, and state to assistive technology.
• Check that form fields have programmatic labels, instructions, required status, and errors associated with the relevant field. Placeholder text alone is not a reliable label.
• For custom controls, verify keyboard behavior and announced state as well as visual appearance. Prefer native HTML controls where they meet the need.

Text alternatives and visual presentation

• Check that informative images have useful text alternatives and decorative images do not add distracting announcements.
• Check captions, transcripts, and alternatives for relevant audio or video content.
• Measure text and control contrast with a suitable tool, then inspect rendered states such as hover, focus, disabled, error, and selected.
• Zoom text and content, increase text spacing where relevant, and verify that content remains readable and operable without clipping or unnecessary horizontal scrolling.

Hidden, changing, and responsive content

• When content is visually hidden, verify that it is hidden from assistive technology when appropriate, and that visually revealed content is exposed when it should be.
• Trigger menus, dialogs, accordions, validation messages, live updates, and loading or success states. Check that focus and announcements communicate the change without unexpectedly stealing focus.
• Test responsive breakpoints and orientation changes that your users may encounter. Verify that controls remain available and the reading and focus order remain coherent.
• Check reduced motion and other supported user preferences if the interface responds to them.

CSS, JavaScript, and complete tasks

• Check whether the information still makes sense in source order and when CSS is disabled or overridden. Users may customize presentation.
• Determine what happens if JavaScript fails or loads late. Critical tasks should not silently become impossible where your product can avoid that failure.
• Exercise real workflows from start to finish, including invalid input, error recovery, confirmation, and any asynchronous step. An isolated component check can miss a broken task.

MDN’s checklist similarly calls out semantic HTML, keyboard use, text alternatives, contrast, hidden content, CSS and JavaScript behavior, auditing, and screen-reader checks. MDN: Accessibility tooling and assistive technology

3. Combine automated checks with manual evaluation

Automated tools are useful for repeatable checks and common detectable issues. Playwright’s accessibility testing guide describes examples such as poor contrast, unlabeled controls, and duplicate IDs, while cautioning that many accessibility issues require manual testing. Playwright accessibility testing

The following runnable JavaScript example adds an automated axe scan to a Playwright test. It is a repeatable automated check, not a browser-and-screen-reader compatibility test and not proof of WCAG conformance.

npm init -y
npm install --save-dev @playwright/test @axe-core/playwright
npx playwright install chromium

Save as accessibility.spec.js and set BASE_URL to a page in your application:

const { test, expect } = require('@playwright/test');
const AxeBuilder = require('@axe-core/playwright').default;

test('page has no automatically detected axe violations', async ({ page }) => {
  const baseUrl = process.env.BASE_URL;
  if (!baseUrl) throw new Error('Set BASE_URL to the page under test');

  await page.goto(baseUrl, { waitUntil: 'domcontentloaded' });
  const results = await new AxeBuilder({ page }).analyze();

  expect(results.violations).toEqual([]);
});

Run it with:

BASE_URL=https://your-staging.example/ npx playwright test accessibility.spec.js

Use a staging URL where the page can load without exposing real user data or making unintended changes. If a page depends on authentication or setup, add the appropriate test fixture and reach the intended state before scanning. Scan relevant interaction states too: open menus, expanded panels, form errors, and dialogs may have different accessibility issues than the initial page. Playwright supports scanning a selected part of a page and configuring rule tags; decide which rules fit the check you intend to make.

Manual and inclusive checks remain necessary

1. Run the same user task with keyboard-only input in each prioritized environment.
2. Use the screen reader or other assistive technology paired with that browser and platform; check navigation, names, announcements, focus, and dynamic changes.
3. Inspect contrast and zoom or text resizing in the rendered page, including error and interaction states.
4. Ask users with disabilities to try important tasks where possible. Record where they succeed, hesitate, or need assistance; usability can fail even when an automated scan finds no violation.

W3C notes that tests of individual techniques are not themselves WCAG conformance tests. Evaluate the applicable success criteria and whether the approach is accessibility-supported for the people using the content. W3C Understanding Conformance

4. Record results so another person can reproduce them

For every finding, record the page or workflow, exact environment and versions, setup, steps, expected result, observed result, impact, and any known limitation. Include a screenshot or short recording when it clarifies a visual or focus issue, but treat it as supporting evidence: an image alone cannot show what a screen reader announces or whether a keyboard user can finish the task.

Field	What to write
Environment	Browser and version, platform and version, assistive technology and version, language, relevant settings
Reproduction	Page, starting state, numbered steps, keyboard keys or assistive-technology commands
Expected and observed	What should happen and what actually happened, including announcements and focus
Impact	Who is blocked or slowed down and which task is affected
Evidence and limitations	Relevant screenshot or recording, known workaround, and conditions not yet checked

5. Use screenshots as visual evidence, not an accessibility verdict

A screenshot can help compare layout, visible focus, clipping, contrast, or whether a responsive state rendered as expected. It cannot establish accessible names, reading order, keyboard operability, screen-reader announcements, or successful completion of a task. Pair visual evidence with interaction checks and assistive-technology evaluation.

For repeatable visual captures of pages or states, ScreenshotNeo is a website screenshot API and MCP server. It can capture a page as PNG, JPEG, WebP, or PDF; screenshots are supporting artifacts for the manual checks above, not an accessibility audit.

Or skip the browser setup

For a visual artifact, ScreenshotNeo takes a screenshot with one GET request. See the ScreenshotNeo API documentation for request options.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

• Cookie banners, popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
• Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed; response headers identify the page verdict and billing status.
• An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents and MCP clients.
• The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

6. Troubleshooting common testing problems

Symptom	Likely cause	What to do
The automated scan passes, but a user cannot finish the task	The scan only detects a subset of issues; interaction or workflow problems need human evaluation	Reproduce the full task with keyboard and the relevant assistive technology; document the failure and add a regression check where practical.
A control appears in the page but has no useful spoken name	Missing or ineffective accessible name, label, or semantics	Inspect the accessibility tree and markup; provide a concise programmatic name and verify it in the target screen-reader pairing.
Keyboard focus disappears or gets stuck	Focus styling is absent, focus is obscured, or custom interaction logic mishandles focus	Repeat with keyboard only, inspect focus after each action, and repair the focus order or widget behavior.
A scan misses a menu or dialog issue	The relevant state was closed or not rendered when the scan ran	Open the control, wait for the state to appear, then scan that state and manually check focus and announcements.
Results differ between runs	Page state, asynchronous content, data, or timing differs	Use deterministic test data, wait for the specific state or element needed, and record the starting conditions. Avoid treating a fixed delay as proof that the interface is ready.
Results differ between browsers or AT combinations	Platform support and browser/assistive-technology interoperability differ, or versions changed	Record exact versions and steps, confirm each environment is configured as intended, and investigate the failing pairing directly.
Contrast tool and visual inspection disagree	The tested color or state may not match the rendered text, opacity, background, or interaction state	Measure the actual rendered foreground/background pair for each relevant state and manually inspect legibility.
A visual screenshot looks correct but the experience still fails	A screenshot records pixels, not semantics, focus behavior, keyboard operation, or announcements	Use the image only for visual evidence; perform keyboard, screen-reader, and workflow checks.

7. Plan for performance, reliability, and cost

• Keep CI scans focused. Automated checks are repeatable and can run on changed pages or key states. A full environment-by-environment manual matrix costs more time, so prioritize around audience, task impact, and risk.
• Make failures reproducible. Pin or record browser and dependency versions in automated runs, control test data, and preserve logs and exact reproduction steps.
• Separate scan failures from product failures. A browser launch, navigation, authentication, or test setup error means the accessibility assertion may not have run. Report infrastructure and product findings separately.
• Budget for human evaluation. Automated tools cannot determine whether every real task is understandable and usable. Include time for manual assessment and user testing with disabled people where possible.
• Use screenshots selectively. They can make visual comparisons easy, but should not replace live interaction and assistive-technology checks. ScreenshotNeo charges only for clean shots; failed loads, bot checks, blank pages, timeouts, and cache hits cost nothing.

8. Short FAQ

Does passing an automated accessibility scan mean the site is accessible?

No. It is evidence about issues the scanner can detect. Manual evaluation and usability testing are also needed.

How many browser and screen-reader combinations should I test?

There is no universal required count. Select and document combinations based on your audience, supported environments, and important tasks.

Can a screenshot prove a page is accessible?

No. It can show visual conditions, but it cannot demonstrate keyboard behavior, semantics, announcements, or task completion.

Should I test every page?

Cover representative page patterns and every important workflow, including distinct states and custom controls. Add checks for unique pages and components where their behavior differs.