Website Accessibility – A Guide to the BFSG (2025 Edition)

Introduction: Why accessibility matters

Web accessibility means that websites and digital offerings are designed so that everyone can use them – regardless of disability, age or assistive technology. An accessible website allows, for example, blind users to operate it with a screen reader and keyboard, offers sufficient color contrast for people with low vision and understandable content for everyone. This improves not only inclusion but often general usability as well.

From 2025, web accessibility also becomes a legal requirement for many companies in Germany. The new Barrierefreiheitsstärkungsgesetz (BFSG, German Accessibility Strengthening Act) implements the EU’s European Accessibility Act and comes fully into force on June 28, 2025 (Barrierefreies Internet – Wikipedia (in German)). This significantly widens the accessibility obligation – it no longer applies only to public authorities, but also to numerous private providers. One study found that at the end of 2024, 99 % of 2,446 German online shops examined still did not fully meet the requirements (Barrierefreies Internet – Wikipedia (in German)). There is therefore an urgent need to get websites ready for the new rules.

This guide is aimed at web agencies and their clients. It gives a comprehensive overview of who has to meet the requirements, by when the changeover must happen and which concrete measures are needed for accessible websites. We also show best practices with examples, name helpful tools and give pointers on mobile apps and documents. All in clear, understandable language – for developers as well as for project managers in companies.

Who has to meet the requirements?

From 2025, the obligation for web accessibility applies to a large group of players. In principle: public bodies have already had to make their websites and mobile offerings accessible in recent years (under BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung, German Accessible Information Technology Ordinance) since 2019 (Barrierefreies Internet – Wikipedia (in German)), with transition periods until 2020/2021 for older websites and apps (Barrierefreies Internet – Wikipedia (in German))). What is new is that many private companies must now offer accessibility too. This is regulated by the BFSG, which transposes EU Directive 2019/882 (European Accessibility Act) into German law (Barrierefreiheitsstärkungsgesetz – Wikipedia (in German)).

Particularly affected are providers of the following products and services for consumers (BFSG – Barrierefreiheitsstärkungsgesetz (in German)) (BFSG – Barrierefreiheitsstärkungsgesetz (in German)):

• Telecommunications services (e.g. websites of phone and internet providers).
• Passenger transport services (web portals of rail, air, bus and shipping companies; purely regional/local transport services are excluded).
• Banking services for consumers (online banking, finance apps).
• E-books and related reading software.
• Electronic commerce – this includes online shops, booking platforms and other e-commerce offerings for goods and services.

For these areas, the BFSG requires that websites (and likewise mobile apps, see below) meet the recognized accessibility standards. Small businesses are exempt, however: microenterprises with fewer than 10 employees and annual revenue under €2 million are not obliged to implement the requirements (BFSG – Barrierefreiheitsstärkungsgesetz (in German)). For them, the Federal Ministry of Labor and Social Affairs is merely to provide voluntary guidelines as support (BFSG – Barrierefreiheitsstärkungsgesetz (in German)). Sole proprietors and freelancers usually fall into this category if they are very small. Even so, it can make sense for them to make their websites accessible – whether to reach more customers or because accessibility is likely to become the industry standard.

All larger companies (small and mid-sized as well as large companies) in the areas mentioned, on the other hand, must meet the requirements. The law tries not to burden mid-sized companies in particular excessively (BFSG – Barrierefreiheitsstärkungsgesetz (in German)), but the obligation as such exists. Web agencies should therefore alert their clients early if they fall under the rules. When in doubt, it is worth getting a legal assessment of whether a particular offering counts as a “service in electronic commerce” etc. within the meaning of the law. The sectors named above serve as a guide.

Overview of obligated parties and exemptions

For a better overview, Table 1 once more shows who is subject to the web accessibility obligation and who is exempt, with examples:

(Note: Accessibility requirements also apply, for example, to ATMs, ticket machines, self-service terminals and other physical products – but these are outside the “websites” topic of this brochure.)

Implementation deadlines

The Barrierefreiheitsstärkungsgesetz comes into force on June 28, 2025 (Barrierefreies Internet – Wikipedia (in German)). By this date, the companies concerned must have made their websites and apps accessible so that new and existing digital offerings meet the requirements. In effect, this is an implementation deadline of mid-2025. Anyone who is not compliant by then risks violating the law.

