Accessible Website Development: What Actually Breaks
Accessible website development means building pages that work for keyboard, screen reader, and low vision users from the start. For Nassau County businesses in 2026, the biggest fixes are real form labels, sufficient color contrast, no keyboard traps, and alt text on images. That covers most WCAG 2.2 and ADA risk.
Part of the complete web design guide.
On this page
- Why this matters more now than it did five years ago
- The four failures I find most often
- 1. Form inputs with no real label
- 2. Text that fails contrast
- 3. Keyboard traps and invisible focus
- 4. Images with no text alternative
- Testing it without buying anything
- Where an audit fits into a real project
- Frequently asked questions
- Do I legally have to make my website accessible?
- How much does it cost to fix an existing site?
- Will accessible design make my site look worse?
Most “accessible website” articles are either legal scare pieces or a checklist of alt text advice you already know. I want to show you what actually breaks on real business sites, why it breaks, and the specific code that fixes it. I build sites for companies in Nassau County and across Long Island, so the examples below are the kinds of problems I run into constantly.
Accessibility is not a separate project you bolt on at the end. It is a set of decisions you make while writing markup, and most of them take less time than the bug you would file later. Let me walk through the ones that matter most in 2026.
Why this matters more now than it did five years ago
Two things changed. First, WCAG 2.2 became the baseline most auditors and courts reference, and it added requirements like focus appearance and target size that catch a lot of older sites. Second, the volume of ADA web lawsuits filed against small businesses in New York has not slowed down. You do not need to be a national brand to get a demand letter. A local service business with a contact form and a menu can get one.
I am not a lawyer and this is not legal advice. But I have watched enough of these complaints to know they tend to target the same handful of failures: missing form labels, low contrast text, keyboard traps in navigation, and images with no text alternative. Fix those four and you remove most of the risk.
The four failures I find most often
1. Form inputs with no real label
This is the single most common issue I see. Someone builds a nice-looking form, drops in a placeholder, and calls it done. A screen reader user hears “edit text” with no idea what to type. Placeholders also disappear the moment you start typing, so they are useless as labels for anyone.
<!-- Bad: placeholder only -->
<input type="email" placeholder="Email address">
<!-- Good: a real, associated label -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">The for attribute on the label has to match the id on the input. If you are wrapping the input inside the label instead, you can skip the for and id, but I find the explicit version easier to maintain. Add autocomplete while you are there. It helps everyone and it is a WCAG 2.2 win.
2. Text that fails contrast
Light gray text on white is a design trend that fails people with low vision and anyone reading a phone in sunlight. WCAG 2.2 wants a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (roughly 18.66px bold or 24px regular and up).
You do not need to guess. Open your browser dev tools, inspect the text, and look at the color picker. Chrome and Firefox both show the contrast ratio right there and flag failures. If a brand color fails, you usually do not have to abandon it. Darken it a shade or two. I have taken a client’s light teal and pulled it down until it passed, and nobody noticed the difference except the people who needed it.
3. Keyboard traps and invisible focus
Every interactive element on your site has to be reachable and usable with a keyboard alone. Tab through your own site right now. If you cannot see where focus is, that is a WCAG 2.2 failure called focus appearance. If focus gets stuck somewhere, that is a trap and it is a hard blocker.
The fix is usually CSS discipline. Do not do this:
/* Bad: removes the focus ring for everyone */
button:focus,
a:focus {
outline: none;
}If the default ring clashes with your design, replace it with something visible rather than deleting it. WCAG 2.2 sets a minimum size and contrast for the indicator:
/* Good: a clear, high-contrast focus indicator */
a:focus-visible,
button:focus-visible {
outline: 3px solid #1a1a1a;
outline-offset: 2px;
border-radius: 2px;
}Note :focus-visible instead of :focus. It shows the ring for keyboard users and hides it for mouse clicks, which keeps designers happy without punishing anyone.
4. Images with no text alternative
Every meaningful image needs an alt attribute. Decorative images need an empty one. The mistake people make is writing alt text like a keyword or leaving it off entirely.
<!-- Meaningful: describe the content and purpose -->
<img src="storefront.webp" alt="Our office on Main Street in Mineola">
<!-- Decorative: empty alt, no role needed -->
<img src="divider.svg" alt="">If an image is inside a link and the link has no text, the alt text becomes the link name. So the alt has to describe where the link goes, not just what the picture shows.
Testing it without buying anything
You can catch most problems for free before you ever pay for an audit:
- Unplug your mouse and work through the whole site with Tab, Enter, and the arrow keys.
- Run the built-in Lighthouse accessibility check in Chrome dev tools. It is not perfect but it catches the obvious stuff.
- Install the axe DevTools browser extension. It is more thorough than Lighthouse and tells you exactly which element failed and why.
- Turn on your operating system’s screen reader for ten minutes. VoiceOver on Mac, Narrator on Windows. You will learn more in ten minutes than in an hour of reading.
- Zoom to 200 percent and see if anything overlaps or disappears.
Automated tools catch roughly a third of real issues. The rest requires you to actually use the site the way a person with a disability would. That is why I test by hand on every project.
Where an audit fits into a real project
If your site is already live, the practical sequence is: automated scan first to get a list, manual keyboard and screen reader pass second to catch what the scan misses, then fix in order of severity. Forms and navigation first, because those block tasks. Contrast and alt text next. Then re-test.
If you are building something new, fold accessibility into the build. It is far cheaper than retrofitting. When I take on Long Island web design work, semantic HTML and labeled forms are part of the base build, not an add-on I bill for later. It costs almost nothing to do it right the first time and a lot to undo it.
Frequently asked questions
Do I legally have to make my website accessible?
For most businesses open to the public, treat it as yes. Courts have generally read the ADA to cover websites, and New York has seen a steady stream of filings against small businesses. Even where the law is murky, the fixes are cheap and the downside of ignoring them is not.
How much does it cost to fix an existing site?
It depends entirely on how the site was built. A clean WordPress or hand-coded site with a handful of issues might take a few hours. A site built on a bloated page builder with unlabeled forms everywhere can take considerably longer, because some fixes require rebuilding components rather than tweaking CSS. Get a written scope before anyone starts.
Will accessible design make my site look worse?
No, and this is the myth I push back on most. Better contrast, clear focus states, and real labels make a site easier for everyone, including people on old phones or in bright rooms. Good accessibility is just good design with more people in mind.
