Accessible Withdrawal and Cancellation Buttons for Shops

§ 356a BGB applies to distance contracts concluded via an online interface, which covers the typical purchase in an online shop. The trader has to ensure that consumers can submit a declaration of withdrawal via a withdrawal function. The function must be clearly legible and labelled „Vertrag widerrufen“ or another equivalent unambiguous wording (§ 356a(1) BGB). The provision transposes Directive (EU) 2023/2673, whose provisions member states apply from 19 June 2026 and under which the function remains available throughout the entire withdrawal period (Directive (EU) 2023/2673). The withdrawal period is 14 days (§ 355(2) BGB).

Behind the entry point follows an input page with three items: the consumer's name, details identifying the contract or the affected part of it, and the electronic means of communication through which the acknowledgement of receipt should arrive (§ 356a(2) BGB). Submission happens through a confirmation function labelled „Widerruf bestätigen“ (confirm withdrawal) or an equivalent unambiguous wording (§ 356a(3) BGB). The trader then has to send, without undue delay, an acknowledgement of receipt on a durable medium that contains at least the content of the declaration and the date and time of receipt (§ 356a(4) BGB).

For subscriptions and other continuing obligations that can be concluded on a website, § 312k BGB applies alongside. The cancellation button carries „Verträge hier kündigen“ (cancel contracts here) or a corresponding unambiguous wording and leads directly to a confirmation page. That page asks for the type of termination, identification, the contract, the desired end date and the channel for the cancellation confirmation; submission happens through a button labelled „jetzt kündigen“ (cancel now) (§ 312k(2) BGB). Buttons and confirmation page must be permanently available as well as directly and easily accessible. Websites relating to financial services and contracts for financial services are expressly excluded by § 312k(1) BGB.

“Permanently available” and “prominently placed” are quick to tick off visually: a button in the customer account, a link in the footer. For screen reader users the question starts earlier. They take in a page through headings, landmarks and link lists. A withdrawal function that sits in the footer as an icon without text does not appear in any of these lists with an understandable name. For keyboard users, all functionality must be operable through the keyboard interface (W3C, WCAG 2.2, SC 2.1.1), and the focus has to stay visible along the way (W3C, WCAG 2.2, SC 2.4.7). What matters for tab order and the focus outline is covered in our article on keyboard navigation in web development.

People who work with strong magnification only see a section of the page. Text must be resizable up to 200 per cent without assistive technology (W3C, WCAG 2.2, SC 1.4.4), and content must work at a width of 320 CSS pixels without horizontal scrolling, which corresponds to 400 per cent zoom at a starting width of 1280 CSS pixels (W3C, WCAG 2.2, SC 1.4.10). If the withdrawal function disappears into a collapsed menu that only opens on mouse hover, it is neither prominent nor easily accessible for this group. A consent banner covering the footer has a similar effect: when the button receives focus, it must not be entirely hidden (W3C, WCAG 2.2, SC 2.4.11). How such a banner should be built is described in the article on accessible cookie banners.

The name matters most at this point. For controls with a visible label, the accessible name must contain the visible text (W3C, WCAG 2.2, SC 2.5.3). If the button reads „Vertrag widerrufen“ but the code says aria-label="Retoure starten", a screen reader user hears something different from what her sighted colleague reads, and the voice command “click Vertrag widerrufen” goes nowhere. About 9 per cent of buttons on desktop pages and 11 per cent on mobile pages have no accessible name at all (Web Almanac, 2025); empty buttons appear on 30.6 per cent of home pages (WebAIM Million, 2026). An icon button with an arrow or a parcel symbol quickly joins these statistics.

The confirmation function is the moment in which the withdrawal is submitted. If an input error occurs here, the affected field has to be identified and the error described in text (W3C, WCAG 2.2, SC 3.3.1). A red outline alone reaches neither people with colour vision deficiency nor screen reader users. A proven pattern is an error summary at the top of the form that receives focus and links to the individual fields, plus a message directly at the field, attached via aria-describedby. Just as important is what must not happen: data already entered is not lost on error, and the page does not reload with an empty form.

After a successful submission, the person needs clear feedback. Status messages must be marked up so that assistive technologies can present them without them receiving focus (W3C, WCAG 2.2, SC 4.1.3). In practice there are two clean ways: either a new page loads whose title and main heading read „Widerruf eingegangen“ (withdrawal received) and whose heading receives focus, or the message appears on the same page in a region with role="status". Only about 33 per cent of websites use the aria-live attribute at all (Web Almanac, 2025). A confirmation page without focus and without an announcement is a typical pattern that makes an otherwise tidy flow fail at the last step: the person hears nothing, presses again and afterwards does not know whether they have withdrawn twice.

The acknowledgement of receipt must contain the content of the declaration and the date and time of receipt (§ 356a(4) BGB). The status message on the page should name the same details, so that nobody has to wait for the email to know what has arrived. How live regions are set up robustly without producing duplicate announcements is described in the article on accessible error and status messages. In single-page applications where the confirmation appears without a page change, focus management in single-page apps comes on top. The following skeleton shows the input page with entry point, labels, error summary and status region.

For subscriptions, the checklist applies accordingly, only with different labels. The cancellation button carries „Verträge hier kündigen“ or a corresponding unambiguous wording, the confirmation button „jetzt kündigen“ (§ 312k(2) BGB). Both texts also belong in the accessible name. A button “Manage membership” that first leads to a menu with retention offers meets neither the labelling rule nor the requirement to lead directly to the confirmation page. The confirmation page asks for more than the withdrawal, including the type of termination, the end date and the channel for the cancellation confirmation (§ 312k(2) BGB). This quickly turns into radio buttons and a date field, and both need clean markup: radio buttons grouped in a fieldset with a legend, the date field with a visible format hint.

The option “at the earliest possible date” should be offered as a clearly labelled first choice, because without a date the termination takes effect at the earliest possible point in case of doubt anyway (§ 312k(5) BGB). This spares people who can only operate a date field with difficulty one of the hardest steps. Anyone who still offers a calendar picker has to make it fully keyboard-operable and announce the selected value; how that works is shown in the article on accessible appointment booking with a calendar widget.

Automated rules alone find missing labels and empty buttons, but not whether a status message is marked up as one or whether the withdrawal can still be found at 400 per cent magnification. We therefore test the flow step by step in the browser: with automated rules and our own measurements of contrast, target size, focus, text spacing and reflow at 320 CSS pixels, in the desktop and smartphone layouts and also in opened states such as the error summary and the confirmation. Every step is run with the keyboard without a mouse, and in the screen reader output we check whether names, roles, states and status messages are marked up so that screen readers can announce them. What the review of the screen reader output covers is described on a separate page. The results go into the WCAG audit as a separate test section with an assessment of every criterion and findings per step.

Two figures show how far practice is from this standard. In the Aktion Mensch test, only 20 of 65 examined shopping sites were operable by keyboard alone (Aktion Mensch, 2025). And 67 per cent of websites explicitly remove the default focus outline (Web Almanac, 2025). A withdrawal flow built in the same design system inherits these weaknesses unless someone measures it on purpose.

The effort stays manageable because the flow is short: one entry point, one form with three fields, one confirmation, one email. Building it cleanly once implements the BGB requirements in a way that also works for people with disabilities and closes a gap between checkout and customer account that otherwise easily goes unobserved. The adjacent parts of the shop are covered in the articles on older customers in online shopping and on the accessible product detail page with variants and basket.