
Accessibility
18.05.2026
BFSG 2025: Why Carousels So Often Fall Short on Accessibility
Lucas Falkowsky
Fullstack Development
Since June 28, 2025, the Accessibility Enhancement Act (BFSG) has required all providers of online services or products to ensure their websites are accessible. The web carousel is one of the most common UI components—and at the same time, one of the most difficult to make accessible—a WCAG challenge that hardly anyone is aware of.
Like the GDPR in 2018, the BFSG 2025 has the potential to fundamentally reshape the German online market — because accessible websites have been a legal requirement in Germany since June 28, 2025. Almost everyone offering services online is affected. Most businesses only find out when the first cease-and-desist letters arrive — and then the question is no longer whether to invest, but how much.
This series is a practical guide through the most common mistakes when building accessible websites, what WCAG and BFSG actually require, and where implementations keep falling short in the real world. The common thread is the carousel.
A web carousel is a UI component that displays multiple content units — images, product cards, teasers — in a single container and cycles between them through navigation or automatic rotation.
It's a component found on almost every commercial website, and one that manages to concentrate more typical accessibility mistakes in one place than almost any other.
We at typedigital have been building digital products for years — web applications and mobile apps for startups, mid-sized companies, and established enterprises. Accessibility comes up in almost every project: as a late-stage requirement, as a missed audit finding, as the reason for a delayed launch. This series grew out of exactly those experiences — and out of the conviction that most of these mistakes are avoidable, if you know where they happen.
The BFSG: What Changed
With the Barrierefreiheitsstärkungsgesetz (BFSG), Germany transposed the European Accessibility Act into national law. Any business that provides electronic services through a website — online shops, booking forms, contact options — is now legally required to make those services accessible.
The technical benchmark is the European standard EN 301 549, which references WCAG 2.1 Level AA for websites. Violations can result in fines of up to €100,000, cease-and-desist actions from competitors and consumer associations, and in the most serious cases, a regulatory order to take the service offline. In the worst case: the online shop goes dark.
The only exemptions are micro-enterprises with fewer than ten employees and an annual turnover below two million euros — but only if they provide services. Manufacturers of products are subject to the law even at that scale.
Who Struggles With Poor Carousels?
The affected group is larger than most people assume.
Keyboard users simply cannot operate a component that has no focusable navigation elements. This doesn't only affect people with permanent motor impairments — it affects anyone who doesn't have a mouse within reach.
Screen reader users experience automatically rotating carousels as acoustic chaos — or complete silence, when no state changes are communicated at all.
People with vestibular disorders or epilepsy can experience dizziness, nausea, or worse from animated content. CSS has had prefers-reduced-motion for years — but very few carousels respect it.
Older users often combine several of these factors: reduced visual acuity, slower reaction times, decreased fine motor control. An 8-pixel dot navigation isn't a minor inconvenience for them.
According to Germany's Federal Statistical Office, around 7.8 million people in Germany live with a recognized severe disability. Add to that the millions with temporary impairments and a rapidly aging population. The total number of people affected by poor accessibility far exceeds those who depend on assistive technology permanently.
What WCAG 2.2 Actually Requires
Three criteria are particularly relevant for carousels.
Keyboard operability (WCAG 2.1.1, Level A): All functionality must be reachable via keyboard — navigating between slides, controlling rotation, interacting with slide content.
Control over moving content (WCAG 2.2.2, Level A): Automatically rotating content that runs for more than five seconds must have a mechanism to pause or stop it. A carousel without a pause button fails this criterion — full stop.
Sufficient touch targets (WCAG 2.5.8, Level AA): A minimum of 24 × 24 pixels, with 44 × 44 pixels recommended. The dots in a typical dot navigation are almost always well below that threshold.
Why Carousels Are Structurally Hard to Get Right
A button has a role, a state, and a label — and that's it. A carousel is a composite system: a container with landmark semantics, individual slides with position information, navigation buttons with dynamic labels, a live region for state announcements, and focus management that has to work consistently across the entire component.
Each of these layers has its own ARIA requirements. And they interact with each other: what gets announced depends on whether the carousel is auto-rotating. Which slides are focusable depends on which ones are currently visible. These are real edge cases that keep failing in production implementations.
That's why retrofitting accessibility onto a carousel is especially costly. A component built accessible from the start looks like any other — and works for everyone. One that needs to be patched after the fact usually has to be rebuilt from the ground up. In practice: teams that don't plan for accessibility upfront pay for it twice — in development time, in project budget, and in the worst case, as a regulatory fine.
What's Coming Next
This series works through the topic layer by layer.
Part 2 — How does a screen reader perceive a carousel? ARIA roles, slide structure, and concrete screen reader output from NVDA, JAWS, and VoiceOver.
Part 3 — Keyboard navigation and focus management: which keys, which order, and what the inert attribute has to do with it.
Part 4 — aria-live, autoplay, and the announcement problem: when should a screen reader speak, and when shouldn't it.
Part 5 — Touch targets, swipe gestures, and prefers-reduced-motion: carousels for all input devices.
Part 6 — faceless-carousel: an open-source web component that implements everything from this series accessible by design — without imposing any design decisions on the developer.
→ Read Part 2: Semantics First — ARIA Roles & Slide Structure
Sources: W3C APG — Carousel Pattern · WCAG 2.2 · Nielsen Norman Group — Auto-Forwarding · Federal Statistical Office Germany — Severely Disabled Persons
Contact
Got questions about your website's accessibility?
Lucas Falkowsky
Fullstack Development
