Shopware BFSG Accessibility Backlog Guide

For German ecommerce teams, BFSG pressure often turns into a long list of vague accessibility findings. A better Shopware accessibility backlog groups issues by customer journey, risk, reusable component, and retestable ticket evidence.

This page is implementation guidance, not legal advice or a certification statement.

Start with Shopware customer journeys

Organize findings around the flows that decide whether customers can buy or get support:

Homepage and category navigation.
Product listing filters and sorting.
Product detail page, variant selection, and add to cart.
Cart, checkout, payment, and order confirmation.
Account login, registration, password reset, and address forms.
Search, contact, returns, and customer-service content.

Convert audit notes into Shopware ticket clusters

Before opening dozens of isolated tickets, group findings into clusters a product owner and developer can actually plan:

Checkout blockers: validation errors, payment selection, focus order, cart updates, and order confirmation messages.
Reusable storefront components: buttons, accordions, off-canvas menus, filter controls, variant selectors, alerts, modals, and carousels.
Plugin-owned behavior: payment, cookie consent, review widgets, search, recommendations, chat, and tracking consent overlays.
Content and CMS pages: landing pages, legal/support pages, embedded videos, image alternatives, PDFs, and contrast problems in promotional modules.
Theme regressions: custom template overrides that remove labels, focus indicators, names, roles, states, or status messages.

That structure keeps the backlog close to Shopware implementation ownership. It also avoids the common trap where every scanner row becomes a separate low-context ticket.

Backlog columns that keep tickets useful

Flow: where the issue affects a shopper.
Component: Shopware theme, plugin, custom storefront component, checkout extension, or content page.
User impact: blocked purchase, confusing form, hidden information, extra effort, or minor polish.
Evidence: screen reader note, keyboard path, axe rule, selector, screenshot note, or tester quote.
Likely WCAG references: criteria to verify, not decorative labels.
Acceptance criteria: what must be true before the ticket can close.

Shopware BFSG ticket title patterns

Use titles that name the flow, component, and user-facing problem. These are easier to triage than generic titles like “WCAG issue” or “BFSG accessibility problem”.

[Critical] Checkout: payment error is visible but not announced
[High] Product listing: selected filter state is not exposed to screen readers
[High] Mobile navigation: keyboard focus moves behind the off-canvas menu
[High] Account registration: required-field errors are not associated with inputs
[Medium] Product detail: color variant swatches have no accessible names
[Medium] Cookie consent plugin: dialog lacks an accessible name and focus containment
[Medium] Cart: quantity update changes totals without a status message
[Low] Campaign teaser: decorative image alt text repeats nearby heading

Example Shopware backlog items

[Critical] Checkout: payment errors are visible but not announced
Flow: checkout payment
Component: payment plugin / checkout template
Impact: screen reader users may not know why payment failed
Evidence: error appears visually after submit; no focus move, no aria-live/status announcement
Acceptance criteria: invalid payment state is announced and field-level errors are associated with inputs

[High] Product listing: filter checkboxes do not expose selected state
Flow: category product listing
Component: storefront filter sidebar
Impact: screen reader users cannot reliably refine product results
Evidence: selected visual chips update, but checkbox state/name is unclear in NVDA
Acceptance criteria: selected state, filter name, and updated result count are programmatically available

[High] Mobile navigation: keyboard focus can move behind the menu
Flow: mobile category navigation
Component: off-canvas menu / theme navigation
Impact: keyboard and screen reader users may lose context or activate hidden page content
Evidence: after opening the menu, Tab reaches links behind the overlay before the menu is closed
Acceptance criteria: focus remains inside the open menu, Escape closes it, and focus returns to the opener

[High] Account registration: inline errors are not connected to fields
Flow: registration and account address forms
Component: Shopware form templates / custom validation
Impact: screen reader users may not know which field needs correction
Evidence: error text appears under invalid inputs but is not referenced by aria-describedby
Acceptance criteria: each invalid input exposes required state, invalid state, and the related error message

[Medium] Product detail: color swatches rely on visual color only
Flow: variant selection
Component: theme variant selector
Impact: shoppers who cannot distinguish colors may choose the wrong variant
Evidence: swatches have no text alternative or selected-state announcement
Acceptance criteria: each option exposes a text name and selected/unavailable state

What to include from axe, WAVE, or manual tests

Automated findings are useful evidence, but they rarely explain Shopware business impact on their own. Add the missing context before the ticket reaches a sprint:

Raw finding: tool name, rule, selector, affected node, screenshot note, or tester quote.
Shopware ownership: core storefront template, custom theme, plugin, CMS block, checkout extension, or third-party embed.
Customer task: choosing a product, filtering results, creating an account, paying, correcting an error, or requesting support.
Assistive technology retest: keyboard-only, NVDA/Firefox, VoiceOver/Safari, TalkBack/Chrome, or another relevant setup.
Closure condition: a short acceptance criterion QA can verify without reading the original audit report.

Prioritization rule of thumb

Fix checkout, payment, registration, and login blockers first.
Then fix reusable theme/plugin components used across many pages.
Then handle content, PDF, and lower-frequency polish items.

Do not count findings only by volume. One checkout blocker can matter more than twenty low-impact color contrast notes on rarely used pages.

Mini workflow for the first backlog pass

Export scanner findings and manual notes, but keep them as evidence rather than final tickets.
Mark every issue with its customer journey and likely Shopware owner.
Merge duplicates that share the same component, such as repeated missing accessible names in one filter widget.
Split findings when one scanner rule hides different user impacts, such as contrast on checkout errors versus contrast on a decorative footer link.
Write acceptance criteria before implementation begins, especially for checkout, account, navigation, and plugin dialogs.
Retest the fixed component in at least one real flow, not only on an isolated pattern page.