Accessibility

BakeHQ aims to meet WCAG 2.2 Level AA. Accessibility was treated as a foundation requirement rather than a later pass, because the decisions that make a reference site usable — semantic structure, real labels, visible focus — are cheap at the start and expensive to retrofit.

• A skip link to the main content, and a single main landmark on every page.
• Semantic headings in order, with one h1 per page and no level skipped for visual effect.
• Navigation landmarks with accessible names, and aria-current="page" on the active section — so a screen-reader user tabbing the nav knows where they are.
• Active navigation state signalled by weight and underline as well as colour, so it survives a monochrome display and the common forms of colour vision deficiency.
• Visible focus indication on every interactive element, never removed.
• Every form control has a real label, including ones whose visible label is a column heading; those labels are visually hidden rather than omitted.
• Radio groups are wrapped in fieldset with a legend, which is what makes the troubleshooting questions comprehensible to a screen reader.
• Status and error messages are announced through role="status" and role="alert", so a copied link or a validation error is not visual-only.
• Buttons for actions and links for navigation, never the reverse.
• Wide tables scroll inside their own container, so the page body never scrolls horizontally on a phone.
• Reduced-motion preferences respected site-wide.
• Colour contrast for every text and background pair verified against WCAG AA by an automated test, so a future palette change cannot quietly drop below it.

Automated accessibility testing runs against representative pages as part of the standard test suite, covering the homepage shell, an entity page, the troubleshooting interface and a calculator. Contrast ratios are asserted numerically rather than checked by eye.

This is stated because an accessibility statement that lists only achievements is not a statement, it is marketing.

• No testing with actual assistive technology — screen readers, magnification, voice control — has been carried out. Automated checks catch a meaningful fraction of problems and miss the ones that matter most to real users.
• No testing with disabled users has been carried out.
• The troubleshooting interface’s live-region behaviour has not been verified against a real screen reader, and narrowing results announce a fair amount of text.
• No formal WCAG conformance audit has been undertaken.

If something here is difficult or impossible to use, please write to hello@hekno.co.uk. Tell us the page, what you were trying to do, and what happened. Accessibility problems are treated as defects rather than as enhancement requests.