WCAG 2.2 Accessibility Checklist for Small Business Websites and Web Apps

Published: September 5, 2026 · Last updated: September 5, 2026 · Author: Softix

A WCAG 2.2 accessibility checklist is useful only when it changes how a product is designed, built, tested, and maintained. A scan can find some missing labels or contrast issues; it cannot decide whether a keyboard user can complete checkout, whether a screen-reader user understands a dynamic status, or whether an error can be corrected without losing work.

WCAG 2.2 is a W3C Recommendation published December 12, 2024. It defines testable success criteria across perceivable, operable, understandable, and robust principles. Softix uses Structure–Interaction–Evidence: build a sound semantic structure, make every important interaction operable, and keep evidence from automated, manual, and assistive-technology testing.

This is implementation guidance, not legal advice or a promise of conformance. If a contract, regulator, or customer requires a particular standard or deadline, involve qualified accessibility and legal specialists.

Plan accessibility as a product requirement

Accessibility is not a final polish pass. Put it in the product brief with the same clarity as security, performance, and mobile support. Identify the critical journeys, users and assistive technologies you expect to support, content and component owners, target conformance level and scope, evidence required before release, and how issues will be triaged after launch.

The W3C quick reference is useful because it lets a team filter success criteria by level and technology. Do not treat the filtered list as a substitute for understanding conformance requirements. WCAG conformance applies to complete pages and, for a process, the complete sequence of pages and states.

The U.S. Department of Justice web accessibility resources may be relevant to public entities and related organizations; applicability and obligations depend on the organization and legal context. A small business should not claim that “WCAG compliance” automatically settles every legal question.

The Softix Structure–Interaction–Evidence model

Structure: make information understandable to more than one sense

Use semantic HTML before adding ARIA. A native button, link, heading, list, table, label, and form control usually gives browsers and assistive technologies a better starting point than generic div elements with roles.

Structure checks include:

• one clear page title and meaningful heading hierarchy;
• a programmatically determinable page language;
• landmarks that reflect page regions;
• labels associated with form controls;
• text alternatives for informative images;
• decorative images ignored by assistive technology;
• tables with appropriate headers and relationships;
• meaningful link text and button names;
• reading order that survives responsive layout changes;
• status messages exposed without forcing focus away from the user’s work.

WCAG 2.2’s Success Criterion 1.1.1 requires text alternatives for non-text content except for defined exceptions. “Alt text” is not a keyword field. The text should convey equivalent purpose; a decorative shape may need an empty alternative, while an image that is the only control label needs an accessible name.

For custom widgets, consult the WAI-ARIA Authoring Practices Guide. Use a pattern only when component behavior, keyboard interaction, focus management, and announcement rules are implemented together. ARIA can expose a misleading structure when underlying interaction does not work.

Interaction: make important work operable

Keyboard testing is one of the highest-value checks for a website or web app. Put the mouse aside and complete the main journeys with Tab, Shift+Tab, Enter, Space, arrow keys, and Escape as appropriate.

Check that every action has a reachable control, focus order follows the task’s meaning, focus is visible and not hidden behind sticky headers or dialogs, a modal returns focus sensibly, users are not trapped, drag-and-drop has a non-drag alternative, pointer actions can be canceled or undone, dynamic updates are announced, time limits can be extended or work is preserved, and the product does not rely on color, sound, shape, or location alone.

WCAG 2.2 added criteria including Focus Not Obscured, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, and Accessible Authentication. The exact success criterion and conformance level matter. Read the criterion and its supporting guidance instead of relying on a summary.

Responsive design is part of interaction quality. Test zoom and narrow viewports. WCAG 2.2 includes a reflow criterion at 320 CSS pixels for most content, with exceptions for content where two-dimensional presentation is essential. A horizontal data table may need a specialized accessible treatment; “make everything scroll” is not an accessibility plan.

Visual design and content checks

Build design tokens for contrast, focus, spacing, typography, and disabled states. For normal text, WCAG 2.2’s Level AA contrast criterion specifies a 4.5:1 ratio, with defined exceptions; large text has a different threshold. The requirement is not satisfied by a color palette document if the actual component state fails.

Test body text, headings, placeholders, links, muted text, focus indicators, error and success states, icons and graphical controls, text at 200% zoom, narrow viewports, forced-color modes, motion, autoplay, blinking, and animated transitions.

