Build products everyone can actually use

WebAIM measured these six across one million home pages in February 2026. They account for most of what breaks on the web. Every one of them is decided in a design file, a component library or a content brief. That happens weeks before anyone runs a test. The conversation worth having is with the people making those decisions. That is what our UX design process is built around.

Nobody in this category will say what it costs. Here are the two public numbers worth having, kept apart on purpose.

Built afterwards instead, it stops being part of a build and becomes an annual line. The US Department of Justice priced that side in its 2024 Title II rule. It gives an average of USD 20,324 a year for a small public entity over ten years. For a school district the figure is USD 38,348 a year. The rule's own footnote names what sits inside those figures, which is getting familiar with the standard, testing, and remediation. What does not exist is the ratio between the two. No independent study has published what designing this in costs against retrofitting it later. We are not going to invent one. The shape is the honest part. One of them is a slice of a build you are already paying for. The other is a line that comes back every year for as long as the product is live.

ISO/IEC 30071-1:2019 is a code of practice published jointly by ISO and IEC. It covers embedding accessibility decisions through the whole process of developing and maintaining a system. It sets out activities and the documenting of choices rather than prescribing one method. We do not certify against specific compliance frameworks ourselves; our software engineers build systems that pass your auditors' requirements. We build for the audits. We do not own the certifications. The GOV.UK Design System already attaches accessibility criteria to each component's documentation, citing success criteria by number. Settling this once inside a component is established government practice rather than our idea. The same underlying practice is described at how we run product discovery and how we build production software.

The company that sells the tooling published this first, and we agree with it. Deque's own audit data puts automated testing at 57.38% of issues. That is a real share of the work. It touches those issues; it does not fully cover the standard. The four criteria it returned nothing on are the ones somebody using a keyboard hits within seconds. Those four are worth putting in front of your own design leads and software engineering leads at the next design review. They are settled in the design rather than caught in the build.

Most teams quietly plan the version that gets most of the way. Somebody tested that. Schmutz, Sonderegger and Sauer published the study in Human Factors in 2016, DOI 10.1177/0018720816640962. They built the same municipal site three times, changing nothing but the WCAG 2.0 conformance level. They ran 61 people through it. At AA, task completion rose from 65.0% to 82.1% (p = .004). Time per task fell from 136.8 to 116.9 seconds (p = .03). Perceived usability rose from 2.8 to 3.3 (p = .009). Workload dropped from 10.9 to 8.4 on the NASA-TLX scale (p = .004). Level A came out statistically indistinguishable from no conformance at all on every outcome measure, in the paper's own words. The companion study ran 55 participants with visual impairments and 55 matched sighted participants. Both groups gained. There was no interaction between user group and conformance level (F(2,102) = 1.35, p = .264). The same held on the second measure (F(2,102) = 1.06, p = .349). So this is not a benefit landing on a small minority. Design to AA from the start, and the evidence says the spend comes back.