Many businesses treat website accessibility as a final review item, something to check shortly before launch or address only after a complaint arrives. The difficulty with that approach is that most accessibility outcomes are determined much earlier, when colors are chosen, page templates are structured, and interactive components are built. By the time a site is finished, those decisions are baked into every page, and fixing them is no longer a small task.
This article outlines the risks of leaving accessibility until late in a project and the technical decisions that should be settled during design and construction.
The risks of treating accessibility as a finishing step
Excluded customers. The Centers for Disease Control and Prevention reports that more than 1 in 4 U.S. adults have some type of disability, with the most frequently reported categories being cognition, mobility, independent living, hearing, and vision. A site that cannot be operated with a keyboard, read with a screen reader, or understood at a glance by someone with limited vision turns away a meaningful share of the people it is intended to serve, and the business rarely learns who they were.
Legal exposure. The U.S. Department of Justice states that it has consistently taken the position since 1996 that the ADA applies to web content, and that businesses open to the public must provide full and equal enjoyment of the goods and services they offer, including those offered on the web. The Department also states that it has no regulation setting out detailed technical standards for these businesses, and it points to the Web Content Accessibility Guidelines as helpful guidance. A business should discuss its obligations with counsel; this article is not legal advice, but it is reasonable to regard an inaccessible site as a risk that carries a cost.
Higher cost to correct. The W3C's business case for accessibility reports that accessibility can contribute to cost savings when it is integrated into existing development cycles, and it recommends that a business case present the cost and risk of inaction. Our experience points to the same conclusion for a straightforward reason: a color palette, a heading structure, or a navigation component is used on every page, so fixing it after launch means revisiting every page that depends on it.
Lost inquiries. A form without properly associated labels, or a menu that cannot be reached by keyboard, does not announce itself as a problem. Visitors who cannot complete it leave, and the business sees only a lower conversion rate with no obvious cause.
Reputation. The W3C notes that a clear commitment to accessibility reflects well on a business, and the reverse is also true. A public complaint, or a customer who tells others the site cannot be used, is more damaging to a small business than the cost of building it properly.
Why the technical decisions come first
Accessibility isn't a layer you can add to a finished page. The heading hierarchy, markup semantics, keyboard behavior, and color contrast are properties of the page itself. They are set in design and construction, and the later a correction is made, the more of the site it touches.
The current version of the guidelines, WCAG 2.2, was published by the W3C as a Recommendation on October 5, 2023. It adds nine success criteria to WCAG 2.1, six at Level A or AA, and removes the obsolete 4.1.1 Parsing criterion. Level AA is the usual target for business websites.
What to settle during design
- Color and contrast as system decisions. Define text and background combinations once, in the design system, and verify them against the contrast requirements before any page.
- Typography and spacing. Establish a type scale that remains legible when enlarged, and spacing that gives interactive elements room, including on touch devices.
- Visible focus states. Design the appearance of focus for every interactive element deliberately, so keyboard users can always see where they are.
- Heading structure and page outline. Plan headings as a logical outline for each template, not to adjust visual size.
- Component behavior. Menus, accordions, tabs, modals, and forms should be designed with their keyboard and screen reader behavior specified, not only their appearance.
- Motion and media. Decide in advance how animation will behave, whether it can be paused or reduced, and how video will be captioned.
- Content guidance. Agree how images will be described, how links will be worded, and who is responsible for both.
What to set up in the build
- Semantic structure. Use the correct HTML element for each purpose. Webflow, for example, lets you set the HTML tag for each element and provides options for alternative text on images or for marking them as decorative.
- Landmarks, page titles, and language. Give every template identifiable regions, a descriptive page title, and a declared language, and provide a way to skip repeated navigation.
- Forms that can be operated and understood. Associate every field with a label, identify errors in text, and confirm the form can be completed using only the keyboard.
- Keyboard operation throughout. Verify that every interactive element can be reached, operated, and exited, and that nothing is hidden behind a fixed header or overlay when it receives focus.
- Content fields that enforce good habits. In the CMS, require image descriptions where practical, and provide editors with clear help text about heading levels and link wording.
- Testing built into the process. Use automated checks and manual testing with a keyboard and a screen reader during the build, not only at the end. Webflow's audit tools, for instance, check for some common issues such as missing alt text, empty links, and out-of-sequence headings, which is useful but is not a review against every criterion.
- A route for feedback. Publish an accessibility statement with a contact method, and commit to responding.
What we do and do not promise
Ultimately, responsibility for conformance with WCAG 2.2 and for compliance with applicable law rests with the client, as the owner and operator of the website. Hazel River Digital does not guarantee conformance and does not assume responsibility or liability for a client's compliance. Our role is to bring the site as close to the standard as practicable within the design constraints we agree on with the client at the outset, such as brand colors, supplied imagery, and required third-party tools. We build toward WCAG 2.2 Level AA from the first design decision, verify the result with accessibility tools and manual checks, and tell the client plainly where a constraint or a request prevents a criterion from being met. Conformance must also be maintained after launch, since later content, changes to third-party services, and decisions to depart from our recommendations can all affect it, and those matters remain the client's to manage.
Where accessibility tools fit
A wide range of website accessibility tools is now available, including automated scanners, monitoring services that recheck pages over time, checkers built into editing environments, and toolbars that offer visitors display preferences. Used well, they are valuable. Scanners quickly identify certain categories of issues, monitoring detects regressions as content changes, and editor-side checks help people who publish pages avoid common errors. The Department of Justice's own guidance observes that pairing a manual check of a website with automated checkers gives a better sense of its accessibility than either alone. These tools, however, work on what the site already contains. They can report a missing label or a contrast failure, but they cannot supply the heading structure, keyboard behavior, and component design that a build never included. They deliver their value only when the initial design and set-up have already established a strong technical framework, and they are best regarded as a means of protecting and maintaining that framework, not as a substitute for it. We have experience with several accessibility tools you can add to your site to support the standards your site is working toward, and we can guide you on the best tool for your needs.
The short version
The risks of leaving accessibility until late are practical: customers who cannot use the site, legal exposure, corrections that touch every page, and inquiries lost without explanation. The remedy is to build the technical foundation into design and construction, then use tools afterward to protect it. If you would like our team to review your site or build accessibility into a new one, reach out to us —we will transparently assess the current state before any commitment.
Sources
Verified against primary sources as of October 2026. This article is educational and not legal advice.
Have a system you want your website to talk to?
Book a free discovery call. We will tell you where your applications stand before you commit to anything.
Book a discovery call