Accessibility

Last updated: 2 May 2026.

Our Aim

We aim to provide clear navigation, readable text, keyboard-accessible controls, descriptive links, and useful alternative text for editorial images. Our target is to meet WCAG 2.2 AA where practical across current public pages, including articles, category pages, search, events, corrections, policy pages, and key admin journeys.

Accessibility is treated as part of code quality. New templates should use semantic headings, meaningful link text, visible focus states, sufficient colour contrast, resilient responsive layouts, and form labels that work for screen readers and voice input.

What We Have Built In

The site uses semantic HTML landmarks, keyboard-accessible links and buttons, descriptive alt text fields for article and event images, skip-friendly page structure, readable font sizes, and responsive layouts that avoid overlapping controls on small screens. Search, filters, share buttons, article correction notices, and event calls to action are built with accessible names where possible.

We also aim to avoid relying only on colour to convey meaning. Where badges, alerts, or status labels are used, text labels are included. Form controls in the admin area should have labels, validation messaging, and predictable tab order.

Known Limitations

Some archived or third-party content may not yet meet the same standard as current editorial pages. We review and improve these issues over time. Known limitations may include older images without complete alternative text, embedded third-party media that we do not control, social platform widgets, event organiser pages linked from our site, and legacy editorial markup imported from earlier systems.

Some generated or externally supplied content may need manual review before it fully meets our standard. Where we discover a material issue, we prioritise fixes that affect core reading, navigation, search, corrections, event discovery, and editor workflows.

Reader Controls

You should be able to zoom the site, increase text size in your browser, navigate with a keyboard, and use common assistive technologies. The progressive web app service worker should not block access to fresh content when a network connection is available.

Ongoing Review

We review accessibility during design and code changes, including checks for heading order, focus visibility, button names, link names, colour contrast, mobile layout, and text overflow. We also treat reader feedback as a direct input to our backlog.

Feedback

If you find an accessibility issue, email accessibility@booze.co.uk with the page URL, the device and browser you used, the assistive technology involved if relevant, and a description of the problem. We aim to acknowledge accessibility reports promptly and prioritise fixes based on severity and reader impact.