Why Accessibility Comes First

Accessibility is where good design starts, not a box to check the week before launch. Here is why building accessibility in from the start costs less, reaches more people, and lowers legal risk, along with what that looks like at every stage of the work.

Building accessibility in from the start means people with disabilities shape the product from the first research session, so the barriers never ship. A fix in a sketch is a conversation. A fix in shipped code is a project. Starting early also improves the product for every user and lowers your legal and procurement risk.

The audience is large. The CDC reports that more than 1 in 4 US adults have some type of disability. The World Health Organization estimates that 1.3 billion people, about 1 in 6 of us, experience significant disability. Those numbers include your customers, your employees, and the families who buy alongside them.

Why does accessibility from the start cost less?

The W3C, the group that writes the web's accessibility standards, puts the point plainly: "Addressing accessibility at later stages becomes increasingly difficult." The reason is easy to see in any real product.

• A color choice spreads. A low-contrast gray picked for a style guide ends up in every button, chart, and form across the product. Changing the gray in the style guide takes one decision. Changing the gray after launch means finding and retesting every screen that uses the color.

• A form built without labels has to be rebuilt. Labels added at the start cost nothing extra. Labels added later mean new code, new testing, and a new release.

• Retrofits arrive under pressure. Late fixes usually follow a complaint, a failed procurement review, or a legal letter, when the team has the least time and the least choice.

How does accessibility make the product better for everyone?

The curb cut is the classic example. Lowered curbs serve wheelchair users, and they also serve parents with strollers, travelers with suitcases, and delivery workers with carts. Digital features behave the same way.

• Captions help in loud rooms and silent ones. The W3C notes that captions also help people who are less fluent in the spoken language, and search engines index caption text better than audio.

• Keyboard access helps anyone in a hurry. Fast typists, people with a sprained wrist, and anyone whose trackpad stops working all move through a page with the keyboard.

• Strong contrast holds up in bright sunlight. Text that meets the contrast standard stays readable on a phone outside at noon.

• Clear language reaches tired and distracted readers. Short sentences and plain words help a person reading in a second language, on a small screen, or at the end of a long day.

What legal and procurement risk comes with waiting?

For leaders, this is the part that shows up in contracts and court filings. The rules differ by who you are and where you sell, and each one points back to the same technical standard, the Web Content Accessibility Guidelines (WCAG).

• The Americans with Disabilities Act (ADA) covers businesses open to the public. Department of Justice guidance says the ADA's requirements apply to all the goods, services, privileges, or activities that a business open to the public offers, including those offered on the web. Web accessibility lawsuits against businesses are brought under Title III of the ADA.

• State and local governments have a set standard. The Justice Department's 2024 rule under Title II of the ADA requires WCAG 2.1 Level AA for their web content and mobile apps. After a one-year extension in 2026, governments with a total population of 50,000 or more must comply by April 26, 2027, and smaller governments and special district governments must comply by April 26, 2028. Check ada.gov for the current dates before you plan around them.

• Federal work runs through Section 508. Section 508 requires equivalent access to technology that federal agencies develop, procure, maintain, or use. The Revised 508 Standards incorporate WCAG 2.0 Level AA, and vendors are expected to test their products and publish the results so agencies can weigh accessibility when they buy.

• The European Union applies the European Accessibility Act. Since June 28, 2025, the act has covered services such as e-commerce, consumer banking, e-books, and electronic communications provided to consumers, along with products such as computers and smartphones. Microenterprises that provide services are exempt.

A team that builds to the standard from the beginning can answer a procurement questionnaire with evidence. A team that waits has to answer with a plan.

What does accessibility from the start look like at each stage?

Accessibility belongs inside the work your team already does. Here is what that means at each stage, from the first interview to the last test.

Research includes disabled people from the first study.

Recruit participants who use screen readers, screen magnifiers, voice control, switch devices, and captions, along with people with cognitive disabilities. Pay them fairly, and let them use their own devices and settings. Ask about the workarounds they use today, because each workaround marks a place where a product failed someone.

Design settles contrast, focus, and structure before anyone writes code.

• Check contrast in the palette. WCAG asks for at least 4.5 to 1 for normal text, and 3 to 1 for large text, form fields, icons, and other interface parts.

• Design a visible focus state. Every link, button, and field needs a focus indicator that a sticky header or pop-up never hides.

• Annotate the structure. Mark headings, landmarks, reading order, and field labels in the design file, so developers build what you meant instead of guessing.

• Size targets for real fingers. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels, with some exceptions, and asks for a single-pointer option wherever a design relies on dragging.

Content says what people need in plain words.

Write link text that says where each link goes. Write alt text that says what each image is for. Write error messages that say what went wrong and how to fix the problem. Make every heading describe its section, so a screen reader user can skim by headings the way a sighted reader skims by eye.

The build starts with semantic HTML and targets WCAG 2.2 AA.

Use native elements first: real buttons, links, labels, headings, lists, and fieldsets. Add ARIA only when no native element does the job. Make every function work from the keyboard, and never require a puzzle or a memory test to sign in.

Set WCAG 2.2 Level AA as part of your definition of done. The W3C states that content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and 2.1, so one target lines up with the versions named in Section 508 and the Title II rule. Teams that report against 2.0 or 2.1 may still need to test the older Parsing criterion, which 2.2 removed.

Testing combines automated tools, manual review, and assistive technology.

1. Run an automated checker on every build. Automated tools catch missing labels and low contrast, but they can't judge whether alt text makes sense or whether the focus order is logical.

2. Test by hand with a keyboard alone, then with the page zoomed to 400 percent.

3. Test with screen readers, including VoiceOver, TalkBack, NVDA, JAWS, and Narrator, plus voice control.

4. Run usability sessions with disabled participants before release, and fix the barriers they find before launch.

To hear what one of these tests sounds like, read what a screen reader user hears on your checkout page.

Where do you start if the product has already launched?

Start with the flows that matter most: sign-up, sign-in, search, checkout, and anything that takes payment or personal information. Review those flows against WCAG 2.2 AA, fix the barriers that block people completely, and add accessibility to the definition of done so new work meets the standard from the first sketch. From that point on, accessibility comes first for everything new.

In short

• Accessibility from the start costs less than a retrofit, because early decisions spread across the whole product.

• Captions, keyboard access, strong contrast, and clear language improve the product for every user, and US and EU law increasingly requires accessible digital products.

• Put accessibility into every stage: research with disabled people, design, content, a WCAG 2.2 AA build, and testing with real assistive technology.

If you'd like an outside review of your product, from a single flow to a whole product, explore my accessibility audits.