For existing web content, there are partial exceptions and transitional rules, which mainly concern historical content (BFSG – Barrierefreiheitsstärkungsgesetz (in German)) (BFSG – Barrierefreiheitsstärkungsgesetz (in German)):

• Archive content: Websites or apps that count as archives – i.e. whose content is no longer updated or revised after June 28, 2025 – are exempt from the requirements (BFSG – Barrierefreiheitsstärkungsgesetz (in German)). Example: an old web presence that stays online only for documentation purposes and is no longer maintained from 2025 does not have to be made accessible retroactively.
• Older media: For recorded video/audio that was published before June 28, 2025, there is no obligation to add subtitles or audio description retroactively (BFSG – Barrierefreiheitsstärkungsgesetz (in German)). Likewise, office documents (e.g. PDFs) that were put online before this cutoff date do not have to be adapted retroactively (BFSG – Barrierefreiheitsstärkungsgesetz (in German)).
• Third-party content: Content from third parties that is neither funded or created by the website operator nor under its control (e.g. embedded external content, social media feeds) is also exempt (BFSG – Barrierefreiheitsstärkungsgesetz (in German)).

All new content from the 2025 cutoff date, by contrast, must be accessible. For newly added videos, for example, subtitles must be provided; new PDF documents must be created accessibly, etc. In practice this means: companies should start the changeover in 2024 at the latest in order to be compliant on time by June 2025. It is advisable to build accessibility into all relaunch and development projects as a fixed component right now.

Tip: It makes sense to make improvements before 2025. That way users benefit immediately, and the effort is spread out. Experience from the public sector also shows that accessibility has to be planned consistently – last-minute adjustments shortly before the deadline are risky and may be expensive.

Legal foundations in brief

To understand the context, here is a short overview of the relevant legal foundations in Germany:

• Behindertengleichstellungsgesetz (BGG, German Disability Equality Act) and BITV: Since 2002, the BGG has obliged the federal government to make its websites accessible (Barrierefreies Internet – Wikipedia (in German)). The specific Barrierefreie-Informationstechnik-Verordnung (BITV) has since listed technical requirements based on international guidelines (Barrierefreies Internet – Wikipedia (in German)). A new version, BITV 2.0, came into force on May 25, 2019 (Barrierefreies Internet – Wikipedia (in German)). It transposes EU Directive 2016/2102 (websites and mobile apps of public bodies). As a result, strict requirements (WCAG 2.1 AA) apply to all public websites – new sites had to be accessible from September 2019, existing ones from September 2020, mobile apps from June 2021 (Barrierefreies Internet – Wikipedia (in German)).
• European Accessibility Act (EAA): In 2019, the EU adopted the EAA, a directive that for the first time also obliges many private sectors of the economy to provide accessibility (Barrierefreies Internet – Wikipedia (in German)). It had to be transposed into national law by 2022; implementation in practice by June 28, 2025 at the latest (Barrierefreies Internet – Wikipedia (in German)).
• Barrierefreiheitsstärkungsgesetz (BFSG): The BFSG, passed in 2021, is Germany’s implementation of the EAA (Barrierefreiheitsstärkungsgesetz – Wikipedia (in German)) (Barrierefreiheitsstärkungsgesetz – Wikipedia (in German)). It extends the accessibility obligation to private digital offerings in the sectors mentioned, in addition to the public bodies already covered by the BGG/BITV (Barrierefreiheitsstärkungsgesetz – Wikipedia (in German)). The specific technical requirements refer to existing standards (in particular the EU standard EN 301 549). This standard, in turn, is based on the internationally recognized Web Content Accessibility Guidelines (WCAG) (Barrierefreies Internet – Wikipedia (in German)). Put simply: what already applies to government websites now also applies (adapted to their sector) to many private websites.
• Penalties and enforcement: Compliance with the BFSG is monitored by market surveillance authorities. Depending on the case, violations can lead to orders, possibly fines, or in extreme cases prohibition orders. In addition, those affected can lodge complaints – for public sites, for example, there is already a conciliation body under the BGG (Barrierefreies Internet – Wikipedia (in German)). Companies should therefore not assume that ignoring the requirements will go without consequences.

Technical requirements for websites (WCAG 2.1 & co.)

