WCAG-informed design: accessibility decided in design, not fixed in QA

Why design is where accessibility is decided

Accessibility is often treated as a testing activity: build the product, run an audit, fix what fails. That approach is expensive and never really finishes, because the same failures are created again with every new feature.

Look at the most common failures on the web and a pattern appears. WebAIM's 2026 analysis of the top one million home pages found low-contrast text on 83.9%, missing image alt text on 53.1%, missing form labels on 51%, empty links on 46.3% and empty buttons on 30.6% - and those categories account for 96% of all detected errors. Nearly every one starts as a design decision: a palette choice, a form layout without visible labels, an icon-only button, a link that says "click here".

WCAG-informed design means making those decisions correctly in the first place, and building them into the design system so they stay correct.

My practice here comes from real delivery: contributing to WCAG A/AA/AAA accessibility for a major banking client's platform, and rebuilding an AI enterprise brand's colour system where testing found a pairing in use at 2.37:1 and the rebuilt primary pairing reached 17.26:1.

Accessibility decisions I build into design

Headings and structure matter more than they look

Structure is invisible to sighted users skimming a page, but critical to screen-reader users. WebAIM's screen-reader user survey found that 71.6% of respondents navigate lengthy pages by headings as their first strategy. Designing templates with a real heading hierarchy - rather than styling text to look like headings - makes long pages, dashboards and documentation usable for them, and helps everyone scan.

Designing accessible colour systems

Colour is the most common failure and the easiest to prevent. My approach:

1. Give each colour a role - brand, action, text, status, data - rather than a list of swatches.
2. Test pairings, not colours - a colour is only accessible against a specific background at a specific size.
3. Create compliant variants - a darker version of a bright accent for text and links, keeping the bright version for large display use.
4. Separate data colours - a utility layer for charts with its own tests and direct labels.
5. Test each theme - light and dark modes checked separately.

The full method is in WCAG contrast testing for AI product UIs.

For regulated and enterprise products

In healthcare, finance, government and enterprise procurement, accessibility is increasingly required rather than optional. US rules referencing WCAG 2.1 AA now have deadlines in 2027 and 2028, and enterprise buyers routinely ask for conformance information. Designing accessibly from the start is far cheaper than remediation under a deadline. See WCAG accessibility for healthcare software.

What you get