Accessibility web design means building pages so people can perceive, operate and understand them with different abilities and tools. Follow WCAG 2.2, plan headings, contrast and forms early, then test with both tools and people.
This page is a plain-language checklist for teams and non-developers. For wider context, see our digital accessibility guide.
How accessibility barriers form
Barriers appear when content and the software that delivers it do not fit together. The W3C notes that web accessibility depends not only on accessible content but also on accessible web browsers and other user agents. You control the content and the code. Browsers and assistive tools control the rest. Your job is to hand them pages that are clear and predictable.
Most barriers are decided early, in layout and wording, long before anyone writes code. Low-contrast text, a form that relies on colour, or a missing heading plan is far cheaper to fix on a sketch than on a live site. That is why the stages below start with design.
The POUR principles in everyday terms
WCAG groups its requirements under the POUR principles. The W3C says the 13 guidelines provide the basic goals that authors work toward under those principles. In practice, each principle asks a simple question of your page:
- Perceivable: can people detect the content? Images need text alternatives and text needs enough contrast against its background.
- Operable: can people use every control with the input they have, not only a mouse?
- Understandable: is the wording clear and do forms behave in the way people expect?
- Robust: is the markup clean enough for browsers and assistive technology to interpret reliably?
What WCAG 2.2 requires
WCAG 2.2 became a W3C Recommendation on 12 December 2024. Its success criteria are written as testable statements that are not technology-specific, so each one can be checked as pass or fail whatever stack built the page. Each criterion sits at a conformance level, and the level tells you how much you commit to.
| Conformance level | Position in WCAG | Planning use |
|---|---|---|
| A | Lowest level | The starting floor. A site that misses these criteria has basic barriers. |
| AA | Middle level | The level to name in a policy or contract when you need a clear, testable target. Confirm what any rule that applies to you requires. |
| AAA | Highest level | Apply where it suits your content. Treat it as a stretch goal unless a requirement names it. |
The levels come from the W3C’s WCAG 2.2 text, which defines three levels of conformance: A (lowest), AA and AAA (highest).
Because the criteria are written to be testable with a combination of automated testing and human evaluation, plan for both. No single scan settles conformance. The testing section below shows how to split the work.
Making a website accessible, stage by stage
Work through these stages in order. Each one reduces what the next has to catch.
- Plan structure and visual design. Decide the heading structure, colours, type size and form layout on the sketch.
- Write the content. Give every image a text alternative and make colour a helper, never the only signal.
- Build with meaningful markup. Use real headings, lists and form elements, and the alt attribute on images.
- Test. Run tools, then check by hand, and repeat after changes.
Design and layout decisions
The U.S. government’s Digital.gov guidance says to plan heading structure early and notes that everyone benefits from designs that are easier to see. Reviewing layouts as a team, with sketches pinned up where everyone can comment, is the cheapest point to catch problems.
The checklist for design, content and code
This table turns the guidance into checks anyone can apply, whether or not they write code.
| Area | Check | Planning use |
|---|---|---|
| Design | Text contrast of at least 4.5:1 for small text and 3:1 for large text | Specify these ratios in the colour palette before designs are approved. |
| Design | Do not use colour alone to convey meaning | Add a label, icon or pattern to every error, status or chart series. |
| Design | Body text at an effective size of at least 16px | Set this as the base size and let headings scale from it. |
| Design | 45-75 characters per line is acceptable; about 66 is comfortable | Cap the content column width so long lines do not form on wide screens. |
| Forms | Present fields in a single-column layout | Use one column even where space allows more. |
| Forms | Do not use placeholder text in form fields | Keep field labels visible rather than hiding instructions inside the field. |
| Content | Plan the heading structure early | Draft the outline of headings before writing the paragraphs beneath them. |
| Code | Use the alt attribute of the img element for alternative text | Make alt text part of the publishing checklist for every image. |
The design and form checks come from Digital.gov’s visual design guidance. The alt attribute is described in Texas A&M’s accessibility components article.
Contrast and colour
Contrast is the check most people can do first. Digital.gov sets the minimums at 4.5:1 for small text and 3:1 for large text, and says text that is part of a logo has no minimum contrast requirement. Use the ratios as pass marks, not as targets to scrape past: where the palette allows, stronger contrast is easier on every reader.
Alt text for images
The alt attribute on the img element is how HTML carries alternative text. Writing good alternative text is a skill in its own right, covered in What Is Image Alt Text? A Practical Guide to Writing Alt Text for Accessibility and SEO (2026) – Internetbuttons.
Testing tools compared
Tools are good at the repeatable checks. People are needed for the rest. Texas A&M lists evaluation tools as web accessibility assessment tools, HTML/CSS validators and browser extensions, and Digital.gov points to WebAIM’s Color Contrast Checker for measuring text and background colours.
| Tool type | Best for | Planning use |
|---|---|---|
| Contrast checker (such as WebAIM’s Color Contrast Checker) | Measuring the ratio between text and background colours | Use during design to confirm the palette meets the ratios before build. |
| Accessibility assessment tools | Evaluating pages against accessibility criteria | Run on every template and on pages after significant changes. |
| HTML/CSS validators | Checking that markup and styles are well formed | Use in the build stage, before assistive technology encounters the code. |
| Browser extensions | Running checks on the page you are viewing | Handy for editors and non-developers reviewing a live page. |
These categories are drawn from Texas A&M’s overview of web accessibility components and Digital.gov’s visual design guidance.
Human evaluation completes the picture, as WCAG expects. Tab through a page and confirm you can reach and operate every control without a mouse, read it with a screen reader if you can, and judge whether labels and instructions make sense. Digital.gov recommends regularly conducting accessibility testing throughout the design and development processes, not only before launch.
If a page fails to load at all, that is a connection problem rather than an accessibility one. Rule it out first with How To Restart Your Modem And Router: Quick Fixes To Restore Internet In Minutes (2026) – Internetbuttons, so test results reflect the page and not your network.
Who does what on a team
Accessibility is shared work. Texas A&M describes developers broadly as architects, programmers and graphic designers who turn content into digital resources, which means designers carry part of the load alongside programmers. A workable split looks like this:
- Designers: own contrast, type size, line length and form layout from the checklist above.
- Writers and editors: own heading structure, plain wording and alternative text for images.
- Developers: own the markup, the alt attribute and the validators.
- Everyone: run a contrast check or a browser extension on pages they publish.
A non-developer can complete most of the design and content checks without touching code. Hand anything that needs markup changes to a developer with the specific check that failed.
Frequently asked questions
What did WCAG 2.2 add compared with earlier versions?
The U.S. Access Board notes that WCAG 2.2 adds nine new success criteria to WCAG 2.1, and WCAG 2.1 had added 17 to WCAG 2.0. It also describes WCAG 2.2 as the final edition in the WCAG 2 line of normative requirements.
Which version of WCAG does U.S. federal law reference?
The Access Board states that Section 508 incorporates WCAG 2.0 by reference. If a legal or contractual requirement applies to you, check which version it names before choosing your target.
Does text in a logo have to meet contrast minimums?
No. Digital.gov states that text that is part of a logo has no minimum contrast requirement. Ordinary text on the page still does.
Do the criteria only apply to certain technologies?
No. The W3C writes WCAG 2.2 success criteria as testable statements that are not technology-specific, so they apply whichever tools built the page.