The accessibility requirements for websites are described in detail in standards. The WCAG 2.1 guidelines (Web Content Accessibility Guidelines) define success criteria at the international level for making web content perceivable, operable, understandable, robust. In the EU, these criteria were incorporated into the standard EN 301 549, which underlies the BFSG (Barrierefreies Internet – Wikipedia (in German)).

In practice, the technical requirements can be divided into individual topic areas. Below we explain the most important points for websites – from contrast to alternative text to keyboard operation – and show how they can be implemented in concrete terms. We refer to WCAG 2.1 conformance level AA, which corresponds to the legal minimum standard.

Text alternatives for images and media

Non-text content must be made accessible through text descriptions. In particular: Images on websites need alternative text (“alt text”). Alternative text is a short description stored in the alt attribute of the <img> element in the HTML. Screen readers read this text aloud so that, for example, blind people learn what the image shows.

Alternative text should directly convey the image and its visual message, briefly and concisely, and contain all information from the image that is needed for understanding and is not already in the surrounding text (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)). A good example:

<img src="logo.jpg" alt="Firmenlogo der Beispiel AG">

– here alt clearly describes the content (a company logo).

Bad examples would be alt=”bild1″ (no helpful information) or no alt attribute at all (the image then remains inaccessible to screen reader users). If an image is purely decorative and carries no informational content, it should get an empty alt=”” – then assistive technology ignores it. It is not acceptable to embed meaningful content only as an image without alt text (such as text within the image) (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)) (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)).

Tips for alternative text: Put yourself in the position of describing the image to someone over the phone. Mention relevant objects, people, actions etc., but no irrelevant details. Example: a product photo of a red sweater could have alt=”Red women’s wool sweater, front view” – the color and type of garment are relevant, the background of the photo is probably not. If the surrounding text already says “red sweater,” the alt text does not need to repeat that and can focus on any additional features (e.g. pattern, neckline). Short, precise alt texts are ideal (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)).

Besides static images, other media also need alternatives:

• Videos should have subtitles for people who are deaf or hard of hearing (at least for all spoken content and important sounds). If a video is purely informational, a transcript can be offered as an alternative. For important videos (e.g. product presentations), an audio description that describes visual scenes for blind people is also desirable – this can often be solved by having the speaker in the video verbally describe relevant events.
• Audio content (e.g. podcasts, audio files) should get a transcript or written summary so that deaf people can grasp the content.
• Icons and graphics: If symbols are used (e.g. a printer icon as a link to a print version), there should be either alt text or an ARIA label that describes the function (e.g. aria-label=”Print page”). Alternatively, an explanatory text can sit next to the icon.
• CAPTCHA images: Avoid visual CAPTCHAs where possible. If they are necessary, offer accessible alternatives (e.g. audio CAPTCHA or logic-based questions).

Best practice example: An online shop shows a product photo of a handbag. The item name (“Leather bag model X”) is already next to it as a heading. A suitable alt text could be: alt=”Black leather handbag, model X, front view”. This adds visual details (color, material) to the heading without redundancy. If the bag were shown in several views, you could use, for example, alt=”Rear view of the bag” for the additional images.

Contrast and color design

Contrast is crucial for people with low vision to be able to read text. The minimum contrast between foreground (text) and background should be 4.5:1 ( Understanding Success Criterion 1.4.3 | Understanding WCAG 2.0 ) (exception: large bold text may have 3:1, logos are exempt ( Understanding Success Criterion 1.4.3 | Understanding WCAG 2.0 )). This corresponds to the WCAG requirements at level AA. In practice this means: light gray text on a white background or yellow text on a light green button are usually too low in contrast. Instead, use dark text on a light background or vice versa.

A simple way to check is to use a contrast checker (see tools below). It calculates the ratio from color values. Example: black text on a white background has the maximum contrast of 21:1. White on medium blue reaches, for example, ~8:1, which is good. Light gray on white, by contrast, may be only ~1.5:1 and would be unacceptable.

Besides body text, controls must also have sufficient contrast. For example, buttons and links should stand out clearly from the background, and their text or symbol (e.g. an arrow on a button) should also be high in contrast. Graphics that convey information (charts, icons with meaning) should also be designed with high contrast – if necessary with outlines or borders so that all details are recognizable (G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text | Techniques for WCAG 2.0 ).

