Most owners do not ignore accessibility because they do not care. They ignore it because of something they heard: it only matters for blind visitors, a plugin handles it, it will make the site look like a government form, it is a problem for big brands. Each of these sounds reasonable, and each one leads to decisions that leave real customers stuck.
Below are seven website accessibility myths that come up again and again with US business owners, office managers and marketing teams, each with what is actually true and what to do about it.
Myth: accessibility is only for blind people
Screen reader users are the group people picture first, and they matter. They are also one group among many. Think about who else visits your site:
- someone with low vision who zooms the page in until only a few words fit across the screen
- someone who is deaf or hard of hearing and needs captions on your video
- someone with a tremor or limited hand movement who uses only a keyboard, a switch or voice control
- someone with a cognitive disability or memory difficulty who struggles with a login that demands a code copied from another app
- someone with a broken wrist this month, or holding a baby in one arm
- anyone using a phone in bright sunlight
WCAG reflects that range. 1.2.2 Captions (Prerecorded) is for deaf visitors. 2.1.1 Keyboard is for anyone who cannot use a mouse. 2.5.8 Target Size (Minimum) sets a minimum size of 24 by 24 CSS pixels for clickable controls, with exceptions such as enough spacing between small ones, so people with limited dexterity can hit what they aim at. 3.3.8 Accessible Authentication (Minimum) is about logins that do not depend on memory puzzles. None of these are about blindness.
What to do: when you test, do not just turn on a screen reader. Put the mouse away and tab through a form. Zoom the browser in. Watch a video with the sound off.
Myth: a plugin or widget can take care of it
This is the myth with the best marketing behind it. A toolbar or script loads on top of your pages and promises to make them accessible automatically. What it cannot do is write meaningful alt text, rebuild a menu whose submenus appear only on mouse hover, caption your videos, fix your PDFs or reach into a booking widget loaded from another company’s server. Sites that run these tools have still received demand letters.
Some plugins are genuinely useful, such as checkers that list issues for a person to fix, or small helpers that add a skip link. The difference is whether a human still does the fixing. For the longer explanation, including the FTC action against one vendor, see how overlay toolbars work and where they fall short.
What to do: treat any product that promises instant compliance with caution, and put the effort into the site itself.
Myth: once it is fixed, it stays fixed
An accessible site is a state, not a certificate. It changes every time somebody touches it.
A theme update restyles buttons and the focus outline disappears. A new plugin adds a pop-up that traps keyboard users. The new office manager uploads twenty staff photos with no descriptions. The marketing team adds a carousel for a seasonal offer and forgets the pause button. Six months later, the site that passed its audit has a fresh list of barriers, and nobody did anything wrong on purpose.
What to do: build a light routine. Check new pages as they go live, tab through key forms after updates, and review a sample of pages every month. If you would rather not run that yourself, this is exactly what ongoing accessibility monitoring is for.
Myth: accessible design looks plain
Designers sometimes hear “accessible” and picture black text on a white page with no images. That is not what WCAG asks for.
- Contrast rules (4.5:1 for normal text, 3:1 for large text and for meaningful parts of controls under 1.4.11) leave room for a wide palette. Usually the fix is darkening one brand gray, not abandoning your colors.
- A visible focus indicator can match the brand: a thick outline in your accent color, an underline, a change of background.
- Images, video and motion are all allowed. Images need text alternatives, video needs captions, and anything that moves by itself for a while must let visitors stop it, which is the subject of 2.2.2 Pause, Stop, Hide.
- Typography can be expressive as long as text can be resized and spacing adjusted without the layout breaking.
Clear hierarchy, generous spacing and readable text are simply good design, and nobody calls them plain.
What to do: ask your designer to check contrast and focus states while choosing colors, not after launch, when changes feel like a loss.
Myth: only big companies need to worry
National retailers and chains attract the headlines, so it is easy to assume a ten-person firm is out of scope. In practice, small business sites receive demand letters too. A ten-person firm’s site usually runs on the same mainstream themes and plugins as a large company’s, faults included. A website is visible to anyone with a browser and a free scanner, whatever the size of the company behind it.
How the ADA applies to a particular business is a legal question for a lawyer, and nothing here is legal advice. For the general picture, see our guide to ADA compliance for websites, and for the size question specifically, how being a small business fits in.
What to do: scale the effort to the site. A small site with a handful of templates and one contact form is a manageable job if you start with the tasks customers actually come to do.
Myth: nobody has complained, so nobody needs it
People who hit a barrier rarely write in. They leave. A customer who cannot get past your booking form with a keyboard phones a competitor, or gives up. Your analytics record a short visit and nothing else.
Silence is not evidence that the site works. It may only mean the people it fails have stopped trying.
What to do: make it easy to report a problem, with a clear contact route in your accessibility statement or footer, and test the main tasks yourself rather than waiting for feedback that may never come.
Myth: if it works on a phone, it is accessible
A responsive theme is a good start, and 1.4.10 Reflow does ask that content works on narrow screens. But a site can look tidy on a phone and still fail people. Common examples: pinch zoom disabled in the page code, tiny icon links packed too closely together, a mobile menu button that VoiceOver or TalkBack announces only as “button”, form fields with no labels, a chat bubble covering the “Submit” button.
What to do: on your phone, turn on the built-in screen reader for five minutes and try to reach your contact page. It is uncomfortable the first time, and very instructive.
Why website accessibility myths stick around
Website accessibility myths and the wider accessibility misconceptions behind them survive for a simple reason: the people they hurt are not in the room when decisions are made. The owner, the designer and the developer can all use the site comfortably, so nothing looks wrong. Spend one afternoon watching someone use your site with a screen reader, a keyboard or heavy zoom, and most of the myths above stop sounding reasonable.
Frequently asked questions
Which of these myths causes the most harm?
The idea that a plugin or widget handles everything, because it convinces owners the job is finished. The forms, menus, documents and videos stay exactly as they were, the barriers remain, and the false sense of safety means nobody looks again. The one-time-fix myth comes a close second, since it lets good work quietly decay.
Does making a site accessible slow it down?
Real fixes usually do not. Labels, headings, alt text, focus styles and better contrast weigh next to nothing compared with a single photo. Removing an unused slider or a heavy toolbar script can even make pages lighter. The things that slow sites down are large images and stacks of third-party scripts, which are unrelated to accessibility work done properly.
Is accessibility only about the website code?
No. A lot of it lives in content that editors control: headings, link wording, image descriptions, captions, PDF documents, plain language and tables. Code fixes in the theme and plugins matter, but a well-coded site can still become hard to use if new content is published without these habits.
Who should own accessibility on a small team?
Give one person responsibility for it, even if they do not do all the work. That person makes sure new content is checked, updates are followed by a quick keyboard test, and reported problems get fixed. Developers handle code and plugins; editors handle content. Without a named owner, it tends to slip.
When you are ready to move past the myths and look at your own pages, our ADA website compliance help covers the practical part: testing against WCAG 2.2 AA, fixing the barriers and documenting the results, with legal questions left to your lawyer. You can also browse the full range of accessibility services for US businesses.
