Accessibility Is Not Optional: WCAG for Marketing Sites

Accessibility on a marketing website is usually treated as a legal exposure to be minimised: a footnote in a contract, a checkbox in a procurement questionnaire, and a plugin.

That framing is both wrong and, increasingly, expensive.

Accessibility requirements are now written into law across most major markets — the European Accessibility Act, the Americans with Disabilities Act as applied to websites, the Equality Act in the UK, and equivalents in Canada and Australia. Public-sector procurement in most countries requires conformance as a matter of course. And the commercial case has stopped being arguable: accessible design is also faster, cheaper to build, better for SEO, and better for everyone on a slow connection.

Here is a practical guide to what actually matters on a marketing site.

Why marketing sites are specifically exposed

Marketing sites are where accessibility failures concentrate, for reasons that are structural rather than accidental:

• They are usually built last, after the product, under deadline pressure.

• They are rebuilt most often — every campaign means another template.

• They are built by people who did not write the content and will not maintain it.

• They are full of third-party embeds: chat widgets, maps, video players, forms, tracking scripts.

That last point deserves emphasis. A well-built template with a chat widget bolted on can fail more accessibility criteria than a mediocre site with no third-party scripts.

The criteria that actually fail on real sites

We audit a lot of these. The same handful of things come up.

1. Colour contrast on secondary text

Body text at full opacity is easy to pass. Secondary text is where most sites fail: captions, timestamps, helper text, form hints, table meta, disabled states, placeholder text, and any muted grey chosen by making the primary colour lighter.

WCAG 2.2 requires 4.5:1 for normal text and 3:1 for large text (18.66px bold or 24px regular). We check every pair against its actual backdrop, because a contrast ratio computed against pure white is meaningless when the element sits on a tinted section or inside a card.

2. Missing form labels and unclear errors

Placeholder text as a label is the most common failure we see. It disappears when the field is filled, it fails colour contrast by default in most implementations, and it is not reliably announced by screen readers.

What works: a visible <label> for every field, the error message associated programmatically with aria-describedby, and errors that say what to do rather than that something went wrong. "Enter a valid email address" beats "Invalid input".

3. Keyboard traps and focus problems

Everything interactive must be reachable and operable by keyboard. The usual failures:

• A modal or dropdown that cannot be closed with Escape

• Focus that moves into an overlay and never comes back

• A custom control that responds only to mouse events

• Visible focus indicators removed by outline: none without a replacement

A visible focus ring is a small cost and a large benefit. It also helps sighted keyboard users, who are more numerous than most people assume.

4. Images without meaningful alternatives

Decorative images should have empty alt attributes. Meaningful images need real descriptions. The failure is usually in the other direction — every image tagged with the filename, which is worse than nothing because a screen reader announces "IMG-4821".

5. Heading structure that does not match the visual structure

Screen reader users navigate by heading. When the visual hierarchy and the heading hierarchy disagree — because a heading was skipped for styling reasons, or because an <h4> was used to get smaller text — navigation breaks for everyone who relies on it.

Use headings for structure and CSS for size. One <h1> per page.

6. Video without captions

WCAG 2.2 includes captions as a requirement, not a enhancement. The bar is accurate captions, not an auto-generated track nobody checked. Auto-generated captions are a starting point for a transcript, not a substitute.

This is a marketing-site-specific issue because marketing sites are where video lives — on the homepage, in case study pages, in the middle of the sales journey.

7. Third-party embeds

Chat widgets, maps, video players, cookie banners and tag managers each add their own accessibility surface. A map embed without keyboard support and without a text alternative is a hard failure you did not write.

Mitigation: configure the embed properly, provide a text alternative or a link to the same information elsewhere, and load these late so they do not affect the rest of the page.

8. Motion without a reduced-motion option

WCAG 2.2 requires that motion triggered by interaction can be disabled, and prefers-reduced-motion is the standard mechanism. It is a small CSS block and it is also just good manners for anyone who gets motion sickness from parallax.

What "conforming" actually means

WCAG has three levels, and marketing sites routinely claim the wrong one.

• Level A — the bare minimum. Largely about having text alternatives and logical structure.

• Level AA — the standard. Contrast, focus visibility, labels, captions, target sizes. This is the level most law and procurement requires.

• Level AAA — enhanced contrast and sign language, among others. Very hard to achieve for a marketing site and rarely required.

Claiming conformance means:

1. Every applicable criterion is met.

1. The claim is documented — usually a short accessibility statement listing what is covered, what is not, and why.

1. There is a contact point for reporting a barrier.

1. The site is actually maintained against that claim.

An accessibility statement that claims full AA conformance on a site that fails contrast in the footer is worse than no statement, because it creates legal exposure rather than reducing it.

Building it in rather than retrofitting it

Retrofitting accessibility is possible and it is expensive, because you are touching every component and every template.

Start in the design system

This is where accessibility actually becomes cheap. If the design system specifies:

• Focus styles as a required component state

• A minimum target size of 44×44

• A defined and tested contrast pair for every colour role, including muted text

• A text scale with no step below 16px for body content

then every team building on it inherits those properties without thinking about them. If it does not, every team has to remember, and nobody remembers.

Make the content guidelines explicit

Alt text, heading order, link text, and plain language are content decisions, and they have to be written down and given to whoever writes the content — which, on a marketing site, is usually not the design team.

Link text is a specific one. "Read more" as link text is a genuine failure, not just a style complaint. Screen reader users routinely pull up a list of links, and a list of fourteen "Read more" entries tells them nothing.

Test with a keyboard, once a month

Take the keyboard and use the site. Tab through it. Open the menu. Open the modal. Complete the form. Nothing else in the process catches keyboard problems as reliably.

Run an automated check on every build

Automated tools catch roughly a third of accessibility issues — missing labels, low contrast, missing alt, bad heading order. That third is the cheap third, and it is the third that regresses silently.

Get real users involved

Automated checks and manual keyboard testing find different things. People with disabilities using assistive technology find things neither will. If your organisation has any, involve them early — not for a final audit, but while the design is still changeable.

The commercial argument, since that is often the one that moves things

Accessible design is not a cost centre dressed up as a virtue. It tends to pay for itself.

• Better SEO. Semantic HTML, descriptive link text, proper headings and fast performance all help, and they are the same things accessibility requires.

• Better performance. Accessibility work usually coincides with performance work: real image dimensions, sensible markup, less decorative JavaScript.

• Broader reach. Older users, users on slow connections and users on cheap devices are a large and growing share of the audience.

• Lower legal risk. In the EU, the Accessibility Act can carry fines of up to 7% of turnover. That is not a rounding error.

• Lower maintenance cost. A system with accessibility built in needs fewer one-off patches.

A practical order

If you are starting from a non-compliant site:

1. Write the accessibility statement. It forces the decision to be explicit, and it defines the scope.

1. Audit and triage. Automated scan, manual keyboard pass, and a real screen reader on the main journeys. Fix what blocks the core task first.

1. Fix the template, not the pages. Contrast tokens, focus styles, target sizes, form components, heading structure. Every page inherits the fix.

1. Fix the third-party embeds. Configure, constrain or replace them.

1. Add captions and transcripts for video.

1. Wire an automated check into the build so it does not regress.

1. Review quarterly, with real users when you can get them.

Do not try to fix everything at once. Fix what blocks people, then work down the list.

---

Accessibility is one of the few areas where doing it properly is cheaper than doing it twice. If your site needs an audit or a rebuild, our UI/UX and product design practice builds accessibility into the design system from the first component — and our web development practice enforces it in the build.