Updated October 9, 2026.
Website accessibility helps people read information, navigate pages, and complete tasks using different devices and assistive technologies. For a business website, that includes reading service details, finding contact information, and using a form without unnecessary barriers.
WCAG means Web Content Accessibility Guidelines: a technical standard used to evaluate accessibility. A review should specify both the version and the conformance level it is assessing.
What the Minnesota state standard covers
Minnesota’s state digital accessibility standard incorporated WCAG 2.1 Level AA effective July 1, 2024. The Minnesota IT Services guidance describes requirements for state agencies. That change does not, by itself, establish an identical statewide deadline for every private business.
The U.S. Department of Justice explains that the ADA applies to businesses open to the public under Title III, including access to goods and services offered on the web. Its web accessibility guidance is a separate reference from Minnesota’s state-agency standard.
A business may have separate legal, contractual, or procurement requirements. Establish which apply to your organization before treating a general checklist as a compliance plan. A website accessibility review should name the standard, level, pages, and processes it evaluates.
Start with the tasks your visitors need to complete
Choose representative pages and complete journeys: navigation to a service, reading a project, completing a form, and making a booking. Include embedded tools and error states. Testing only the homepage can miss the part of the website a customer needs most.
The following checks are a starting point for identifying barriers. They are not a complete WCAG conformance evaluation.
Reading and understanding
- Give pages descriptive titles and use headings that reflect the content structure.
- Provide useful alternatives for meaningful images; decorative images need different treatment.
- Check text contrast, including links, errors, and controls in different states.
- Test text zoom and narrow layouts for information or controls that become unavailable.
- Use clear link and button labels that explain the destination or action.
Navigation and interaction
- Use the site with a keyboard, including menus, dialogs, and forms.
- Check that focus is visible and moves in a meaningful order.
- Make sure a visitor can leave a component without becoming trapped.
- Review moving content and whether visitors can pause or stop it where required.
- Make controls comfortable to use on touchscreens and identify the applicable target-size criterion.
WCAG 2.1’s 44-by-44 CSS pixel target-size criterion is Level AAA. It should not be described as a universal WCAG 2.1 AA requirement. The relevant criterion depends on the version and level being evaluated.
Forms and media
- Check that fields have usable labels and that required information is explained.
- Trigger errors and confirm that people can identify and correct them.
- Test whether important status changes are available to assistive technology.
- Review captions and audio-description requirements for the media you publish.
- Test third-party booking, payment, or contact tools as part of the complete task.
Combine automated checks with human testing
Automated tools can identify some problems quickly, but a numerical score is not a WCAG compliance percentage. Human evaluation is needed for aspects tools cannot determine. W3C explains the limits of evaluation tools.
A useful review records what was tested, the method, the observed barriers, and the recommended fixes. Keyboard and screen-reader testing help assess interactions that may appear fine in a visual inspection. Retest after changes and document any remaining limitations.
Example: checking a quote-request form
As an initial exercise, try requesting a quote without a mouse. Can you reach every field, see which control has focus, submit the form, and find the confirmation? Then leave a required field blank and check whether the error is clear and you can correct it.
Record the page, browser, steps, expected behavior, and what happened. A note such as “focus disappears after opening the service menu” gives the person fixing it a reproducible problem. This exercise does not replace a full evaluation or screen-reader testing.
Plan ongoing ownership
Accessibility can change when somebody adds a page, uploads a document, changes colors, or replaces a form. Identify who is responsible for content, development, embedded tools, and follow-up testing.
For a new website, include accessibility requirements during design and development. For an existing site, prioritize barriers to essential tasks and agree on a realistic remediation scope. Completing a short checklist or achieving an automated score cannot guarantee conformance or eliminate legal risk.