Accessibility Statement

Alf's Cycles is committed to making this website usable by as many people as possible. We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA — the standard most government and public-sector sites in the UK are required to meet under the Public Sector Bodies Accessibility Regulations 2018.

This page is partly a statement and partly a short, plain-English guide to web accessibility. We've kept it here because we think understanding why these things matter is more useful than just a checklist.

What is web accessibility?

Web accessibility means designing and building websites so they work for everyone — including people who use a screen reader, navigate only with a keyboard, have low vision, are colour-blind, use voice control, or just have an old phone and a patchy connection. Accessibility is not a niche concern: roughly 1 in 5 people in the UK lives with a disability (Family Resources Survey, DWP), and most of us will need accessibility features at some point — temporarily (a broken arm, a noisy train, bright sunlight on a screen) or permanently.

An accessible website is also faster, easier to use on a phone, easier for search engines to index, and easier to translate. Building things this way costs little extra if it's done from the start; retrofitting afterwards is where the cost lives.

The four principles of WCAG (POUR)

WCAG is built on four ideas. The acronym is POUR:

1. Perceivable

Information must be presentable to users in ways they can perceive. Images need text alternatives (alt text), videos need captions, colour can't be the only way to convey information, and there must be enough contrast between text and background. On this site, we use a minimum contrast ratio of 4.5:1 for normal text — about double what unaided black-and-cream might offer at the wrong shade.

2. Operable

Every interactive element must be usable by a keyboard alone — not just a mouse. Users must have enough time to read and interact with content, and we shouldn't trigger seizures (so no rapid flashing). Navigation should be predictable: the same link should go to the same place from every page.

3. Understandable

Text should be readable. Pages should behave in predictable ways. When the user makes a mistake (say, in a form), the site should explain what went wrong in plain language and suggest how to fix it.

4. Robust

Content must work with current and future tools, including assistive technologies. In practice that means writing valid HTML, using semantic elements (nav, main, article, etc.) instead of generic div wrappers, and leaning on standards rather than browser quirks.

Who benefits?

People who are blind or have low vision rely on screen readers (which speak the page aloud), screen magnifiers, or high-contrast modes.
People with motor or dexterity impairments may use a keyboard only, a switch device, eye-tracking or voice control — anything that isn't a precise mouse pointer.
People who are deaf or hard of hearing need captions for audio and video.
People with cognitive or learning differences benefit from clear language, consistent layouts and the ability to control motion (no auto-playing animation).
Everyone else — from someone on a slow rural connection to a tourist using Google Translate — benefits from semantic HTML, captions and readable type.

Common assistive technologies

Screen readers

Software that reads the page aloud, in order. The two most widely used are NVDA (free, Windows), JAWS (paid, Windows), VoiceOver (built into macOS and iOS), and TalkBack (built into Android). Screen readers rely heavily on correct HTML structure — they can't infer meaning from visual styling alone.

Screen magnifiers

Tools like ZoomText or the built-in OS magnifier enlarge a portion of the screen. Sites that re-flow at 200% zoom without horizontal scrolling are much easier to use with magnifiers.

Keyboard-only navigation

Many people don't use a mouse at all. They tab through links and buttons using the Tab key, activate them with Enter or Space, and rely on a visible focus outline to know where they are. Try it on this site — pressing Tab from the top should reveal a "Skip to main content" link.

Voice control

Tools like Dragon NaturallySpeaking or built-in OS voice control let users navigate by saying "click contact" or "scroll down." Voice control depends on links having sensible visible names — "click here" links are a nightmare.

Adjust your own settings

Your browser and operating system already offer powerful accessibility tools you may not have tried:

Zoom the page: Ctrl + + (Windows/Linux) or ⌘ + + (macOS). This site re-flows up to 400% zoom without losing content.
Reader mode: most browsers (Firefox, Safari, Edge) have a one-click button that strips the page down to its text — perfect for long articles like our Our Story page.
Reduce motion: enable "Reduce motion" in your OS settings to stop the rotating headline on the home page and the slide-in mobile menu. This site listens for prefers-reduced-motion.
Force dark mode or high-contrast mode: in your OS settings. The site uses sufficient colour contrast in either direction.

What we've done on this site

Semantic HTML5 throughout — proper headings (one h1 per page, no skipped levels), landmarks (header, nav, main, footer) and lists. Zero <div>, zero classes, zero IDs (with one exception: id="main" for the skip-link target).
A "Skip to main content" link as the first focusable element — invisible until you tab to it.
ARIA labels on every navigation region, status pill and interactive control. The rotating hero headline uses a fixed aria-label so screen readers get one stable announcement.
Colour contrast verified at 5.13:1 or better for every text/background pair, meeting WCAG AA for both normal and large text.
All images have meaningful alt text; the decorative cat-paw illustration uses alt="" and aria-hidden="true".
Tap targets are at least 44 × 44 pixels for buttons, links and form fields (WCAG 2.5.5).
Fully responsive from 320 px upward, mobile-first — no horizontal scroll at any width.
Forms use proper label association, required attributes, autocomplete hints, and confirmation / error messages with role="status" and role="alert" so screen readers announce them.
The shop-open status pill in the header is announced via aria-live="polite" when its state changes between Open and Closed.
The horizontal "What we do" gallery on the home page supports mouse drag, touch swipe, and keyboard arrow-key scrolling.
Animations respect the prefers-reduced-motion media query — the rotating headline and slide-in menu hold still for users who've asked for it.
Page structure validated against W3C HTML and CSS validators.

Known limitations

We're not perfect. Things we are still working on:

The horizontal scroll gallery on the home page is operable with keyboard arrows and mouse drag, but some assistive technologies may treat it as a generic scroll region rather than a list of links. We are actively reviewing this with a more explicit list semantic.
Three of the bike-photo files on the site could be smaller. We're scheduled to recompress them to WebP at a lower quality level — until then the home page weighs a little more than it should on slow connections.
The shop-status pill currently uses the visitor's local time. A traveller in another timezone will see a status calculated against their clock, not ours. We're considering switching it to Europe/London time.

Need help?

If you encounter any accessibility barrier on this site — anything from a hard-to-read colour to a form field that confuses your screen reader — please get in touch. We aim to respond within five working days.

017687 72345 · Send us a message