Start your conformance report.

List the places your product ships recorded audio without video (an onboarding voice-over, a podcast embed) or video without audio (a silent screen recording). For each, check a transcript or an equivalent text description is available next to it. If your product contains no such media at all, answer Not Applicable — that is the honest and common answer for most business software.

Inventory the videos your product actually ships — tutorials, onboarding tours, help-center clips. Play the first minute of each with the sound off and check captions appear and match the speech. Auto-generated captions count only if someone has reviewed them for accuracy. If some videos have captions and some do not, answer Does Not Support and say so in the note; a procurement reviewer trusts a specific honest answer far more than a blanket yes.

Watch a tutorial video with your eyes closed: is anything essential communicated only visually (a button being clicked, text on a slide) without the narration saying it? If the narration already describes everything important, that can satisfy this. Otherwise you need an audio-description track or a full text alternative. No videos at all means Not Applicable.

Open your product's main screens with the sound on: does anything play audio without being asked? If nothing auto-plays audio anywhere — the common case — answer Supports and note that. If something does (an intro video with sound, notification sounds that loop), check there is an in-product pause/mute control.

This only applies to live media your product itself delivers — not recorded videos (that is 1.2.2) and not meetings your customers run in their own conferencing tools. If your product streams nothing live, answer Not Applicable. If it does, check a live captioning service or feature is in place during those streams.

Stricter sibling of 1.2.3: at AA, a text alternative is no longer enough — visual-only information in videos needs audio description (narration that describes it). Practical check: if your videos' existing narration already speaks everything important ("click Save in the top right..."), they effectively self-describe; note that. Videos with silent on-screen demonstrations need an described version. No videos means Not Applicable.

Unplug the mouse (really) and walk your core flow end to end with Tab, Shift+Tab, Enter, Space, and the arrow keys: sign in, do the main job your product exists for, save. Note what you tried in the attestation. Custom widgets — drag-and-drop lists, date pickers, rich-text toolbars, canvas editors — are where this fails; test those specifically. The automated scan catches a narrow slice (scrollable regions that keyboard users cannot reach); the real answer comes from your walkthrough.

During your keyboard walkthrough, pay attention to modals, embedded editors, video players, and third-party widgets: open each, then confirm you can Tab or Escape back out without reaching for the mouse. A dialog you can open but never leave by keyboard is a trap and fails this. This takes minutes to check and is one of the first things a manual reviewer tries.

List your keyboard shortcuts (check your help page or settings). Shortcuts using a single letter, number, or symbol with no modifier key are the problem case — they misfire for speech-input users whose dictation gets interpreted as commands. If all your shortcuts need Ctrl/Cmd/Alt, or you have none, answer Supports. If you have single-key shortcuts, check for a setting to disable or remap them.

During your keyboard walkthrough, watch where focus goes: it should track the visual reading order, not jump from the header to the footer and back to the form. Modals are the key case — when a dialog opens, focus should move into it, and when it closes, focus should return to where you were. Note which flows you verified.

Tab through your main screens and watch for the focus outline: it must be visible on every interactive element — links, buttons, fields, custom widgets. The classic failure is a global CSS rule (outline: none) that removed browser defaults for aesthetics without adding a replacement. If you lose track of where focus is at any point during your walkthrough, that is a failure at that spot.

Look at your form errors, status indicators, and charts in grayscale (macOS and Windows both have a grayscale filter, or screenshot and desaturate). Anything that only changed color — a field border turning red with no icon or message, a status dot that is only green vs red, links distinguished from text by color alone — fails. The automated scan covers the specific case of links inside body text distinguished only by color.

Open your product on a phone or tablet (or a narrow browser window) and rotate: content should reflow and stay usable both ways. Locking to landscape fails for users with a device mounted in a fixed position on a wheelchair. The automated scan detects CSS orientation locks; a two-minute rotation check on a real device is stronger evidence.

The automated scan measures this precisely on every page you list and cites the exact elements and ratios that fail — it is the single best-covered criterion. Your ten minutes are better spent on what the scan cannot see: text on images, hover/focus states, and screens behind sign-in. Grey placeholder text and muted "secondary" text are the usual offenders.

Press Ctrl/Cmd-plus until the browser reports 200% and walk your main screens: everything should still be readable and operable — no clipped labels, no overlapping columns, no buttons pushed off-screen. Also confirm your mobile pages do not disable pinch-zoom (the scan checks for the user-scalable=no viewport tag). Note the screens you checked.

Scan your marketing and product screens for pictures of text: screenshots used as headings, banner images with embedded slogans, buttons that are images. Real text scales, reflows, and recolors for users who need it; text in images does not. Logos are exempt. Try selecting the text with your cursor — if you cannot select it, it is probably an image.

Set your browser window to about 1280px wide and zoom to 400%, or just drag the window down to ~320px wide: pages should reflow to a single column with only vertical scrolling. Data tables and code blocks may legitimately scroll horizontally; page layouts may not. Check your landing, your main working screen, and one form.