Content needs an owner. Write headings and instructions that explain the task. Identify errors in text near the field, provide a correction suggestion when known, and preserve entered data when validation fails. For a financial or legal submission, give the user a review and correction step before finalizing.

WCAG 2.2 includes Accessible Authentication (Minimum) at Level AA. A login flow should not force a user to remember or transcribe a secret when an alternative or assistive mechanism can be provided. Supporting password managers, paste, passkeys, and clear labels can improve accessibility and security.

Mobile and touch considerations

Accessible web delivery is not desktop-only. Test on a real phone with zoom, orientation changes, touch exploration, screen-reader gestures, and a slow connection. Make targets large enough and separated enough to avoid accidental activation. Do not rely on hover to reveal essential information.

Avoid gesture-only interactions. If a map, slider, canvas, or drag surface is important, provide buttons, fields, or another single-pointer path. Check that fixed footers and keyboard overlays do not cover the focused control.

For a web app, include authentication, error, empty, loading, offline, and permission states in the accessibility plan. The success path is rarely the hardest state.

Testing: combine tools with people

Automated testing is valuable for repeatable checks. It can detect missing names, invalid relationships, contrast combinations, and structural issues. It cannot prove that a workflow is understandable or that a screen-reader user can complete a task.

Use three layers:

1. Automated: run a scanner in CI and on representative routes; fail on agreed high-severity regressions, but review false positives and false negatives.
2. Keyboard and browser: test critical journeys at responsive sizes, zoom, focus states, reduced motion, and forced colors where applicable.
3. Assistive technology and human review: test with at least one screen reader and, where possible, include people with disabilities or an accessibility specialist.

Record browser, operating system, assistive technology, route, state, steps, expected result, observed result, severity, and owner. A test report without tested states is difficult to reproduce.

Do not claim full WCAG conformance from an automated score. W3C explains that conformance is evaluated against full pages and complete processes, and that only accessibility-supported uses of technologies can be relied upon. Third-party widgets, ads, chat tools, and embedded payment flows need an ownership and monitoring plan.

A release-ready checklist

Before development

• Critical journeys and user roles are listed.
• Target conformance level and scope are documented.
• Semantic component and design-system requirements are defined.
• Content, design, engineering, QA, and support owners are named.

During development

• Native HTML controls are preferred.
• Keyboard and focus behavior are acceptance criteria.
• Form labels, errors, instructions, and status messages are tested.
• Images, video, tables, and charts have appropriate alternatives.
• Permission, loading, empty, and error states are included.
• Accessibility tests run against every new shared component.

Before release

• Critical journeys pass keyboard-only testing.
• Focus is visible and not obscured.
• Contrast and text resize checks pass for all states.
• A screen-reader review covers sign-in, navigation, forms, and dynamic content.
• Automated findings are triaged with owners and due dates.
• Third-party content and complete multi-page processes are included.
• The release record contains scope, browsers, assistive technologies, findings, and known limitations.

After release

• Monitor support requests and feedback channels.
• Retest after design-system, dependency, and third-party widget changes.
• Maintain an accessible contact path for reporting barriers.
• Track recurring issues as product work, not only QA debt.

Common mistakes

• Treating an accessibility overlay as a substitute for accessible code.
• Testing a static page but not the authenticated product workflow.
• Using ARIA to repair a component whose keyboard behavior is missing.
• Removing visible focus to make a design look cleaner.
• Relying on color alone for validation or status.
• Forgetting zoom, mobile, and screen-reader states.
• Publishing a conformance claim without defining scope and evidence.
• Ignoring third-party components because a vendor owns the iframe.

Accessibility is a delivery capability. It improves when design tokens, semantic components, test fixtures, content workflows, and release gates reinforce one another.

FAQ

Is WCAG 2.2 required for every small business website?

The applicable requirement depends on your organization, customers, contracts, jurisdiction, and legal obligations. WCAG 2.2 is a current W3C Recommendation and a useful technical target, but legal counsel should advise on obligations and claims.

Can an automated scanner make a site accessible?

No. Scanners find valuable classes of defects, but keyboard, screen-reader, cognitive, content, and workflow testing still require human evaluation.

Should a small business aim for WCAG AA?

Many teams use Level AA as a practical target, but the right scope and target depend on the product and requirements. Document the decision and test complete processes rather than only a homepage.

A practical next step

Softix can help turn accessibility into a web or product delivery workstream: audit critical journeys, improve shared components, and add evidence to the release process. Explore web app development or contact Softix for a scoped accessibility plan.