Website policy

Accessibility Statement

Applies to the Buttercup’s Baking Society website only.
Last updated: 1 August 2026  ·  Effective date: 1 August 2026

What has been built in

The following were implemented deliberately and verified in a browser on the site as it stands:

Feature	How it works here
Skip link	A "Skip to content" link is the first focusable item on every page and becomes visible when focused.
Semantic structure	Real landmarks (header, nav, main, footer), one h1 per page, and a heading order that descends without skipping levels.
Keyboard operation	Every interactive element (links, the menu button, the FAQ, all form fields and the submit button) is reachable and operable by keyboard alone.
Visible focus	A 3px focus ring with offset is applied via :focus-visible and is never removed.
Mobile menu	The toggle exposes aria-expanded and aria-controls. Escape closes the menu and returns focus to the button, and choosing a link closes it. While closed, the menu is both display:none and inert, so its links cannot be reached by Tab.
FAQ	Built from native <details>/<summary> elements, so it is announced and operated correctly without any custom scripting.
Colour contrast	Every text and UI colour pair was measured against its actual rendered background. The lowest result on the site is 4.86:1 (muted body text on cream); primary buttons are 5.45:1 white on lilac, and main body text is 10:1. All meet or exceed the 4.5:1 AA threshold for normal text.
Colour is not the only cue	Required fields are marked with a word as well as a colour, and form errors appear as text, not just a red border.
Images	Informative images carry descriptive alt text; purely decorative images use alt="" and icons are marked aria-hidden. All images declare width and height so the page does not shift as they load.
Forms	Every field has a real <label>. Hints and error messages are linked with aria-describedby, invalid fields set aria-invalid, and the status message is in an aria-live region so it is announced.
Allergen notice	The first time you engage with the order form, a notice appears about the shared home kitchen and has to be acknowledged. It is a labelled role="alertdialog" with aria-modal, focus moves into it, Tab is kept inside it, and Escape or "Not now" backs out and returns focus to where you were. Backing out does not count as acknowledging, so the notice returns. Nothing is stored, so a reload asks again. The same warning is in the FAQ for anyone browsing without JavaScript.
Chat helper	The “Sprig” helper is a real <button> and <form>, operable by keyboard. The panel is a labelled role="dialog", Escape closes it and returns focus to the launcher, and replies are announced through an aria-live log. While a reply is being generated an animated indicator appears, which is stilled under reduced-motion settings. If the AI service is slow or unavailable, Sprig falls back to a fixed set of answers rather than failing silently. It is a purely optional extra: everything it says also appears in the FAQ and Order sections.
Reduced motion	The scroll-reveal effect and smooth scrolling are switched off entirely when the operating system requests reduced motion.
Without JavaScript	All content, all navigation links, the FAQ and the phone number remain fully available. Navigation only collapses into a menu button once JavaScript has loaded successfully.
Zoom and reflow	The layout is fluid and was checked at 375px and 1280px with no horizontal scrolling at either width.
Sticky header	Section anchors use scroll-margin-top so a heading is never hidden behind the fixed header when jumped to.

Known limitations

Stated plainly, because a statement that lists only strengths isn’t much use:

• No independent audit. Checks were carried out by the site’s builder using browser tooling and scripted measurement, not by an accessibility specialist.
• No assistive-technology user testing. The site has not been tested by people using screen readers, voice control or switch access. Automated and manual checks do not substitute for this.
• The date field in the order form relies on the browser’s own date control, whose accessibility varies between browsers and platforms. Every field it collects can also simply be typed into the message box instead.
• Photography is stock. Alt text describes what each photograph shows, but the images do not depict the bakery’s actual products, so the descriptions are generic rather than specific.
• Web fonts load from a third party. If Google Fonts is unavailable, the site falls back to system fonts. Layout and readability hold up, but the appearance changes.
• The order form sends directly. On submit it posts to the site and the bakery receives an email. The button shows a sending state and the outcome is announced through a live region. If sending fails, it falls back to opening your own email app, and the bakery’s address is also shown as plain text beside the form and in the footer so it can always be copied by hand.

Compatibility

The site is built with standard HTML, CSS and a small amount of JavaScript, and is intended to work in current versions of Chrome, Edge, Firefox and Safari on desktop and mobile. It does not require JavaScript to read or navigate.

Tell us if something doesn’t work

If any part of this site is difficult to use, please say so. It will be treated as a fault worth fixing, and the bakery will help you place your order another way in the meantime.

• Email: Kim@buttercupsbakingsociety.com
• Response time: TODO:REPLACE: how quickly the bakery aims to respond to accessibility reports

Formal approach

• Standard targeted: WCAG 2.2, Level AA
• Conformance status: Partially conformant by self-assessment. The target has been designed for and checked for, but not independently verified
• Assessment method: Self-evaluation by the site’s builder, using scripted contrast measurement against rendered colours, keyboard traversal, a JavaScript-disabled pass, and layout checks at 375px and 1280px
• Assessment date: 1 August 2026