Look at your form inputs, checkboxes, toggle switches, and icon buttons: can you actually see their boundaries against the background? Pale grey input borders on white are the classic failure. A contrast-checker browser extension (or your design tool's checker) against the 3:1 bar covers a screen in a couple of minutes. Focus indicators count too.

Users with dyslexia often override text spacing. Test with a text-spacing bookmarklet or extension (search "text spacing bookmarklet" — it applies the exact WCAG override values): text should not get cut off or overlap. Fixed-height containers with overflow:hidden are the usual failure. The automated scan flags inline styles that block user overrides.

Find your tooltips and hover cards: (1) press Escape while one shows — it should close; (2) move the pointer from the trigger onto the popover itself — it should not vanish; (3) it should stay visible until you dismiss it or move away, not auto-hide on a timer. Products with no hover-triggered content pass by default; say so.

Open two or three busy screens and hover the images, or right-click and inspect a few: each <img> should have an alt attribute that describes its purpose (a chart's alt should say what the chart shows, not "chart"). Purely decorative images should have empty alt text (alt="") so screen readers skip them. The automated scan catches images with missing alt attributes on the pages you list, but it cannot judge whether the text is meaningful — that part is yours.

On a content-heavy screen, use your browser's inspector: things that look like headings should be <h1>–<h6> elements, bullet lists should be <ul>/<li>, and data tables should be <table> with header cells (<th>). If your UI framework renders everything as styled <div>s, screen-reader users lose the structure sighted users get for free. The automated scan checks some of this (list and table markup, some ARIA relationships) on the pages you list.

Pick a complex screen and press Tab repeatedly, or open the page with CSS disabled (browser developer tools can do this): the content order should still be logical — heading, then description, then actions — not jumping around because layout CSS reordered things visually. Ten minutes on your two most complex screens is a fair spot-check; say in the note which screens you checked.

Search your UI copy and help text for phrases like "the button on the right", "the green icon", "below", or "you'll hear a beep". Instructions must also name the control ("select Save — the green button on the right" is fine, "the green button on the right" alone is not). A quick text search of your UI strings for right/left/above/below/round/green usually finds every instance.

Read just the headings on your key pages (screen-reader users navigate by them): does the heading outline alone tell you what is on the page? Then skim form labels: "Work email" beats "Email 2"; a section labeled "Details" containing billing settings fails the spirit. This is a judgment pass, not a tooling pass — ten minutes reading your own UI with fresh eyes.

Submit your most important forms empty and with bad values: each error should be described in text near the field ("Enter an email address like name@company.com"), not just a red border or a generic "form invalid" banner. Check your sign-up, sign-in, and the main data-entry form — three forms in ten minutes covers the bulk of the risk.

Scan your forms for fields whose only hint is placeholder text that vanishes when you type — those fail. Every input needs a persistent visible label (or, for compact search boxes, a programmatic label). Required formats (date formats, password rules) should be stated up front, not revealed only as errors. The automated scan flags inputs with no programmatic label on the pages you list.

Inspect your sign-up and profile forms: inputs collecting the user's own details should carry autocomplete attributes (autocomplete="email", "name", "tel", "street-address"). This helps users with memory or motor difficulties let the browser fill known values. The automated scan validates autocomplete attributes where present; missing ones on personal-data fields are a quick template fix.

Revisit the failed submissions from your 3.3.1 check: where the product can know the fix, does the message offer it? "Password must be at least 12 characters" beats "Invalid password"; "Did you mean name@gmail.com?" beats "Email not recognized". Security-sensitive cases (wrong password on sign-in) are allowed to stay vague — that is expected, note it.

List your consequential actions: payments, contract acceptance, bulk deletes, submitting data that cannot be edited later. Each needs at least one of: a review step before commit, a confirmation dialog, or the ability to undo/reverse. Check your deletion flows specifically — a one-click irreversible delete with no confirmation fails. If your product has no such actions, answer Not Applicable.

Load a page and press Tab once: many sites reveal a "Skip to main content" link as the first focusable element — that is the classic pass. Alternatively, proper HTML landmarks (<main>, <nav>) let screen readers jump directly. The automated scan checks for landmark structure on the pages you list; the Tab-once check takes ten seconds per page template.

Click through your main screens and read the browser tabs: each should name the specific page ("Invoices — Acme", not "Acme" on every screen). Single-page apps often fail this by never updating the title after navigation. The automated scan verifies a title exists on the pages you list; whether the titles are distinct and descriptive across your app is yours to spot-check.

Skim your pages for link text: "View invoice #1042" passes; a dozen identical "Details" links pass only if each sits in a table row that identifies what it belongs to (screen readers read the row too). Icon-only links need an accessible name. The automated scan flags links with no accessible name at all on the pages you list; judging whether the names are informative is yours.

Pick three or four important pages and ask: besides the navigation menu, how else does a user reach these? A working search, a dashboard with links, breadcrumbs, or a site map each count. Pages that are steps in a process (checkout step 2) are exempt. Most products with nav plus search pass; note which two mechanisms you rely on.

Click through five or six pages and watch the navigation: the same items should appear in the same relative order everywhere (items may be added or removed per context, but not reshuffled). Products built on a shared layout template pass this structurally — note that the navigation is a single shared component if it is.

List your gesture interactions: pinch-to-zoom on charts, swipe-to-delete, drag-to-reorder. Each needs a single-pointer alternative — zoom buttons, a delete button, up/down arrows. A product operated entirely by plain clicks and taps passes; say so. Test on a touch device if your product supports one.

Press and hold your mouse button on a few important buttons, drag the pointer off, and release: nothing should have fired. Standard HTML buttons behave this way by default — this fails mainly in custom components wired to mousedown/touchstart events. A quick check of your five most consequential actions (delete, submit, pay) covers the risk.

Most web products have no motion-triggered features at all — if that is you, answer Not Applicable. If you do (shake-to-report-a-bug is the common one), check the same action is available from a normal button and the motion trigger can be disabled in settings.

List every time limit: session expiry, auto-logout, timed forms, codes that expire. For each, check the user is warned before expiry and can extend (a "still there?" dialog with at least 20 seconds to respond counts), or the limit is essential (an auction ending, a security code). Sessions that silently expire and discard a half-filled form are the classic failure. No time limits anywhere means Supports.

Scan your product for motion: hero carousels, auto-advancing slideshows, scrolling tickers, animated backgrounds, dashboards that auto-refresh. Each needs a visible pause/stop control if it runs longer than 5 seconds. A static product with no auto-moving content is a Supports with a one-line note. The automated scan only catches the obsolete <blink>/<marquee> elements, so this is really yours to check.

Think through animations, loading indicators, alert effects, and any video content: does anything strobe or flash rapidly? For nearly all business software the honest answer is Supports after a content review — note that you reviewed it. If you ship user-uploaded or third-party video you cannot vet, say so in the note rather than claiming a blanket pass.

View source on a few pages and check the <html> tag carries a lang attribute matching the page's language. This is a one-line template fix if missing. The automated scan checks it on every page you list, so a clean scan is solid evidence here.

During your keyboard walkthrough, notice whether merely tabbing onto anything caused a change — a dropdown that navigates the moment it is focused, a field that opens a dialog on focus. Focus should never cause a context change by itself; only activation (Enter, Space, click) should. If your walkthrough surfaced nothing, that is a Supports with the walkthrough as the note.

Check your select menus, radios, and checkboxes: selecting a value should not fire a page navigation or form submission by itself — there should be an explicit Go/Apply/Save button, or a clear upfront note that changing the value updates the page. Filter dropdowns that immediately re-query a list on the same page are fine; a country selector that navigates to a different site the instant you choose is not.

Only relevant if your product mixes languages in one page — quoted foreign-language content, a language-switcher preview, localized snippets. Each such passage needs its own lang attribute so screen readers switch pronunciation. A single-language product passes by default (the page-level lang from 3.1.1 covers it); answer Supports with that note, or Not Applicable if you prefer — both are honest.

Pick your recurring actions — save, delete, edit, download, search — and check they use the same label and icon everywhere they appear. A design system or shared component library largely ensures this; if you have one, say so. If different teams built different sections, ten minutes comparing them is worth it.

This bites voice-control users: saying "click Save" fails if the button visibly says "Save" but its accessible name (via aria-label) is "Submit form". If you rarely override accessible names with ARIA, you almost certainly pass. If your codebase uses aria-label widely, grep for it and confirm each value contains the control's visible text. The automated scan checks this where it can detect the mismatch.

This criterion is largely covered by automated checks: the scan flags duplicate id attributes and similar markup faults on the pages you list. If your pages are built by a mainstream framework and the scan is clean, Supports (with the scan as evidence) is a fair answer; note anything unusual, like hand-written HTML sections.

Inventory your custom-built widgets — anything interactive that is not a native <button>, <a>, <input>, or <select>. Each needs the right ARIA role and state (a toggle needs role plus aria-pressed/aria-checked; tabs need role="tablist"/"tab" and aria-selected). The automated scan catches many missing names and broken ARIA patterns on the pages you list; for widgets behind sign-in, a screen reader spot-check (VoiceOver is built into macOS) is the honest verification.

Find your toast notifications, inline "saved" confirmations, and result counters. In the inspector, these need role="status", role="alert", or an aria-live region so screen readers announce them without moving focus. The quick real test: turn on VoiceOver (macOS, Cmd+F5), trigger a save, and listen for the announcement. The automated scan verifies some ARIA patterns; the VoiceOver check is the convincing evidence.