Website Design Accessibility Review Checklist Before Development

Accessibility is easier to discuss when it is part of design review, not a last-minute pass after implementation. A mockup can reveal likely barriers in contrast, hierarchy, labels and layout. It cannot prove keyboard support, screen-reader output or conformance by itself. Treat the visual review as an early risk check, then test the implemented site with appropriate methods.

The current W3C Web Content Accessibility Guidelines (WCAG) 2.2 cover web content across desktop and mobile devices. This article is a practical starting point, not a conformance audit or legal opinion.

1. Check text and contrast

• Review body copy, labels, placeholders and secondary text at their intended size.
• Check text against its background, including text over images and colored cards.
• Do not use color as the only way to distinguish success, error, required fields or selected options.
• Inspect hover, disabled and error states where the design provides them.

A screenshot can help spot low contrast, but final checks should use the actual color values and implemented states. Small adjustments to a compressed image or screenshot cannot establish accurate color measurements.

2. Review hierarchy and reading order

Can a person understand the page from its headings and grouping? Are related labels close to their controls? Does the visual reading order match the intended order of the content? Ask the designer to annotate any layout where the visual arrangement could produce a different order when coded.

3. Inspect controls and targets

Buttons, links, tabs and form controls should look interactive and have clear labels. Check that two actions are not visually indistinguishable if they have different consequences. For small controls, ask how the implementation will maintain usable target size and spacing on touch screens. A static preview cannot prove that a control can be operated without a pointer.

4. Review forms and error states

Look at required-field indicators, instructions, validation messages and confirmation states. Does an error explain how to correct the issue? Is a field identified by a persistent label rather than placeholder text alone? Are examples and format requirements shown before submission? These visual decisions should be reviewed before development, then tested with actual keyboard and assistive-technology use.

5. Inspect responsive layouts and zoom assumptions

Review the supplied phone and tablet compositions, not only the desktop image scaled down. Look for text that becomes too small, controls that crowd one another, and important content that disappears. Discuss what should happen when a user zooms or changes orientation. WCAG includes guidance for reflow and text resizing, but a design image is not enough to establish that the built page satisfies it.

6. Record the next verification

For each concern, record the component, visual evidence, proposed decision and the implementation test still needed. Example: “The error state uses red text only. Add a text label or icon, then verify that the message is announced and programmatically associated with the field.”

Use a shared preview to discuss the same screen and version. Swelik’s mobile mockup review checklist can complement this pass. After implementation, continue with keyboard checks, text resize, screen-reader review and testing with people who use accessibility features.

Check more than the color swatches

Contrast is important, but an accessible design review also asks how meaning is communicated. Can a status be recognized without color alone? Are headings visually distinct from body text? Is a link recognizable within a paragraph? Does an error message explain what to correct? Does the page layout group each label with its control? These questions can be raised from the visual artifact before any code exists.

Use the actual brand colors and type sizes when measuring contrast. A compressed screenshot, photograph, overlay or color profile may change the pixels enough to make a measurement unreliable. For text that sits on a photograph, check the whole area where the text can land and discuss a stable background or overlay with the designer.

Pair visual review with implementation checks

Some requirements are impossible to validate from a mockup. A reviewer cannot infer the real tab order from a picture. A screenshot does not reveal whether headings use semantic levels, whether an icon has an accessible name, or whether an error is announced after submission. Convert each concern into a follow-up test with an owner.

• Design question: Is the keyboard focus state visible in every component direction?
• Build test: Can a keyboard user reach and operate the control, and does focus remain in a meaningful order?
• Design question: Is the form error clear and near the affected field?
• Build test: Is the error programmatically associated and announced when it appears?

Include people and real content

Placeholder labels, unusually short text and decorative images can hide problems. Review realistic headings, translations if relevant, error messages, long names and product descriptions. Ask someone who uses keyboard navigation or assistive technology to review the implemented experience when appropriate. Automated checks help locate issues, but they do not replace direct use.

Use the current W3C guidance as a reference and avoid claiming “accessible” or “WCAG compliant” solely because the mockup passed a checklist. The WCAG 2.2 standard sets testable criteria, many of which concern behavior in the built page.

Frequently asked questions

Can a mockup be WCAG compliant?

A mockup can be reviewed against design-relevant requirements, but many requirements concern behavior and implementation. Avoid claiming conformance based only on a static image.

When should accessibility be reviewed?

Start during requirements and visual design, repeat on the implementation, and retest meaningful changes. Early review can identify questions while layout choices are still flexible.