In short and in plain language
This post is about online courses. If you sell courses to consumers, the BFSG often applies. This is a German accessibility law. Universities follow other rules.
Very small companies can be exempt for services. This does not apply to products.
Check the whole path, from booking to the end of the course. Problems often show up where one step leads to the next. Videos and texts in the course count too.
Drag and drop tasks need another way to solve them. Timed tests must allow more time. Train your course authors as well. We can help you with this.
Anyone selling courses online tends to think about accessibility on the website and rarely about the course room behind it. Yet that is where it is decided whether a learning offering is usable at all. The starting position speaks for itself: around 16% (best3, DZHW) of students in Germany reported a health condition that impedes their studies in the 2021 survey, compared with 11% (best3, DZHW) in 2016 and just 8% (best3, DZHW) in 2011. On top of that come 6.2 million (LEO 2018) adults with low literacy, for whom further education matters most and is hardest to reach. The technical picture is similarly sobering: 95.9% (WebAIM Million, 2026) of the home pages analysed carry detectable WCAG failures, on average 56.1 (WebAIM Million, 2026) errors per home page. Education providers can underestimate their obligations twice over. Paid online courses sold to consumers are a service in electronic commerce and therefore fall under the German Accessibility Act, while universities and public sector providers are simultaneously bound by BITV 2.0 and the state statutes. This article first settles the question of which regime applies and then moves into platform practice: booking, sign-in, course room, learning path, assessment and certificate as one continuous chain. The legal frame is summarised in our overview of the BFSG requirements.
Key takeaways
- Two regimes, one offering: paid online courses sold to consumers fall under the BFSG, universities and public providers under the BGG and BITV 2.0. In both cases the technical basis is ETSI EN 301 549: its version V3.2.1 builds on WCAG 2.1 AA, while version V4.1.1, published in September 2026, builds on WCAG 2.2 AA.
- The microenterprise exemption only covers services: fewer than 10 employees (BFSG § 3) and no more than 2 million euros (BFSG § 3) in annual turnover or balance sheet total. Anyone selling products alongside courses loses it for that part.
- A learning journey is a process, not a stack of pages. Booking, sign-in, course room, learning path, assessment and certificate belong in one audit, because barriers often only show up at the transitions.
- Course content in external formats stays the provider's responsibility even when the platform merely delivers it: embedded course modules, slide decks, scripts as PDFs and videos without captions.
- Task formats decide participation: matching exercises based on dragging need an alternative (WCAG 2.5.7), timed assessments need an extension (WCAG 2.2.1), progress and scores need more than colour (WCAG 1.4.1).
- Without trained course authors, the barrier grows back with every new module. The authoring process is the lever that turns a one-off repair into something durable.
Two rule sets, one course room: who is liable for what
Alongside certain products, the German Accessibility Act covers services in electronic commerce that businesses provide to consumers. A paid online course booked and paid for through your own website is exactly that: a contract concluded via a website or application and directed at consumers. The requirements have therefore applied directly since 28 June 2025 (Bundesfachstelle Barrierefreiheit), and not only to the sales page but to the entire service. The course room behind the login is part of the offering, not a private side matter. Technically, the act links the presumption of conformity to harmonised European standards (Section 4 BFSG); the reference is ETSI EN 301 549. For web content, its version V3.2.1 builds on the WCAG 2.1 success criteria at level AA, and version V4.1.1, published in September 2026, on those of WCAG 2.2 at level AA. Which offerings are affected in detail and which deadlines apply is set out in our overview of the BFSG requirements.
Universities, adult education centres, vocational training institutions and other public providers sit in a different regime. They have long been bound by the accessible information technology ordinance in its 2.0 version, derived from the German Disability Equality Act and EU Directive 2016/2102. The difference from the BFSG lies less in the technical benchmark, since BITV 2.0 also points to EN 301 549, than in the formal duties: public bodies must publish an accessibility statement, offer a feedback mechanism and name a conciliation procedure. Anyone having an accessibility statement drawn up should therefore know beforehand which regime their offering sits under, because the required content differs in the details. For universities there is the added complication that state equality statutes supplement the federal rules and sometimes set their own deadlines.
Mixed offerings: both regimes side by side
The microenterprise threshold in the education business
Many small education providers pin their hopes on the microenterprise exemption. It applies where a business has fewer than 10 employees (BFSG § 3) and either an annual turnover or a balance sheet total of no more than 2 million euros (BFSG § 3). The decisive point is the addition that is so often skipped: the exemption covers services only, not products. An online course is a service, so the threshold can indeed hold. But as soon as the same provider sells, say, e-book readers or consumer computers and tablets, that is a product in the sense of the act and the exemption falls away for that part. The pitfalls that are typically overlooked here are worked through in the article on the microenterprise exemption under the BFSG.
Commercially, the exemption is a weak foundation anyway. Anyone selling courses to public contracting authorities such as the employment agencies should expect accessibility requirements in tenders, regardless of whether the BFSG applies: under Section 121(2) of the German Act against Restraints of Competition (GWB), the specification for services intended for use by natural persons has to take into account accessibility criteria for people with disabilities or design for all users, except in duly justified cases. In Bitkom surveys, around 73% (Bitkom, 2025) of companies say they train their staff on digital topics, and 83% (Bitkom, 2025) of the teachers surveyed have access to digital learning platforms. The market is therefore large enough for buyers to set selection criteria, and accessibility can be one of them. Then there is plain reach: at the end of 2023 Germany was home to 7.9 million (Statistisches Bundesamt, 2024) people with a recognised severe disability, which was 9.3% (Statistisches Bundesamt, 2024) of the population. A course offering that cannot serve this group is voluntarily giving up a substantial share of its audience.
Course booking
The booking form, the price and the confirmation must be labelled, forgiving of errors and operable without a mouse. Error messages name the affected field and the way to correct it (WCAG 3.3.1, 3.3.2).
Sign-in
Access must not hinge on a cognitive test. Passwords have to be pasteable; any memory or puzzle task needs an alternative or an assisting mechanism (WCAG 3.3.8).
Course room
Landmarks, a coherent heading hierarchy and a focus that lands somewhere sensible after every change. Without that structure the course room becomes a black box (WCAG 1.3.1, 2.4.1).
Learning path
Progress, completed modules and locked chapters need a textual equivalent. Colour alone does not carry the information (WCAG 1.4.1).
Assessment
Every task needs a route to the answer without dragging, every time limit an extension or an off switch, unless the time itself is part of what is being assessed (WCAG 2.5.7, 2.2.1).
Certificate
The issued document is part of the service. Tagged structure, a declared document language, a sensible reading order and alternative texts all belong to it (WCAG 1.3.1, 1.1.1).
These six stations are not a checklist for six separate pages but the description of a single procedure. Anyone who only audits the home page and the course catalogue sees half of it at most, because the rest sits behind the sign-in. And anyone who only audits the course room misses the fact that prospects can already fail at the booking stage. The order is therefore part of the method: what gets tested is what a person actually does, one step after another.
The learning journey as one continuous process
An audit that ends at the sign-in stays on the surface because the object of the audit is cut wrongly. An automated scan sees the public pages, finds missing alternative texts and insufficient contrast there and reports a result that says nothing about the course. The real home of the barriers is behind the sign-in. That is where the course room, the learning path, the tasks, the forum and the download area live, and no scan without a valid session ever gets there. How to audit such a protected area methodically, without tangling up test data and test accounts, is described in the article on auditing accessibility behind the login.
Thinking in processes also changes what you look for. The question is not the individual page but the transition: where does focus land when a module is marked complete? Is the move from chapter three to chapter four announced at all, or does the application swap its content silently? Does an error message in the booking form stay visible while it is being corrected, or does it disappear at the next keystroke? Only a manual audit along the real chain of actions answers questions like these. The groundwork for the form part of that chain is covered in the article on accessible forms and validation; for the learning journey as a whole, a WCAG audit is the right frame, because it combines automated and manual testing and ranks the findings by severity.
| Aspect | Page-by-page audit | Learning journey audit |
|---|---|---|
| Object of audit | individual public pages | the chain from booking to certificate |
| Login area | left out | walked through with a test account |
| Transitions | not considered | focus, announcement and state changes are checked |
| Course content | treated as foreign content | embedded modules and documents count |
| Task formats | scored as a graphic | reproduced as an operation with the keyboard |
| Result | a list of isolated technical errors | prioritised defects along the learning path |
Barriers often sit where nobody looks
Course content in external formats
The most uncomfortable realisation for many education providers is this: the platform can be technically impeccable and the offering still inaccessible. The reason is course content that the platform merely delivers. Embedded course modules in standardised exchange formats are loaded into a frame as a closed package and bring along their own markup, their own interaction logic and their own barriers. The frame cannot repair them. Anyone exporting such packages from an authoring tool also exports its weaknesses: controls without an accessible name, a focus order that contradicts the visual arrangement, explanatory text that exists only as an image. Legally, none of this shifts responsibility. How duties are distributed when foreign components are embedded is covered in the article on third-party widgets and BFSG duties.
The second large group is documents. Scripts, slide decks, worksheets and model answers frequently sit in the download area as PDFs, and they were often exported from a word processor without tags, without a declared document language, often as a plain image of scanned pages. To a screen reader such a document is mute. Getting there is craft work, and existing source files make it easier; our service for preparing accessible PDF documents starts exactly here. The third group is video. In a marketing context a caption is often treated as an add-on; in a learning context it is the material itself: those who cannot hear learn from the caption, and those still building the technical vocabulary prefer to read along. Captions for recorded content are mandatory at level A, with audio description added at level AA (W3C, WCAG 2.2). The article on captions and transcripts describes what matters in quality and production.
- Embedded course modules are walked through with keyboard and screen reader before release, not just checked visually
- Every document in the download area has a tagged structure, a declared document language and a sensible reading order
- Scanned originals are replaced by real text documents instead of being served as images
- Recorded course videos have reviewed captions and a transcript that also describes board work and on-screen text
- The video player itself is keyboard operable and reports states such as pause, volume and caption status
- For every external format it is documented who created it and who owns the remediation
Tasks, tests and progress indicators
Task formats show most clearly how quickly sound pedagogical intent turns into a barrier. Matching exercises where terms are dragged onto fields, timelines to be sorted, images to be labelled: all of it lives on dragging with a mouse. For people with a motor impairment, with a tremor or working purely from the keyboard, such a task is simply unsolvable. WCAG 2.2 introduced success criterion 2.5.7 Dragging Movements for exactly this: any function triggered by dragging needs an alternative using a single pointer, such as tapping source and target or choosing from a list (W3C, WCAG 2.2). Added to that is the older criterion 2.1.1, which requires every function to be reachable from the keyboard. How to implement that in detail is described in the article on keyboard navigation in web development.
Timed assessments are the second classic. A test that closes after twenty minutes disadvantages everyone who reads more slowly, uses a screen reader or works with magnification. WCAG 2.2.1 therefore requires that a time limit can be turned off, adjusted to at least ten times the default setting, or extended after a warning, with a narrow exception where time is an essential part of the assessment (W3C, WCAG 2.2). Anyone modelling a supervised final exam can rely on that, but should provide the compensatory arrangements that are standard in higher education anyway. The third classic is progress bars and scores that carry their state through colour alone: green means passed, red means failed, grey means locked. WCAG 1.4.1 rules exactly that out. How widespread colour problems are beyond that is shown by a second figure: 83.9% (WebAIM Million, 2026) of the home pages analysed carried text with insufficient contrast, measured against the minimum requirement in WCAG 1.4.3. The groundwork is in the article on colour contrast in accessibility, and the newer requirements are placed in context in the article on the new WCAG 2.2 criteria.
Task formats are a pedagogical decision
Authoring process, forums and live sessions
A one-off remediation lasts until the next course is published. That makes the authoring process the real lever. Course authors are rarely developers; they work in an editor and see the result only visually. Whether a heading is genuinely a heading or just bold text, whether an image carries an alternative text, whether a table has header cells, is all decided in that editor. This is precisely what the Authoring Tool Accessibility Guidelines are for: they describe how an authoring tool should not only be operable itself but actively support the production of accessible content. How those requirements translate to a content management system is shown in the article on ATAG and accessible authoring tools.
In practice two things work together. First the tooling side: a required field for the alternative text, a warning when a heading level is skipped, a contrast check in the editor, a preview driven purely by keyboard. Second the people behind it, and for that you need training for course authors that starts from their daily work rather than from statutes. Whatever the tool chain leaves out is filled in by accessible web development on the platform itself. The downstream areas must not be forgotten either: course forums with posts that have no heading structure, comment features whose reply field receives no focus when it opens, and live sessions where screen shares run without spoken description and the chat log is one uninterrupted wall of text for a screen reader. For live formats a simple principle helps: whatever is shown is also said, and the chat log is made available as a structured document after the session.
A course is only accessible once someone can get from booking to certificate on their own. Anything else is a collection of individually audited pages.
Getting started follows a clear sequence. A stocktake first settles the regime, then walks the learning journey with a test account and sorts the findings by impact: what locks people out entirely, and what merely makes things harder? Typical candidates for such hard blocks are sign-in, task formats and documents; many other individual findings make use harder without locking anyone out. For education providers who want to take this route in a structured way, our page on accessibility in education and higher education sets out the approach. The frame itself stays stable: since 28 June 2025 (Bundesfachstelle Barrierefreiheit) the BFSG has applied to large parts of digital consumer business, breaches can be penalised under BFSG § 37 with fines of up to 100,000 euros (BFSG § 37), and in both regimes the technical yardstick rests on ETSI EN 301 549. Starting now can also win audience: among students with a study-impeding condition, 65% (best3, DZHW) name a mental health condition, a group for whom clear structure, calm design and predictable deadlines in a course are felt immediately.
Sources and Studies
Related Articles
Keeping Accessibility: Review Cadence After Go-live
The duty does not end at acceptance. Which events trigger a re-test, which sample size holds up and how long the evidence has to stay on file.
Accessible CMS Backends: ATAG for Authoring Tools
ATAG 2.0 audits the tool, not just the website: Part A covers the editing interface, Part B the guardrails that make accessible content the likely outcome.
Accessible Online Banking: the BFSG Duty for Banks
Account opening, online banking and TAN approval must be accessible since 2025. What the BFSG requires of banks, savings banks and fintechs in practice.