Accessibility statement

Our commitment and the target

We are working towards WCAG 2.2 Level AA across webasto.co. That is the target, not a claim of arrival — see the known limitations below.

The stakes are higher here than on a brochure site. People read these pages while something is going wrong: a lookalike domain serving a credential form, a registrar accepting a transfer nobody authorised, mail failing DMARC alignment. Under that pressure, an interface that only works with a mouse, a focus ring you cannot see, or a heading structure that gives a page no shape stops being an inconvenience and starts costing minutes. Our emergency response details in particular have to be reachable by keyboard, readable at 200% zoom and announced sensibly by a screen reader.

What is built in

These are the practices the site is written to, not features bolted on afterwards.

• Semantic HTML — headings in order, lists that are lists, landmarks for header, navigation, main and footer, and a skip link as the first focusable element on every page.
• Keyboard operability — page content, links and buttons are reachable with Tab and Enter, in an order that follows the visual layout. The one exception is the desktop navigation, described under known limitations.
• Visible focus states — focus is never removed without a replacement indicator that stays visible against the surface behind it.
• Colour contrast checked against AA — 4.5:1 for body text, 3:1 for large text and for the boundaries of interface components.
• Text alternatives — meaningful images carry alt text saying what the image is there to convey; decorative graphics are hidden from assistive technology rather than described.
• Restrained motion — there is no autoplay, no parallax and nothing that moves on its own. Movement is limited to short hover and focus transitions that carry no information, so no content flashes or animates while you read it.

A note on the dark colour scheme

This site uses a dark palette. Dark backgrounds are often assumed to be easier on the eyes and therefore safe by default; they are not. They fail in their own ways — muted grey on a near-black surface drifts under 4.5:1 easily, thin card borders fall below the 3:1 needed for component boundaries, and saturated accents that look bright can measure worse than they appear. We check ratios on dark surfaces with the same tooling and thresholds we would apply to a light theme.

Known limitations

We would rather list these than write a paragraph of reassurance. None of them is resolved today.

• Desktop dropdown menus open on hover only. On viewports wide enough for the horizontal navigation, the submenus under Services, Solutions and Threat Intelligence are revealed by pointer hover. They are not opened by keyboard focus, so a keyboard or switch user tabbing along the navigation cannot reach the child links from the menu bar. Every one of those destinations is still reachable: the top-level Services, Solutions and Threat Intelligence links are in the tab order and each of those index pages lists its children, and the footer repeats most of them. This is the barrier we consider most serious and it is a genuine failure, not a nuance.
• Reduced-motion preference is not yet honoured. The stylesheet has no prefers-reduced-motion rule, so the short hover and focus transitions described above still run even when your system asks applications to reduce motion. The movement is small and carries no information, but respecting the preference is the correct behaviour and we have not implemented it.
• Off-screen carousel items stay in the tab order. The recent-posts carousel on the home page hides items by sliding them outside a clipped viewport rather than removing them from the accessibility tree. Tabbing through it can therefore move focus to a link you cannot see. The previous and next buttons are labelled and keyboard operable, and the same posts are listed in full on the blog index, which is the reliable way through them.

We do not claim full conformance with WCAG 2.2 Level AA and will not until these are closed and re-tested. If you find something not listed here, it is not that we judged it acceptable — we did not know.

How we test

Testing here is manual and page by page rather than a gate in a build pipeline, and we would rather say that plainly than imply continuous coverage we do not have. A pass means working the page with the keyboard alone, walking the full path from landing to finding the address or document you came for, then listening to how headings, links and controls are announced rather than looking at how they render.

Where automated checking is used it catches mechanical failures — missing alt attributes, unlabelled controls, contrast below threshold, broken heading order, duplicate landmarks. That class of tooling is useful and not sufficient. It finds only a fraction of the barriers a person meets, because the questions that matter most — is this alt text the right description, does the tab order make sense, is this link text meaningful out of context, does a menu open for a key as well as a pointer — are judgements a scanner cannot make. The hover-only navigation listed above is exactly that kind of miss: mechanically valid markup, unusable without a pointer. Where the two methods disagree, the manual result decides.

Reporting a barrier

Email [email protected]. We would rather hear about something small than have you work around it silently. What helps us reproduce it quickly:

• The page URL.
• What you were trying to do, and where it stopped working.
• Your assistive technology, browser and operating system, with versions, if you are comfortable sharing them.

We reply to general email within one business day. If a fix will take longer, the reply will say so and describe a workaround — a direct URL, the same information in another format, or a person who will simply do the thing for you. You will not be left waiting with nothing. Contact is by email only; our addresses are on the contact page, and the standards of plain language and correction we apply to published research are in our editorial policy.

Accessibility reports are not security reports

These are separate channels on purpose, and routing one through the other delays both. An accessibility barrier goes to [email protected] and is handled openly. A vulnerability in our systems needs the opposite: confidentiality, a remediation clock, and no public detail until a fix is in place. Send those to [email protected] under our responsible disclosure policy; that is the address published in our RFC 9116 security.txt. Use of this site is governed by our terms of service, and common questions are answered in the FAQ.