Never use color as the only distinguishing feature: People with color vision deficiency (e.g. red-green weakness) may otherwise not understand color-coded information. So if, for example, error messages are marked in red, a symbol or text should also point to them (such as “*Please correct the fields marked in red.” and perhaps a ⚠️ icon). Links should be recognizable not only by color but also, for example, by underlining.

Example: A contact form marks missing entries in red. Better: in addition, a text such as “This field is required.” appears below the field and a summary such as “Please fill in all required fields.” appears at the top. That way color-blind users also understand what to do.

Keyboard operability and navigation

A central requirement is that all functions of a website can be operated with the keyboard. Many people cannot use a mouse – e.g. blind people who work with a screen reader and keyboard, or people with motor impairments who navigate only with special keys or switches. WCAG 2.1 criterion 2.1.1 stipulates that no keyboard trap may arise (i.e. you must not get “stuck” in an element).

Specifically, that means:

• Focus control: With the Tab key, you must be able to navigate through all interactive elements (links, buttons, input fields, menu items etc.) in a logical order. Pressing Tab moves to the next focusable element, Shift + Tab to the previous one.
• Visible focus: It must be clearly recognizable which element currently has keyboard focus. By default, browsers show a blue or dotted outline around focused links/buttons. This focus indicator should not be removed via CSS! If it is customized, then only to make it clearly visible (e.g. a high-contrast, distinct outline or background change on focus).
• Accessible menus and controls: Navigation menus should be built so that they can be opened and closed with the keyboard. Example: a dropdown menu can be focused with Tab and opened with Enter or an arrow key, then you move through the entries with the arrow keys and select with Enter. If JavaScript is used for this, appropriate ARIA attributes and keyboard events must be implemented.
• No forced mouse use: Elements such as slideshows, carousels or maps should offer alternative ways to operate them (e.g. arrow keys for an image carousel, instead of only making arrow buttons clickable).
• Skip links: At the very top of the page, a hidden skip link can be added that becomes visible on focus, e.g. “Skip to content“. This lets keyboard users jump straight to the main content instead of tabbing through the menu every time. This is required by the BITV for public authorities and is also generally best practice.

Example: A web shop has a large navigation menu. A user without a mouse presses Tab: first a focus outline appears at the top of the screen on “Skip to content” – pressing Enter takes them straight to the main area and skips the menu. Alternatively, they could also tab through the menu step by step. When a menu item with a submenu is focused, it opens automatically (or with Enter), and they can navigate within it using the arrow keys. All product links are also reachable via Tab. In the product gallery slider, they can switch between images with the left/right arrow keys. This makes the entire purchase process possible without a mouse.

Structuring content (headings, lists, tables)

A good semantic structure of the web page is a cornerstone of accessibility. Headings, paragraphs, lists and tables should be marked up correctly with HTML tags so that assistive technologies can recognize the structure.

Heading hierarchy: Every page should have a main heading <h1> (e.g. the page title or article name), with subheadings <h2>, <h3> etc. below it in logical nesting. Headings organize the content and allow screen reader users, for example, to jump quickly from heading to heading. Many screen readers offer an overview of all headings on a page, which serves as a table of contents (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)). If these headings are named meaningfully, it is easy to find your way around. Important: never make headings look like headings merely by styling them bold and large without the corresponding <h1>-<h6> tags – to sighted people that would look like a heading, but blind people would not recognize it as one (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)).

Lists and bullet points: For bullet points and numbered steps, always use the <ul>/<ol> and <li> tags (unordered/ordered list). This makes the grouping of the list items clear. Screen readers announce, for example, “List with 5 items” and then read the list aloud. Here too: do not simply insert “•” symbols manually, but use real list elements.

Tables: Tables should be used only for real tabular data, not for layout. A data table must have headings in the first row and/or first column as <th> cells. Use the scope attribute (<th scope=”col”> or scope=”row”) to mark whether a heading refers to the column or the row (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)). Screen readers can then read out the headings while navigating, so you know which column/row you are in. For more complex tables, use headers attributes where needed to associate cells with headings.

