Five Accessibility Mistakes Service Business Websites Make (That Are Easy to Miss)
These are not the dramatic failures. They're the quiet ones, the issues that pass visual inspection and automated scans but block real users from completing real tasks on your site.
The accessibility failures that make headlines are dramatic: a federal lawsuit, a cease-and-desist, a story about a major retailer’s inaccessible checkout. Those failures happen. They’re also not the typical accessibility picture for a small service business.
The typical picture is quieter. A website that looks good, was built by a competent developer, has no glaring problems, and still blocks a meaningful segment of users from completing tasks they came to do. Not because of carelessness, but because accessibility requires a specific kind of attention that most web projects don’t apply.
Here are five failures that show up consistently in audits of service business websites and are almost universally invisible to visual inspection.
Missing or Misleading Form Labels
Forms are where most conversion happens on a service business site, the contact form, the booking form, the intake questionnaire. They’re also where accessibility failures are most consequential.
The failure pattern: form fields with placeholder text but no visible label. The field for “Email address” shows the placeholder “name@domain.com” inside the input box, but there’s no persistent label outside it. Visually, this can look clean and modern. For a screen reader user, the field may be announced only as an unlabeled edit field, offering no instruction about what information goes there.
When the user types in the field, the placeholder text disappears. Now both the visual and programmatic label are gone. A screen reader user filling out a multi-field form may have no reliable way to know what each field expects.
The fix is straightforward: every input needs a visible, programmatic label, a <label> element properly associated with its input via for and id attributes. Placeholder text is supplementary, not a substitute.
Focus Indicators That Are Invisible
Keyboard users, people who navigate with Tab, Shift+Tab, Enter, and arrow keys because they cannot use a mouse, rely on the focus indicator to know which element is currently selected. The focus indicator is typically a border or highlight around the focused element.
Many website designs suppress the default browser focus indicator with outline: none in the CSS because the blue ring looks inconsistent with the design. This is a WCAG failure (Success Criterion 2.4.7 and 2.4.11 at 2.2 AA) and a significant usability barrier.
A keyboard user navigating a site with no visible focus indicator is essentially navigating blind, they can press Tab and move through the page, but they can’t see where they are. Finding a specific link, button, or form field requires guessing and backtracking.
The fix does not require keeping the default browser ring. It requires designing a visible alternative: a high-contrast border, a background change, a custom highlight that is clearly visible against the surrounding content. The only requirement is that it exists and is visually apparent.
Low Contrast in Secondary Text
Headline text usually passes contrast checks. The small text often doesn’t.
WCAG 2.2 AA requires a contrast ratio of at least 4.5:1 for normal-sized text and 3:1 for large text (roughly 18pt regular or 14pt bold). This applies to body copy, navigation text, labels, helper text, error messages, and placeholder text, not just headings.
The failure pattern: a design that uses a lighter gray for secondary content (captions, subheads, navigation items, footer links) under the assumption that slightly lower contrast is acceptable for non-primary text. In many cases, it isn’t. Gray text on a white background is one of the most consistently failing combinations in service business website audits.
The specific numbers matter. A ratio of 3.8:1 fails the AA standard even though it looks nearly identical to 4.5:1 to most viewers. Contrast checking requires a tool, not a visual judgment, tools like the WebAIM Contrast Checker or browser accessibility inspector extensions can produce the exact ratio for any color combination.
Non-Descriptive Link Text
“Click here.” “Learn more.” “Read more.” “Get started.”
These link texts appear on almost every service business website, and each one is an accessibility failure for screen reader users. Screen readers have a feature that lists all links on a page for navigation; it’s one of the most common ways users scan for navigation options without reading every word. A list of “Click here (×4), Learn more (×6), Read more (×3)” provides no information about where those links go.
Descriptive link text names the destination or the action: “Read our accessibility services overview,” “Schedule a 15-minute introductory call,” “Download the accessibility audit checklist.” This serves screen reader users and also improves clarity for all users.
The fix requires only editing the link text. No development work. No design changes. Just replacing the generic phrase with the specific destination. On a typical service business site, this is a two-hour task.
Images with Generic or Missing Alt Text
Alt text for images serves two functions: it provides a text alternative for users who cannot see the image, and it is read aloud by screen readers in place of the image.
The failure pattern has two forms. The first is no alt text at all, an image with an empty alt attribute, which causes the screen reader to announce the filename or skip the image entirely. The second is generic alt text, “image.jpg,” “photo,” “decorative,” or in some cases, the same alt text used for every image on the page.
Both fail WCAG Success Criterion 1.1.1. The fix is to write alt text that describes the meaningful content or function of each image. For decorative images, visual elements that provide no information, the correct alt text is alt="", which tells the screen reader to skip it. For informational images, the alt text should describe what the image communicates, not what it depicts. “Bar chart showing 40% increase in review volume after implementation” communicates more than “chart.”
This is judgment work, not technical work, which is why it doesn’t get fixed by automated remediation tools. It requires someone to look at each image and write a description of what it contributes.
The Common Thread
None of these failures require exceptional technical skill to create, they’re easy to miss because they’re invisible in visual design review and most of them don’t surface in automated scans. Each one requires human attention and deliberate testing to find.
Together, they describe a site that may look polished and convert reasonably well for users without assistive technology needs, while creating significant barriers for a meaningful segment of potential clients. The COREaccess™ Accessibility Leadership System covers the full framework — audit, remediate, train, and monitor — for organizations that need documented, standards-based conformance.
The Small Business Owner’s Guide to Website Accessibility covers the full scope of what website accessibility requires and how small businesses should approach it. If any of these patterns sound familiar on your site, a 15-minute conversation about COREaccess™ is a practical place to start building the picture.