Last updated: May 2026
If you build websites, accessible web development is no longer the part of the brief you can defer to phase two. The latest WebAIM Million 2026 analysis found that 95.9% of the top one million home pages had detectable WCAG 2 failures, averaging 56.1 errors per page. That's not a fringe problem; that's nearly every site on the open web. This guide walks through the five practitioner dos and don'ts we use on every Major Tom build (images, links, headings, colour, spacing) plus the legal, SEO, and revenue case for getting them right.
The five accessible web development priorities, in order of impact:
- Make every image accessible (descriptive alt text, no text-in-images, no flashing content).
- Write links that describe their destination, not "click here."
- Use a clean heading hierarchy, never skipping levels for visual effect.
- Hit WCAG 2.2 AA color contrast and never rely on color alone to convey meaning.
- Space out interactive elements and respect real-world device and motor-skill variation.
If you're new to this topic, our introductory overview of web accessibility covers the awareness layer (what WCAG is, who it helps, why it matters). This post is the practitioner deep-dive: what to actually do, what to actively avoid, and how to bake it into a build rather than retrofit it under deadline pressure.
Why accessible web development matters more in 2026
Three numbers worth keeping in front of any leadership team weighing whether to invest.
First, the technical baseline. The WebAIM Million 2026 report found 95.9% of the top one million home pages had detectable WCAG 2 failures, averaging 56.1 errors per page. Low-contrast text shows up on 83.9% of pages, missing alt text on 53.1%, missing form labels on 51%. These aren't edge cases; they're the dominant failure modes.
Second, the legal exposure. Seyfarth's ADA Title III news recorded 3,117 federal website accessibility lawsuits in 2025, a 27% jump from 2024. Demand letters that never reach federal docket sit on top of that figure.
Third, the regulatory floor. Under the DOJ's Title II final rule (as amended April 2026), state and local government web content and mobile apps must conform to WCAG 2.1 Level AA by April 26, 2027 (entities serving 50,000+ people) or April 26, 2028 (smaller entities and special districts). The private-sector standard isn't legally codified the same way, but plaintiffs' firms apply WCAG anyway, and we recommend building to WCAG 2.2 AA (finalized October 2023) as the current floor.
When we kick off a new build at Major Tom, WCAG 2.2 AA is the default acceptance criterion, not a feature request that gets cut when the timeline slips. That decision saves clients legal exposure later and saves us the cost of retrofitting an inaccessible design system.
1. Make your images accessible to your entire audience
Imagery is how a site sells a product, sets a mood, or guides a user through a flow. For someone using a screen reader or magnifier, your images either reinforce the page or dampens the experience.
DO: Write descriptive, meaningful alt text for every non-decorative image
Alt text gives users with visual impairments access to the same information sighted users get. Keep it brief, keep it specific, and keep it relevant to the surrounding content. Decorative images (stylistic dividers, purely visual flourishes) should have empty alt (alt="") so screen readers skip them rather than reading filler.
DO: Provide longer descriptions in body copy for complex visuals
For dense charts, infographics, or diagrams, give a short summary in the alt attribute and a fuller description nearby in the page text. That way a screen-reader user can decide whether the detail is worth the time, instead of being trapped inside a 200-word transcription they didn't ask for.
DON'T: Put critical text inside images
Text baked into an image is invisible to screen readers and to search engines. Both your accessibility and your SEO take a hit. If it's not part of the design language (a logotype, say), it belongs in real HTML.
DON'T: Hand alt text to AI without human review
Automated alt-text generators are useful for first drafts but routinely miss the purpose of an image. They describe what's literally there, not why the image matters on that page. When we audit client sites, AI-generated alt is one of the most common sources of "technically present, practically useless" content. Review it.
DON'T: Use flashing or rapidly blinking content
Flashing visuals can trigger seizures in users with photosensitive epilepsy. WCAG 2.2 sets a hard line here: nothing should flash more than three times per second. Leave the garish GIFs in the 1999 archive where they belong.
2. Present your links the right way
Links are the navigation system of the web. Done well, they let any user (sighted, screen reader, keyboard-only) understand where they're going before they get there.
DO: Use descriptive link text that names the destination
"Read our UX/UI design services page" beats "click here" every time. Screen-reader users often navigate by pulling up a list of links on a page, stripped of surrounding context. If your links read "click here, click here, learn more, click here," that list is useless.
DO: Make link styling visible in normal and hover states
Color alone isn't enough (we'll get to that in section 4). Use underlines, weight changes, or icons so the link is identifiable to users who can't perceive the colour difference.
DON'T: Stack identical links next to each other
Two links pointing to the same place, one after the other, double the keyboard navigation cost without adding information. Consolidate.
DON'T: Open every external link in a new tab without warning
Forced new tabs break the back button and disorient assistive-tech users. If you do open a new tab, signal it in the link text or via an icon and an aria-label.
3. Use headings to organize your page
Heading hierarchy is the table of contents a screen-reader user navigates with. Get it wrong and the page becomes a maze.
DO: Use semantic heading levels in order
One H1 per page (the page title), then H2s for major sections, H3s nested inside H2s, and so on. Skipping from H1 to H4 because the H4 "looks right" breaks the document outline and confuses every screen reader trying to build a navigable structure.
DON'T: Style body text as a heading to grab attention
If something needs visual emphasis, style it. Don't wrap it in an H3 it doesn't deserve. Heading tags carry semantic meaning that assistive tech relies on; treat them as structure, not decoration.
4. Use the right colors in the right way
Color does heavy lifting in brand design. It also routinely tanks accessibility scores when it's the only signal carrying meaning.
DO: Hit WCAG 2.2 AA contrast ratios
Body text needs a 4.5:1 contrast ratio against its background; large text (18pt+ or 14pt bold) needs 3:1. Free tools like the WebAIM contrast checker resolve this in seconds. Low-contrast text was the most common WCAG failure in the 2026 Million report, on 83.9% of pages audited; this is the single highest-leverage fix you can ship today.
DO: Use shape, label, and pattern alongside color
Form validation, chart legends, status indicators: anywhere color communicates meaning, pair it with text, an icon, or a pattern. Users with color blindness shouldn't be locked out of a graph because red and green were the only differentiators.
DON'T: Rely on color alone for required form fields
A red asterisk is not enough. Use the word "required," a clear label, and an aria-required attribute so assistive tech catches it.
5. Use proper spacing for clickable elements
Cramped UI is bad for everyone and disqualifying for users with motor impairments, tremors, or anyone navigating on a touchscreen in a moving vehicle.
DO: Give interactive elements room to breathe
WCAG 2.2 introduces a target-size minimum of 24x24 CSS pixels for most interactive elements, with broader recommendations of 44x44 for primary touch targets. Buttons, links, form controls: give them padding and space so a slightly imprecise tap still lands.
DO: Build responsive layouts that hold up across devices
A perfectly accessible desktop site can become unusable on a 5.5-inch phone if interactive elements collapse into each other. Test on real devices, not just resized browser windows. For deeper enterprise-scale considerations, our writeup on complex website usability issues for large-scale organizations walks through where multi-template, multi-locale sites tend to break.
DON'T: Use tiny or decorative fonts for body content
16px is a sensible floor for body text. Display fonts and stylized type are fine for short headlines; they're punishing for paragraphs.
DON'T: Use whitespace characters to fake layout
Extra spaces, hard returns, or tab characters used as formatting break assistive tech and collapse unpredictably across screen widths. Use CSS for layout.
How to test accessibility before shipping
Automated tools catch maybe a third of real WCAG failures, which still makes them the right first stop. Combine them with manual checks and assistive-tech testing.
- Automated scanners: WAVE, Lighthouse (built into Chrome DevTools), or axe DevTools.
- Screen readers: NVDA (free, Windows), VoiceOver (built into macOS and iOS), JAWS (enterprise standard).
- Keyboard-only navigation: unplug the mouse and tab through the page. If you can't reach a control, neither can a keyboard user.
- Manual contrast checks: WebAIM contrast checker, or the contrast eyedropper in your design tool.
Tools tell you about the easy failures. Lived experience tells you about the hard ones. Where the budget allows, paid user testing with people with disabilities is the gold standard, and Major Tom routinely pulls it into discovery for enterprise builds.
What you stand to gain from an accessible website
Accessibility isn't only about avoiding lawsuits. The same work pays back in measurable business outcomes.
Larger addressable audience: Roughly one in four U.S. adults reports a disability. Designing them out shrinks your market.
Stronger SEO: Semantic HTML, descriptive link text, and meaningful alt copy are the same signals search engines parse. Accessible sites tend to rank better on the same content.
Higher conversion: Clear labels, predictable navigation, and uncluttered interactive areas reduce friction for every user. Accessibility and CRO point in the same direction; we find clients see knock-on conversion lifts even when the brief was purely compliance-driven.
Brand trust: Audiences notice when a brand has actually done the work. Genuine accessibility reads as integrity, especially when an accessibility widget overlay (which we strongly recommend against) often reads as a shortcut.
This is the same logic that drives our advice in what an industry-leading website actually looks like: the disciplines that make a site genuinely best-in-class (performance, accessibility, content quality) are the same ones that move commercial metrics.
Maintain accessibility after launch
Accessibility regressions happen quietly. A marketer drops in a new image without alt text. A developer ships a new component with insufficient contrast. A plugin update changes focus order. Without an ongoing program, a site that passed audit at launch will drift below WCAG 2.2 AA inside a year.
The clients we work with on retainer get accessibility folded into the same cadence as performance and security: monthly automated scans, quarterly manual spot-checks, and a clear escalation path when something fails. Our guide to website maintenance and optimization covers the broader operating model.
Find clarity in the chaos
Accessibility done well doesn't slow a project down; it sharpens it. Clearer hierarchy, cleaner code, more deliberate UI choices. If you want help building or auditing a site to WCAG 2.2 AA from kickoff, our team can design and develop a site that hits the bar on day one and holds it after launch.
Become fully accessible online: talk to Major Tom about your next build.
FAQs
What is WCAG and which version should I build to?
WCAG (Web Content Accessibility Guidelines) is the international standard published by the W3C for making web content accessible. The current version is WCAG 2.2, finalized in October 2023; WCAG 3.0 is in draft. We recommend building to WCAG 2.2 Level AA as the practical floor, since AA is the level cited in most regulations and most plaintiff demand letters worldwide.
Does my business website have to be accessible by law?
In the United States, the DOJ's 2024 Title II rule (as amended April 2026) requires state and local government sites to meet WCAG 2.1 AA by April 2027 or April 2028 depending on size. Private-sector obligations come through ADA Title III case law, where plaintiffs apply WCAG anyway. Canada, the EU, and the UK have their own statutes. The safest answer is yes, build to WCAG 2.2 AA regardless.
What are the most common web accessibility mistakes?
The WebAIM Million 2026 report ranks the top failures by frequency: low-contrast text (83.9% of pages), missing alt text on images (53.1%), and missing form labels (51%). Empty links, missing document language attributes, and skipped heading levels round out the top six. Fixing these three categories alone resolves the bulk of automated-tool failures on most sites.
How much does it cost to make a website accessible?
Costs vary by scope. Retrofitting accessibility into an existing site typically runs higher than building it in from the start, because design, content, and code all need rework. Building to WCAG 2.2 AA from kickoff usually adds little to no incremental cost when accessibility is baked into design review, dev acceptance criteria, and QA. Lawsuits, by contrast, can run into six figures.
Are accessibility overlay widgets a good solution?
No. Overlay widgets (third-party scripts that add an accessibility toolbar) consistently fail to fix underlying WCAG issues and have themselves been the subject of accessibility lawsuits. Screen-reader users and accessibility advocates broadly advise against them. The only durable solution is accessible code, content, and design built into the site itself.
How do I test my website for accessibility?
Use a layered approach. Run automated scanners (WAVE, Lighthouse, axe DevTools) to catch the easy failures. Manually navigate the site with a keyboard only, then with a screen reader (NVDA on Windows, VoiceOver on Mac). Check color contrast with the WebAIM contrast checker. For high-stakes builds, commission usability testing with disabled participants. Combine all four for honest coverage.