Paragraphs and section tags: Structure text in paragraphs <p> – long blocks of text should be divided into logical sections. Where needed, use further semantic containers such as <article>, <section>, <nav> and <aside> to mark different areas of the page (main content, navigation, sidebar etc.). These ARIA landmarks also help with orientation, since screen readers can, for example, jump directly to the <nav> if it is declared correctly.

Example: On a news site, an article is built as follows: the title is an <h1>, subheadings are <h2> (and, if needed, further sublevels as <h3>). Below them, the content sits in <p> paragraphs. Important points are summarized in a <ul> list. At the end there may be a table of facts; the table’s header row is marked with <th> as heading cells. Next to the article (in the HTML possibly as <aside>) there are links to further articles; this list has an <h2> heading such as “More news”. The header area and navigation are marked with <header> and <nav>. This clear structure enables all users – with or without assistive technology – to grasp the content easily. Semantically correct code also often improves SEO (search engine ranking), since search engines, for example, weight headings more heavily (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)).

Accessible forms and interactions

Forms (contact forms, checkout processes, search fields etc.) are interactive elements that need particular care. Accessibility errors often occur here, e.g. missing labels. Key basic rules for accessible forms (Accessible forms | ASU IT Accessibility) (Accessible forms | ASU IT Accessibility):

• Every input field must have an associated label element (<label>) that describes its purpose (Accessible forms | ASU IT Accessibility). This can be done in two ways:
  • Either the <label> directly wraps the input field (e.g. <label>Email: <input type=”email” …></label>),
  • or the <label> has a for attribute that points to the id of the corresponding field (e.g. <label for=”email”>Email:</label> <input id=”email” type=”email” …>). Both variants connect the text description “Email” with the input field. When the field gets focus, screen readers then read out, for example, “Email, edit field.”
• Do not use placeholder text alone as a label: A gray placeholder in the field (placeholder) is no substitute for a visible label – it disappears as you type, and screen readers handle it inconsistently. Use placeholders only as a supplementary hint, not as the sole identifier. If a visible label is not wanted for design reasons, still include it in the code and hide it with CSS (using techniques such as position:absolute; clip: rect(1px,1px,1px,1px)) so that it remains available to screen readers (Accessible forms | ASU IT Accessibility).
• Grouping related fields: Use <fieldset> and <legend> to group fields that belong together (e.g. address fields, or a group of radio buttons) (Accessible forms | ASU IT Accessibility). The <legend> text serves as the overarching description of the group.
• Lists in select fields: For very long dropdown lists (<select> with dozens of <option>s), you can use <optgroup label=”…”> to create subdivisions (Accessible forms | ASU IT Accessibility) so that users can navigate faster (screen readers can jump from group to group).
• Visible indication of required fields: If fields are required, this should be made clear in the label (e.g. with a “*” and/or the text “Required field”) (Accessible forms | ASU IT Accessibility). Do not wait until submission to point out that something was forgotten; ideally, indicate it at the field itself.
• Make error messages user-friendly: If a form was not filled in correctly, clear error messages must appear (Accessible forms | ASU IT Accessibility). They should be phrased understandably (“Please enter a valid email address.” rather than just “Error!”), and they should be programmatically linked to the faulty field. This can be done, for example, by giving the error message an id and referencing it in the field via aria-describedby=”error-id”. Important: error messages must not be marked by color alone, but also in text.
• Make help texts and hints accessible: Many forms have help texts (e.g. “Your password must be 8 characters long.”). Make sure such hints are picked up by screen readers. You can, for example, put them in a span with its own ID and have the input field reference it with aria-describedby. That way the hint is read aloud as soon as the field is focused (Accessible forms | ASU IT Accessibility).
• Button labels: Buttons should say clearly what they do (“Submit,” “Search,” etc.). If a button has only an icon (e.g. a magnifying glass as a search button), it needs an aria-label=”Submit search” or a hidden text inside the button.
• Accessible Rich Internet Applications (ARIA): For more complex widgets (date pickers, modal dialogs, etc.), ARIA roles and attributes must be used to convey state and structure. For example role=”dialog” and aria-modal=”true” for a modal dialog, plus implementing keyboard control for it. ARIA is, however, an advanced topic – principle: “Use native HTML elements first, ARIA as last resort.” Native HTML elements (buttons, links, selects etc.) already bring a lot of built-in accessibility, while ARIA helps specifically where standard HTML is not enough.

Example – contact form:

