The fastest way to misunderstand accessibility is to treat it like a score you need to raise. The point is not getting a prettier report. The point is helping more people use the site.
A small-business website does not need a 300-page internal accessibility program before somebody fixes the invisible keyboard focus, the unlabeled contact form, and the gray text sitting on slightly lighter gray because apparently contrast offended the brand guide.
Accessibility is not a plugin problem.
Tools can help. Automated scans can catch real issues. Overlays can add interface controls. None of those things replace accessible markup, sensible interaction design, understandable content, and testing the actual tasks people need to complete.
Start with the jobs the website exists to support. Can somebody find your phone number? Open the menu? Book an appointment? Submit the contact form? Read the pricing? Complete checkout? If one of those tasks breaks because a person uses a keyboard, screen reader, zoom, high contrast settings, captions, or a different input method, that is not a theoretical issue. The task is broken.
Ask whether the important flows still work for people who navigate, perceive, or interact with the page differently. That question gives you something you can actually test.
Start by firing the mouse for five minutes.
Use the Tab key to move through links, buttons, fields, menus, dialogs, and other controls. Use Shift + Tab to go backward. Press Enter or Space where appropriate. Try to complete one important task without touching the mouse.
You should be able to reach interactive controls in a sensible order, operate them, and see a visible focus indicator showing where you are. If focus disappears behind a sticky header, jumps somewhere bizarre, or becomes visually invisible, keyboard users are doing detective work instead of using your website.
WCAG 2.2 added more guidance around focus visibility, focus not being obscured, target size, dragging alternatives, and accessible authentication. You do not have to memorize every success criterion before fixing an obvious problem. Start with the interaction that failed, then use the standard to understand the requirement behind it.
Alt text is not a place to dump keywords.
Alternative text should communicate the purpose or useful information an image contributes when that image cannot be seen. Sometimes that means a short description. Sometimes a decorative image should use an empty alt attribute so assistive technology can ignore it. Sometimes the surrounding text already explains everything and repeating it would just make the page more annoying.
A photo of your storefront may need to identify the business. A chart needs its important information communicated in text. A decorative texture behind a hero probably does not need to announce itself like it just arrived at a party.
An automated tool can often detect a missing alt attribute. It cannot reliably decide whether "IMG_4827.jpg" explains the image. Human judgment still has a job.
Your form should explain itself before it gets angry.
Form fields need labels that identify what the user should enter. Placeholder text is not a substitute for a real label. It disappears when people type, often has poor contrast, and can make error recovery harder.
When validation fails, the message should say what went wrong and how to fix it. Do not rely on a red outline alone. Somebody who cannot distinguish that color still needs to know which field failed and why.
| Weak pattern | Better pattern |
|---|---|
| Placeholder says "Email" | Visible Email label connected to the input, with placeholder used only as optional example text. |
| Field turns red | Field is identified and a text message explains the error and how to correct it. |
| Required fields use only * | The symbol is explained or the field includes a clear required cue in text. |
If the text is technically there but nobody can read it, congratulations on the technicality.
Sufficient contrast helps people with low vision, color vision differences, aging eyes, poor displays, glare, and a long list of normal real-world conditions. WCAG defines measurable contrast requirements for text and user-interface components, which is why contrast checkers are useful here.
Color also should not be the only way information is communicated. If a green dot means available and a red dot means unavailable, add text, an icon with an accessible name, or another cue that does not depend entirely on perceiving the color difference.
Good headings are navigation, not font sizes wearing costumes.
Use actual heading elements to describe the page structure. A heading should identify the section that follows it, and the hierarchy should make sense. The same idea applies to landmarks, navigation labels, buttons, and links. The code should describe what something is and what it does.
"Click here" tells very little when links are read out of context. "View catering menu" tells people what they are opening. A button with only a mystery icon may look clean, but if it has no accessible name, the interface may be clean right up until somebody tries to understand it.
If your page structure is generally confusing even before accessibility enters the conversation, the small-business website clarity guide is a useful companion. Accessible structure and understandable structure have a lot of overlap because both require the page to make sense.
Automated scanners are useful. They are not witnesses under oath.
WAVE can identify many accessibility and WCAG-related errors and then help a human evaluate the page in context. Browser accessibility audits can catch additional machine-testable problems. Contrast checkers can verify color ratios. These tools are excellent for finding things you should inspect.
What they cannot do is certify that a website is fully accessible. A scanner may confirm that an image has alt text while missing that the text is nonsense. It may see a button while a keyboard user cannot reach it. It may pass a form field whose instructions make no sense to a human being.
The SEO Health Checker catches some accessibility basics too.
The Template Forge SEO Health Checker can flag some machine-observable accessibility basics while it reviews the rest of the page. That does not make it an accessibility certification tool. It gives you another set of clues about what deserves inspection.
Run the free SEO checkAnd yes, there is a legal side to this.
In the United States, the Department of Justice says the ADA applies to the goods, services, privileges, and activities that businesses open to the public provide online. For private businesses under Title III, the Department does not publish one detailed technical web standard that functions as a universal checklist for every situation. It points businesses toward established accessibility practices and technical standards such as WCAG for guidance.
WCAG 2.2 is the current W3C Recommendation in the WCAG 2 series. It has three conformance levels: A, AA, and AAA. Many organizations work toward Level AA, but passing an automated WCAG scan is not the same thing as proving legal compliance.
If you need to determine legal obligations for a specific business, location, industry, contract, or government relationship, talk with qualified counsel and an accessibility professional. Do not let a plugin sales page make that decision for you.
Sources worth keeping open while you test
- W3C Web Accessibility Initiative: WCAG overview
- W3C: what is new in WCAG 2.2
- WAVE Web Accessibility Evaluation Tool
- U.S. Department of Justice: guidance on web accessibility and the ADA
Make the important tasks boringly usable.
Accessibility work can get technical, but the starting point is wonderfully unglamorous: people need to read the page, understand the controls, move through the interface, recover from mistakes, and finish what they came to do.
Test those tasks with more than one way of using the site. Fix what breaks. Then use standards and tools to keep finding the problems you did not notice the first time.