Website accessibility belongs in launch QA

Start with real tasks

Accessibility gets harder when a website team starts with a long standard and no user journey.

Start with the important tasks instead.

• Open the navigation.
• Read the main service or product page.
• Understand the pricing or offer.
• Use the main CTA.
• Complete the form.
• Recover from an error.
• Understand the success message.

Now run those tasks without a mouse.

Keyboard use exposes problems fast.

• Focus disappears.
• A menu opens but focus stays behind the menu.
• A card looks clickable but has no keyboard action.
• A modal traps the user.
• A custom control needs a mouse.

Those failures matter because the task stops.

WCAG 2.2 is the current W3C Recommendation in the WCAG 2 series. The standard organizes accessibility requirements across perceivable, operable, understandable, and robust principles.

A short launch checklist does not prove full conformance. A practical pass still finds barriers before the site reaches users.

Run the manual pass

Start with headings.

Use one clear H1 for the page topic, then organize sections with logical H2 and H3 levels. Do not choose heading levels from visual size alone.

Framer now exposes semantic tags through text styles and accessibility controls, which makes heading structure a design and implementation responsibility rather than a hidden developer detail.

Next, review links and buttons.

• Link text should explain the destination where context is not obvious.
• Buttons should describe the action.
• Icon only controls need a useful accessible name.

Then review images.

• Informative images need meaningful alternative text.
• Decorative images should not create noise for assistive technology.
• The alt text should explain the purpose of the image in context rather than describing every visual detail.

Then review forms.

• Visible labels matter.
• Required fields need clear instructions.
• Errors need specific messages.
• Focus should move logically.
• The user should know which field needs attention and how to fix the problem.

Then review contrast and text size.

Check body text, muted labels, button text, links, placeholder text, disabled states, and text placed over images.

Then review zoom and responsive behavior.

• Increase browser zoom.
• Use a narrow viewport.
• Check whether important content stays readable without overlapping, clipping, or disappearing.

Then review motion.

Respect reduced motion preferences where the design uses movement. Avoid motion which blocks reading or makes the page hard to control.

Run a real-task accessibility pass

Use automated tools as one layer.

Automated checks help find missing labels, contrast problems, heading issues, and several code patterns.

Manual testing still matters because a tool does not understand whether the whole task makes sense.

A menu might technically have labels and still behave badly with a keyboard.

A form might pass a basic scan and still give a useless error message.

An image might contain alt text which says "image123" and still fail the user.

Run the high value paths first.

• Homepage.
• Primary service or product page.
• Pricing where relevant.
• Contact, demo, signup, or booking form.
• One CMS article or repeated template.

Fix shared components before isolated pages.

A header, footer, button component, form field, or card pattern often appears across the whole site. One correct component fix removes the same barrier from many pages.

Treat accessibility as part of design QA, content QA, and build QA.

The goal is simple.

A person should be able to understand the page, move through the page, use the controls, fix mistakes, and complete the main task across different ways of browsing.