WCAG Initial Accessibility Checks

Performing early accessibility checks helps identify major barriers before full audits begin. These foundational tests align with WCAG 2.2 Level AA and can be done manually or with lightweight tools to ensure the product is perceivable, operable, understandable, and robust — the POUR principles of accessibility.

1. Page Setup & Structure

These checks ensure that the basic structure of the page supports accessibility from the start.

✅ Confirm every page has a unique, descriptive <title>.
✅ Ensure a single <h1> per page; subheadings (h2–h6) follow a logical hierarchy.
✅ Check that lang attribute is defined on the <html> element (e.g., lang="en").
✅ Include a Skip to main content link that is visible on keyboard focus.
✅ Verify that page landmarks exist: <header>, <nav>, <main>, <footer>.
✅ Inspect reading order matches the visual order (no CSS reordering that confuses AT users).

2. Keyboard Navigation & Focus

Keyboard operability is one of the most critical accessibility checks. Users who cannot use a mouse rely entirely on Tab, Enter, and Space keys.

✅ Navigate the entire page using only the keyboard — no mouse.
✅ Every interactive element (<a>, <button>, <input>, etc.) is reachable via Tab.
✅ Check that focus is always visible and clearly highlighted (WCAG 2.4.7 Focus Visible).
✅ Ensure focus order is logical and matches reading order.
✅ No keyboard traps — user can leave any modal or widget using Esc or Tab navigation.
✅ Test dropdowns, accordions, and modals for Enter/Space activation and Escape close functionality.

Tip: Use browser DevTools or Accessibility Insights for Web to visualize tab stops and focus indicators.

3. Visual & Color Contrast Checks

Ensuring sufficient contrast is essential for users with low vision or color blindness. WCAG defines minimum ratios for text and non-text contrast.

✅ Normal text (below 18 pt / 14 pt bold) must have contrast ≥ 4.5 : 1.
✅ Large text (≥ 18 pt / 14 pt bold) must have contrast ≥ 3 : 1.
✅ Icons, form borders, and graphical objects require non-text contrast ≥ 3 : 1.
✅ Do not use color alone to convey information (e.g., “fields in red are required”).
✅ Hover/focus states must remain visible even with custom colors disabled.

Use free contrast tools like WebAIM Contrast Checker or ColourContrast.cc for instant validation.

4. Structure, Semantics & ARIA Basics

Semantic HTML provides roles and names that assistive technologies depend on. ARIA should enhance, not replace, native semantics.

✅ Use <button> for actions, <a> for navigation — not <div> or <span>.
✅ Ensure all images have meaningful alt text (or empty alt="" if decorative).
✅ Check that forms have explicit <label> elements linked with for or aria-labelledby.
✅ Tables use proper <th> headers and scope attributes.
✅ If ARIA roles are used, validate with the W3C ARIA Validator.
✅ Ensure ARIA states such as aria-expanded, aria-pressed update dynamically.

Remember: “No ARIA is better than bad ARIA.” — Always prefer native HTML elements.

5. Forms, Media & Dynamic Content

✅ Every form control has a label; group related inputs with <fieldset> / <legend>.
✅ Error messages are descriptive, announced to screen readers, and programmatically tied to the field.
✅ Required fields include both visual and programmatic indication (e.g., aria-required="true").
✅ Multimedia includes captions, transcripts, and audio descriptions as applicable.
✅ Test live regions (aria-live) for announcements in dynamic interfaces (e.g., toast messages, carts, validation results).

Warning: Auto-playing video or audio can violate WCAG 2.2 criterion 2.2.2 (Pause, Stop, Hide). Always give users explicit media controls.

6. Quick Assistive Technology (AT) Verification

After completing manual checks, perform a short review using at least one assistive technology. This validates name, role, value, and keyboard operation.

✅ Screen Reader: Use NVDA (Windows) or VoiceOver (macOS) to test headings, landmarks, and form labels.
✅ Zoom / Reflow: Zoom page to 400% and confirm no horizontal scroll appears (WCAG 1.4.10 Reflow).
✅ High Contrast / Dark Mode: Enable OS-level themes and confirm all elements remain visible.
✅ Keyboard-only Users: Confirm focus styles persist under all themes and zoom levels.

7. Reporting & Next Steps

Document findings with screenshots, affected elements, and WCAG 2.2 criteria references. Prioritize based on user impact: keyboard blocks > contrast issues > labeling improvements.

Severity	Description	Action
High	Blocks access to content or function	Fix immediately
Medium	Causes confusion or extra steps	Fix in current sprint
Low	Minor enhancement for clarity	Backlog for review