<form action="/send" method="post">

  <fieldset>

    <legend>Kontaktinformationen</legend>

    <p>

      <label for="name">Name:<span title="Pflichtfeld">*</span></label>

      <input type="text" id="name" name="name" required>

    </p>

    <p>

      <label for="email">E-Mail:<span title="Pflichtfeld">*</span></label>

      <input type="email" id="email" name="email" required aria-describedby="emailHint">

      <small id="emailHint">Wir geben Ihre E-Mail nicht weiter.</small>

    </p>

  </fieldset>

  <p>

    <label for="message">Nachricht:</label><br>

    <textarea id="message" name="message" rows="5" cols="30"></textarea>

  </p>

  <button type="submit">Nachricht senden</button>

</form>

 

In this example, all fields have a <label>. Required fields are marked with an asterisk (and required in the code makes the browser show a message if the field is left empty). For the email field there is a help text <small> with the ID emailHint, which the field references via aria-describedby – so screen readers read out, for example, “Email, edit field, required, We will not share your email“. The structure is logically grouped with <fieldset> and <legend>. A user with a screen reader or keyboard only can understand and fill in this form without any problem.

Avoiding errors: Common problems in forms are, for example, missing labels – these are easy to find with tools. The WAVE tool marks form fields with a proper label with a green icon, and those without a label with a yellow warning symbol (Accessible forms | ASU IT Accessibility). This quickly shows where labels are still missing. You should also test whether pressing Tab jumps logically from field to field (mind the order in the HTML or set tabindex accordingly, although excessive use of tabindex should be avoided).

Further aspects and requirements

In addition to the core points above, there are further requirements to observe for full accessibility:

• Declare the language: The lang attribute should be set on the page’s HTML tag (e.g. lang=”en” for English). If sections within the page are in another language (e.g. a German quote), the lang attribute should also be set on the corresponding element. This lets screen readers choose the correct pronunciation.
• No automatic time limits without an alternative: If content changes automatically, rotates or expires over time (e.g. an automatic slider or a logout timer), the user should be able to stay in control – for example by being able to pause a slider, or being warned before a session timeout with the option to extend it, etc. Automatically scrolling or blinking content can be irritating for some users.
• Avoid flickering content: Content that flickers or flashes brightly (especially in the frequency range around 3–50 Hz) can trigger epileptic seizures. Such effects must be avoided or must stay below the threshold of three flashes per second.
• Responsive and zoom-friendly design: Users should be able to zoom the page up to 200 % magnification without content being lost or becoming unusable (WCAG criterion 1.4.4). A flexible, responsive layout and scalable font sizes (relative instead of absolute in CSS) support this. On mobile devices, no horizontal scrolling should be needed at 200% zoom.
• Input aids: For mobile websites, make sure to use the right input types (type=”email”, type=”tel” etc.) so that the appropriate virtual keyboards appear on smartphones. Such details are also part of accessibility (they make operation easier).

In summary, accessible web design requires clean HTML, thoughtful UX design and attention to user needs. The WCAG list may seem overwhelming at first, but many requirements follow from basic principles: make content available as text, keep interactions robust and operable in alternative ways, and provide clear, consistent structures. Table 2 summarizes the most important requirements and examples once more:

(Table 2: Most important accessibility requirements for websites, with examples)

Mobile apps and PDF documents (brief overview)

The accessibility obligation extends beyond websites to mobile applications (apps) and to digital documents that are provided. This is mentioned only briefly here, since the focus of the brochure is on websites – still, a few pointers:

Mobile apps: For the services covered by the BFSG, their mobile apps must also be accessible. The criteria are similar to the WCAG requirements, applied to apps. In practice this means: apps should be fully operable with VoiceOver (iOS) or TalkBack (Android). Developers must, for example, give controls accessibility labels, define the focus order for swipe gestures, ensure sufficient contrast in the app design as well, and offer gesture alternatives (a function reachable only by a complex gesture must also be reachable another way). EN 301 549 also contains detailed requirements for software and mobile applications. Companies that offer apps (e.g. banks with a banking app, transit operators with a timetable app) should carry out an accessibility review of their apps. From June 2025, new apps must be accessible; existing ones should be updated accordingly.

