Website accessibility and cookies

Accessibility is about whether more people can use your site — including people who use screen readers, keyboards only, voice control or high zoom. Cookies and similar technologies affect privacy and how browsers treat analytics and advertising tags. This guide covers the light checks our free tools make. It is not a full WCAG audit and not legal advice about PECR or UK GDPR.

Use the accessibility signals checker and the cookie checker.

Accessibility signals we look at

Our passive check looks for HTML signals on the page you enter, such as:

• Page language — a lang attribute on the root element (for example lang="en-GB") so assistive technology can pronounce content correctly.
• Image alt text — meaningful alternative text for informative images, and empty alt="" for purely decorative ones so screen readers can skip them.

Passing those checks does not mean the site meets WCAG 2.2. It does not test colour contrast, keyboard traps, form labels, focus order, live regions, media captions or reflow at 400% zoom. Treat a pass as a starting point, not a certificate.

Practical accessibility habits for small sites

• Use headings in order (one H1, then H2s and H3s) that match the visible structure.
• Make sure link text makes sense out of context (“Download the price list”, not “Click here”).
• Keep keyboard focus visible; avoid mouse-only controls for essential tasks.
• Give every form field a visible label tied to the input; do not rely on placeholder text alone.
• Do not use colour alone to mean “error” or “required”.
• Provide transcripts or captions for important video and audio where you can.
• Check your pages at a larger text size — content should still be readable without horizontal scrolling where possible.

If you commission a formal audit, share these passive results as a warm-up, not a substitute.

Cookies, flags and trackers

Cookies are small pieces of storage browsers keep for a site. Some are strictly necessary for security, load balancing or a shopping basket. Others remember preferences. Others track behaviour across sites for analytics or advertising.

Our cookie checker looks at cookie flags on the response and obvious tracker script hosts referenced on the page. Flags worth knowing:

• Secure — only send the cookie over HTTPS.
• HttpOnly — block page JavaScript from reading the cookie (helpful for session cookies).
• SameSite — limit when the cookie is sent on cross-site requests (Lax or Strict are common starting points; None requires Secure).

The checker is not a full consent-law assessment. UK rules on cookies and similar technologies are detailed. If you run advertising pixels, remarketing or cross-site tracking, get proper advice and make sure your notice and controls match what the site actually does.

Sensible defaults for many small business sites

• Prefer cookie-free or first-party analytics when they meet your needs (this project uses cookie-free Cloudflare Web Analytics on the scanner itself).
• Load non-essential tags only after a clear choice, if you use a consent tool.
• Review third-party scripts quarterly — marketing tags have a habit of accumulating.
• Keep the privacy notice accurate; ours is at /privacy/ if you want to see the tone we use.

What we do not claim

These checks are not a WCAG certification, not a penetration test, not a malware scan, and not legal advice. They highlight basics you can improve quickly and point you at the matching tools.

Forms, media and third-party embeds

Contact forms and booking widgets are frequent accessibility weak points. Every control needs a name, errors should be announced clearly, and time limits should be generous or adjustable. When you embed a map, video or payment frame, check that you can still reach the rest of the page by keyboard and that the embed does not trap focus.

Cookie and consent banners themselves must be usable: focus should move sensibly, buttons should be proper buttons, and reject or essential-only choices should be as easy as accept when you offer a choice. A banner that covers content without a working close control creates both privacy and accessibility problems.

Practical next steps

1. Run the accessibility signals checker and fix missing language and alt text on key templates.
2. Run the cookie checker and review any third-party hosts you did not expect.
3. Align your privacy and cookie wording with reality.
4. Schedule a deeper accessibility review if you serve the public sector, run ecommerce at scale, or have had complaints.

For the wider passive pass — HTTPS, headers, email auth, links and SEO basics — use the free scan. More topics live on the guides hub.

Informational only. Not a security audit, legal advice or a guarantee.

All guides · Free scan