ACR Desk

Method, tools and limits

How we test your product for an ACR.

ITI’s template requires every ACR to describe its evaluation methods, and GSA advises federal buyers to ask how an ACR was produced. Here is our method in full — including what it does not cover.

WCAG 2.1 A and AA by default, 2.2 on request 100% in writing — no calls Last updated September 2026

The five steps

We follow W3C’s evaluation methodology.

WCAG-EM 2.0, published by the W3C on July 23, 2026, sets out five steps for evaluating a website, an app or another digital product against WCAG. Our process uses the same five.

  1. Define the scope

    We confirm in writing: the product and version, the standard (WCAG 2.1 AA unless your buyer asks for 2.2), the VPAT® edition, and up to 15 screens or key flows.

  2. Explore the product

    With your test account, we use the product the way your users do and list its screens, components (dialogs, menus, data grids, custom widgets), states (errors, empty results, loading) and any media.

  3. Select a representative sample

    Every screen type and every agreed flow, end to end. WCAG applies to complete processes, so when a flow is in scope, every step of it is tested.

  4. Evaluate

    The checks below, on every screen and state in the sample. Then each of the 50 WCAG 2.1 Level A and AA criteria gets a conformance level and a written remark.

  5. Report

    The ACR on ITI’s VPAT® 2.5Rev template, the fix list and the draft accessibility statement — with the tested version, dates, browsers and assistive technology written into the report.

What we check, and with what

Nine checks, one remark per criterion.

The scan comes first, not last. As the W3C puts it: “Tools cannot check all accessibility aspects automatically. Human judgement is required.” (Selecting Web Accessibility Evaluation Tools)

Check How Main criteria
Automated scan axe-core 4.11, an open-source rules engine, run with Playwright in Chromium and WebKit (the engine behind Safari) on every screen and state in the sample. Many criteria, partly — a starting point only
Keyboard only Every flow with Tab, Shift+Tab, Enter, Space, the arrow keys and Escape — no mouse. We record focus order, focus visibility, traps and what happens when dialogs open and close. 2.1.1, 2.1.2, 2.1.4, 2.4.3, 2.4.7
Accessibility tree The names, roles, states and values Chromium exposes to assistive technology, for every interactive component in the sample. 1.3.1, 2.5.3, 4.1.2, 4.1.3
Screen reader Each flow with VoiceOver and Safari on macOS. We note what is announced for headings, controls, errors and status messages. 1.1.1, 1.3.1, 1.3.2, 3.3.1, 4.1.2, 4.1.3
Contrast Measured from computed colors with the WCAG formula: text at 4.5:1 (3:1 for large text), and 3:1 for component boundaries, states, focus indicators and meaningful graphics. 1.4.1, 1.4.3, 1.4.11
Zoom, reflow, spacing Text at 200%; a 320 CSS pixel viewport (1280 pixels at 400% zoom); the WCAG text-spacing values; portrait and landscape. 1.3.4, 1.4.4, 1.4.10, 1.4.12
Forms and errors Labels, instructions, required fields, error messages and suggestions, confirmation steps, and autocomplete on personal-data fields. 1.3.5, 3.3.1, 3.3.2, 3.3.3, 3.3.4
Pointer and hover Gestures and drag-and-drop alternatives, pointer cancellation, labels matching visible text, tooltips and pop-ups on hover or focus. 1.4.13, 2.5.1–2.5.4 (plus 2.5.7 and 2.5.8 for WCAG 2.2)
Media and time Captions, transcripts and audio description; audio that starts on its own; session timeouts; moving, blinking or flashing content. 1.2.1–1.2.5, 1.4.2, 2.2.1, 2.2.2, 2.3.1

What the remarks look like: rows marked Supports say what we checked; rows marked Partially Supports or Does Not Support name the screen, the element and the failure — never “some issues.” See every one of them in the sample ACR.

Limits

Read this before you order.

These limits are written into every report we deliver, so your buyer sees them too.

  • A sample, not a census. We test the screens and flows agreed in your quote. Issues can exist elsewhere in the product.
  • One version, one date. The ACR describes the build we tested. New releases can change the results — hence the retest and ACR Care.
  • One screen reader. VoiceOver with Safari on macOS. We don’t test JAWS or NVDA on Windows, TalkBack on Android, or VoiceOver on iPhone and iPad. If your buyer requires JAWS or NVDA results, tell us before you order.
  • No testing with users with disabilities. Our evaluation is manual and tool-based. Studies with disabled users are valuable, and they are a separate service we don’t offer.
  • Not a Trusted Tester evaluation. We are not DHS-certified Trusted Testers, and agencies that adopt that process accept results only from certified testers.
  • Web-based products only. No native mobile apps, desktop software or hardware. PDFs and other files your product generates are listed as out of scope.
  • Not a certification, not a legal opinion. The ACR is your statement; you review, approve and publish it.

Overlays

Why we never recommend an overlay.

An overlay is a script or widget that promises to fix accessibility automatically. It doesn’t change the code your users’ assistive technology actually meets, and it doesn’t change what an honest ACR has to say.

In April 2025 the Federal Trade Commission approved a final order requiring one overlay vendor to pay $1 million and barring it from claiming, without evidence, that its automated tool can make any website WCAG-compliant (FTC, April 22, 2025). The HECVAT that universities send to vendors says it directly: “Third-party overlays or add-ons are not sufficient for products to conform with accessibility standards.” (EDUCAUSE HECVAT 4.1.6, guidance for ITAC-18)

This website

We hold our own site to the same standard.

We target WCAG 2.2 Level AA on acrdesk.com and test it the same way: an automated scan in Chromium and WebKit, a keyboard-only pass, a review of the accessibility tree, contrast, 200% zoom, 320-pixel reflow and text spacing. Last checked: September 2026.

Focus indicators use a two-color ring — dark inside, yellow outside — so they stay visible on light and dark backgrounds (W3C technique C40). Text is set in Atkinson Hyperlegible, a typeface the Braille Institute designed for readers with low vision.

Found a barrier on this site? Tell us at contact@acrdesk.com.

Sources

Primary sources only. Each was read on September 26, 2026.

  1. VPAT® — current version 2.5Rev (April 2025), four editions, FAQs — Information Technology Industry Council (ITI).
  2. Request Accessibility Information from Vendors and Contractors — Section508.gov, GSA.
  3. WCAG Evaluation Methodology (WCAG-EM) 2.0 — W3C Group Note, July 23, 2026 — W3C.
  4. Selecting Web Accessibility Evaluation Tools — W3C Web Accessibility Initiative.
  5. Web Content Accessibility Guidelines (WCAG) 2.1 — W3C Recommendation (current version dated May 6, 2025) — W3C.
  6. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Recommendation (current version dated December 12, 2024) — W3C.
  7. DHS Trusted Tester Process & Certification Program — Section508.gov, GSA (reviewed/updated July 2026).
  8. FTC Approves Final Order Requiring accessiBe to pay $1 Million — Federal Trade Commission, April 22, 2025.
  9. Higher Education Community Vendor Assessment Toolkit (HECVAT 4, current version 4.1.6) — IT Accessibility questions ITAC-01 to ITAC-18 — EDUCAUSE.
  10. Technique C40: Creating a two-color focus indicator to ensure sufficient contrast with all components — W3C Web Accessibility Initiative.

Get a quote

Comfortable with the method? Send us your product.

We reply within one U.S. business day with a scope, a fixed price and a delivery date.

Request a quote Read the sample ACR