Accessibility mistakes that cost you customers

I am auditing a client website. It looks good - modern, well-designed, built by a solid agency. I turn on keyboard navigation and within 3 seconds I have no idea where I am. Focus is invisible. The menu does not respond to Enter. The contact form has zero labels.

The client has no idea there is a problem. Google Analytics shows traffic, the form collects leads, the site "works." But how many people left because they could not use it? No tracker will show you that.

Here are the mistakes I see most often. Every one of them can be fixed - and none requires rebuilding the site from scratch.

Insufficient text contrast

The most common problem on business websites. Light gray text (#999) on a white background looks "elegant" and "minimal." The problem is that it is unreadable.

WCAG requires a minimum contrast of 4.5:1 for regular text. Gray #999 on white #FFF gives 2.85:1 - 40% below the requirement.

Where I see this:

• Product descriptions in online stores
• Footer information
• Form field placeholders
• Text on photos without a darkened overlay

How to fix: Change the text color to something darker. #595959 on white gives 7:1 - and still looks light. For text on photos - add a semi-transparent dark background behind it. 20 minutes of CSS work.

Missing alt text on images

A screen reader hits an image without alt text and reads the file name: "DSC_0847_final_v2.jpg." The user has no idea what is in the photo.

Worse: many sites have alt="" on all images. The screen reader skips them entirely - it does not know these are product photos, team photos, certificates. The visual content simply does not exist.

How to fix:

• Product: alt="Semmelrock Pastella concrete paving stone in gray"
• Team: alt="Anna Kowalska, project manager"
• Decoration (icon, divider): alt="" - and that is correct, because these images carry no content

Writing alt text for 30 images on a site takes about an hour. Once, not every week.

Elements not reachable by keyboard

The "Send inquiry" button works when clicked with a mouse, but Tab skips it. Why? Because instead of <button>, someone used <div onclick="...">. It looks like a button, behaves like a button, but for the keyboard and screen readers - it does not exist.

The same applies to dropdown menus, sliders, tabs, and modals. If an element is interactive, it must be reachable by keyboard. No exceptions.

How to fix: Use proper HTML elements. <button> instead of <div>, <a href> instead of <span onclick>. Add tabindex="0" where needed. Add Enter and Escape key handling for modals.

Forms without labels

A contact form. Three fields. Placeholders: "Name", "Email", "Message." Zero <label> elements.

The problem: the placeholder disappears once you click the field. A user with short-term memory issues does not remember what to type. A screen reader says "text field" with no context - it does not know if this is for a name, email, or bank account number.

How to fix: Add <label for="field"> to every field. You can visually hide the label (class sr-only) if the design requires it - but it must exist in the HTML. You can also use aria-label on the field. 15 minutes for the entire form.

Tap targets too small on mobile

44 by 44 pixels - that is the minimum touch target size per WCAG. Yet on many mobile sites I see links that are 20 by 12, checkboxes at 16 by 16, and close icons I hit correctly one time out of three.

The result? A user with larger fingers, hand tremors, or simply riding a bus - taps in the wrong spot. Once, twice, three times. And closes the site.

How to fix: min-height: 44px; min-width: 44px; on buttons and links in the mobile view. If a text link is too small - add padding. Simple CSS change, zero impact on the desktop layout.

Animations with no way to stop them

Parallax, animated backgrounds, elements sliding in on scroll. They look nice on a landing page, but for people with vestibular disorders (vertigo, migraines) they can cause physical nausea.

WCAG requires that users can pause, stop, or hide moving content. The operating system has a "Reduce motion" setting (prefers-reduced-motion) - but most websites ignore it.

How to fix: One line of CSS:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

That is it. Users who turned on "Reduce motion" in their system see the site without animations. Everyone else sees it normally. At dede.agency we also added a button in the accessibility widget that lets users stop animations manually.

What does it cost to fix these issues

None of the problems described here require a site rebuild. Most are CSS changes, added HTML attributes, or swapping <div> for <button>. For a typical business website - a few hours to two days of developer work.

What does it cost NOT to fix them? You cannot calculate that. These are people who did not fill out the form. Did not read the offer. Did not call. They will not come back, will not file a complaint, will not leave a bad review. They will simply go to a competitor whose site works for them.

Check your site

In the previous post I described 5 tests you can run yourself in 10 minutes. And if you want a professional audit and implementation - get in touch. We do this regularly for our clients, with every web project.