Documents (PDF & co.): Websites often provide PDFs or other documents for download (reports, forms, product information). Such files are part of the web offering and must also be accessible if they are published after the cutoff date. An accessible PDF contains, for example, text layers (not just scanned images), correct heading tags, bookmarks, alternative text for images, table structure and a logical reading order. PDF/UA exists as a standard for accessible PDFs. Tools such as Adobe Acrobat Pro or PAC (PDF Accessibility Checker) can be used for checking. Alternatively, HTML pages should be provided where possible, since HTML is generally easier to access than complex PDF files.

Office documents (Word, PowerPoint) should also be created according to accessibility principles (e.g. with proper heading styles, captions for graphics etc.) before they are exported as PDF. For technical documentation or reports, it is advisable to also keep alternative formats (HTML, accessible PDF) available on request.

In short: If your web offering contains other digital content besides HTML pages, remember to make it inclusive too. The same principles often apply: text instead of images, structure instead of visual layout, labels instead of pure looks.

Tools and aids for support

Implementing and checking accessibility can be made easier with various tools. There are a number of free testing tools that web developers and editors can use to analyze their pages. Here is a selection of important aids:

• WAVE Web Accessibility Evaluation Tool: A browser add-on (or online service) from WebAIM that analyzes a page and overlays hints graphically. It marks, for example, existing alt texts, missing form labels, contrast problems and much more. It is helpful for developers because you see colored icons and outlines directly on your own page showing where something needs improvement. As mentioned, WAVE shows, for example, a green symbol for correctly labeled fields and a yellow warning symbol for missing labels (Accessible forms | ASU IT Accessibility). WAVE is available for Chrome and Firefox.
• axe by Deque Systems: Another tool available as a browser extension that scans a page at the push of a button and outputs a report of detected problems according to WCAG. Axe integrates, for example, into the Chrome Developer Tools. It lists errors (e.g. “Image without alt attribute”) and gives hints on how to fix them. Many automated test suites (Nightwatch, Selenium etc.) can be extended with axe rules to check accessibility in continuous integration.
• Color Contrast Analyzer: A small tool (from TPGi, formerly the Paciello Group) for Windows/Mac that lets you check any pair of colors on screen. You pick the foreground and background color with an eyedropper, and the tool shows the contrast ratio and whether it is WCAG-compliant (for AA and AAA). This lets you validate design decisions quickly. Alternatively, websites such as the WebAIM Contrast Checker offer similar functionality in the browser.
• Screen readers for testing: To get a feel for usability, it is advisable to try testing with a screen reader yourself. On Windows, NVDA is available for free – after a short learning period you can experience your own site first-hand with it. On the Mac, VoiceOver is built in (Cmd+F5 turns it on). Check with it, for example: can you navigate everywhere with Tab? Are sensible labels read aloud? Is the order logical? – These are things automated tools do not always fully detect, which is why a manual test with assistive technology is very valuable.
• Browser developer tools: Modern browsers often have built-in accessibility inspection. In Chrome, for example, the DevTools include a “Lighthouse” audit for accessibility that delivers a percentage score and points out problem areas. Edge and Firefox have similar features. While these do not replace a thorough check, they give a good overview. You can also view the computed accessibility properties of elements (role, name, descriptions) in the DOM inspector to check, for example, whether an ARIA label has arrived.
• BITV test: In Germany there is the BITV test (bitv-test.de), an extensive testing procedure with 60 test steps, developed in the project “BIK – barrierefrei informieren und kommunizieren” (accessible information and communication). It is often carried out by experts but can also be used for self-assessment. It systematically covers all WCAG criteria. The full BITV test is very detailed, but the website offers checklists and examples that can help make sure nothing important is overlooked.

Tip: A combination of automated checks and manual tests leads to the best result. Use tools such as WAVE or axe to quickly find easily detectable errors (they reliably find, for example, missing alt texts, missing labels, clear contrast violations). Afterwards, though, competent testers – ideally including users with disabilities themselves – should always review the application. Only then do you detect, for example, comprehension-related problems or special usage requirements.

Best practices and outlook

When implementing web accessibility, it has proven worthwhile to think about the requirements early in the project and to anchor them firmly in the process. Some best practices to close with:

