Accessibility on this site

Somebody buying an engine is often doing it under pressure, on a phone, with a car already off the road. Making that harder than it needs to be is a design failure before it is a compliance one. This page lists what was built for that reason.

Structure and navigation

• Semantic HTML throughout, with header, nav, main and footer landmarks.
• Exactly one h1 per page, and heading levels that descend without skipping. This is checked by an automated crawl of every route on every build, so a page cannot ship with two.
• A skip-to-content link as the first focusable element on every page.
• Breadcrumbs on every page below the homepage, marked up as an ordered list.
• Every route reachable from at least one other page. The build fails on an orphan, so nothing is reachable only by typing its URL.

Keyboard and focus

• A single visible focus style, a three-pixel outline with an offset, applied through :focus-visible so it appears for keyboard users without following a mouse click.
• The focus ring switches to white inside dark sections, so it never disappears into the background it is drawn on.
• The mobile navigation drawer traps focus while open, closes on Escape, and returns focus to the button that opened it.
• The FAQ accordions are native <details> elements. There is no JavaScript state and no ARIA to fall out of sync, and they work before hydration.

The Engine Finder

The form carries most of the accessibility weight on this site, because it is where the site actually does something.

• Every field has a real <label> tied to its control.
• Hints and error messages are linked to their fields with aria-describedby, so a screen reader announces both with the field rather than leaving them as loose text.
• Errors are described in words (what to do, not just that something is wrong),
  are announced through a focused summary listing every problem at once.
• Moving between steps sends focus to the new step and announces it through a live region.
• Radio options are full-width tappable cards with a minimum target height, which helps anyone with limited dexterity as much as it helps thumbs.
• Every field is 16 pixels or larger. Below that, iOS Safari zooms the viewport on focus and does not zoom back out, which leaves people panning sideways through a form.
• Inputs declare the right inputmode and autocomplete, so numeric fields open a numeric keypad and contact fields can be autofilled.

Colour and contrast

• Every text colour token in the stylesheet records its contrast ratio against the surface it is used on, in a comment beside the value. A future change that darkens a background has to reckon with the number rather than break AA quietly.
• Body text, muted text and link colours all meet AA for normal text.
• Colour is never the only signal. Errors carry text and an icon, active navigation carries aria-current, and availability states are words rather than coloured dots.

Motion and the hero video

• The homepage hero video is decorative. Everything it conveys: the headline, the description, the calls to action. Exists as real text over it, and nothing is communicated only by the video.
• It is marked aria-hidden and carries no audio track at all, so it cannot interrupt a screen reader or play sound unexpectedly.
• With prefers-reduced-motion: reduce set, the video does not play. The poster image is shown instead, and the hero is otherwise identical.
• Elsewhere, reduced motion collapses all transitions and disables smooth scrolling. Nothing on this site animates on scroll, parallaxes or auto-advances.

Images and media

• Decorative marks, the logo glyph, icons inside buttons, are hidden from assistive technology rather than announced as meaningless graphics.
• Data tables use real table markup with scoped headers and a caption, so they can be navigated cell by cell rather than read as a wall of text.
• Wide tables scroll inside their own container; the page never scrolls sideways.

Known limits

Stated plainly, because a page that claims everything is perfect is not describing software.

• No formal third-party audit has been carried out. This describes what was built and tested during development, not a certification.
• The generation and application tables are wide by nature. They scroll horizontally within their container on a narrow screen, which is workable but is more effort than reading them on a desktop.
• The Engine Finder’s multi-step flow is easier to complete in one pass than to review as a whole. An unfinished draft is preserved if you leave and come back, but there is no single summary screen listing every answer before submission.
• The administration area was built for one operator and has had less accessibility attention than the public site.

Telling us about a problem

If something here blocks you, we want to know: particularly if it stopped you getting an engine quote, which is the site failing at its only job. Contact details are here, and describing what you were using and what happened is more useful than a standards reference.