• Design phase: Color contrast and font sizes should already be taken into account in the design. Define a color palette that is WCAG-compliant. Plan enough space for accessibility aids (e.g. visible focus outlines, skip links). A designer should know, for example, that placeholder texts are not meant to be the sole labels, etc.
• Development phase: Use HTML5 semantic elements and avoid unnecessary div spaghetti. Integrate tools such as axe into the test pipeline right from development. Create coding guidelines for accessibility (e.g. always <button> instead of div for clickable elements, always alt on <img>, etc.).
• Maintaining content: Editors should be trained in how to write accessible content – e.g. headings in the correct order, entering descriptions for images in the CMS field “Alternative text,” choosing understandable link texts (“Sign up now” instead of “Click here”), and so on. An editorial handbook with dos and don’ts can be helpful.
• Testing and feedback: Run user tests with people with disabilities if possible. Even a small test with 1–2 screen reader users can yield valuable insights (e.g. whether your ARIA labels are really read out sensibly). Use browser extensions and validation services regularly during development, not only at the end.
• Continuous improvement: Accessibility is not a one-time box to tick but an ongoing process. Technologies and assistive tools keep evolving. Keep your website up to date and fix newly arising problems (e.g. when a content module is added, check it for accessibility right away). Also stay informed about updates to the WCAG – version 2.2 is around the corner, WCAG 3.0 is in planning, which could bring further aspects in the future.

From 2025, accessibility will have to be a matter of course for professional web presences – much like responsiveness or data protection today. For web agencies, this is on the one hand a challenge to acquire know-how, and on the other a chance: you can offer your clients real added value and stand out through quality and inclusive design. Clients in turn benefit from wider reach (around 20% of the population have a recognized disability, and many older people also appreciate low-barrier offerings) and from the positive image of welcoming all users. Accessible sites also often improve overall usability – clear structures and texts benefit everyone, not just people with disabilities.

Conclusion: The requirements of the BFSG may seem complex, but with the right methods they can be implemented successfully. This brochure has given the most important guidelines and examples. Use the references and tools to dive deeper. Accessibility is teamwork – designers, developers, editors and clients must pull together. The best approach is to start today making your web offerings accessible step by step. That way you will be well prepared when the new rules come into force on June 28, 2025 (Barrierefreies Internet – Wikipedia (in German)) – and at the same time you will be doing something good for a more inclusive digital world.

Sources and further links

• Federal Ministry of Labor and Social Affairs (BMAS): Barrierefreiheitsstärkungsgesetz (BFSG) – legal text and information. (Federal Law Gazette 2021 I p. 2970) (Barrierefreiheitsstärkungsgesetz – Wikipedia (in German)) (Barrierefreiheitsstärkungsgesetz – Wikipedia (in German)).
• European Union: Directive (EU) 2019/882 (European Accessibility Act) – EU requirements for accessible products and services (Barrierefreies Internet – Wikipedia (in German)).
• Wikipedia: Barrierefreies Internet (accessible internet) – background on legal rules, WCAG and the state of studies (Barrierefreies Internet – Wikipedia (in German)) (Barrierefreies Internet – Wikipedia (in German)).
• W3C Web Accessibility Initiative: Web Content Accessibility Guidelines (WCAG) 2.1 – international guidelines for accessible web content ( Understanding Success Criterion 1.4.3 | Understanding WCAG 2.0 ).
• W3C WAI: Understanding WCAG 2.0/2.1 – explanations of success criteria (e.g. contrast min. 4.5:1) ( Understanding Success Criterion 1.4.3 | Understanding WCAG 2.0 ).
• MDN Web Docs: HTML: A good basis for accessibility – tutorial (English) on HTML basics including alternative text (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)) and structuring (HTML: Eine gute Grundlage für Barrierefreiheit – MDN (in German)). German translation available.
• Accessible University (ASU) Guides: Accessible Forms – best practices for accessible forms (Accessible forms | ASU IT Accessibility) (Accessible forms | ASU IT Accessibility).
• WebAIM: Contrast Checker – online tool for checking contrast, WAVE tool – accessibility checker in the browser (shows form labels, among other things) (Accessible forms | ASU IT Accessibility).
• German BITV test procedure (BIT inklusiv) – catalog of test criteria and self-assessment tool for web accessibility.

(As of April 2025 – all information and legal bases researched to the best of our knowledge. For legal advice, please contact official bodies or legal counsel.)