Checklist: Accessibility under BFSG/BITV 2.0 (WCAG 2.1 AA)

This detailed checklist helps you make websites accessible in line with the German Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz, BFSG). It is based on the legal requirements of the Ordinance on Barrier-Free Information Technology (Barrierefreie-Informationstechnik-Verordnung, BITV 2.0) and the Web Content Accessibility Guidelines (WCAG) 2.1, conformance level AA. The checkpoints are organised according to the four principles of accessibility – perceivability, operability, understandability and robustness – and can be used as a practical tick-box list.

Perceivability

Text alternatives

• Images and graphics: All informative images, icons and graphics have meaningful alternative texts (alt attribute) that describe their content or purpose. Purely decorative elements either have an empty alt="" or are included via CSS so that screen readers ignore them.

• CAPTCHAs: If visual CAPTCHAs are used, accessible alternatives are available – e.g. an audio CAPTCHA or another verification method – so that users with disabilities can also complete the test.

Time-based media (audio/video)

• Videos: Embedded videos with sound come with captions (subtitles) so that users with hearing impairments can also take in all the information. Important visual content in videos is conveyed either through audio descriptions or alternative text descriptions to make it perceivable for blind users. (Example: an explainer video on the home page includes captions and an audio description of the visual elements.)

• Audio: Audio-only content (e.g. podcasts) is supplemented by a transcript or an equivalent written summary, so that the information can also be taken in without being able to hear it.

Structure and adaptability

• Semantic structure: Content is logically and semantically structured. Headings are marked up in the correct hierarchy (<h1> … <h2> etc.), lists are implemented as <ul>/<ol>, tables are given <th> headers, and so on, so that relationships and information are recognisable to all users. Form elements have associated <label> elements, and in general, relationships in the layout are conveyed not only visually but also in the code (WCAG 2.1 Success Criterion 1.3.1).

• Screen orientation: The website supports different screen orienta­tions. Content is easy to use in both portrait and landscape format without a particular orientation being enforced (e.g. apps/pages are not restricted to landscape display only).

• Magnification and zoom: Users can enlarge the display up to 200% without losing content or functionality. There is no horizontal scrolling at 200% zoom on common screen sizes; the layout adapts (reflow). Text remains legible when enlarged and does not overlap or get cut off. The website works reliably with the browser's zoom functions (Ctrl/⌘+Plus) and does not require a special font-size switcher.

Visual design

• Colours and contrast: Information is never conveyed by colour alone – there is always a textual or graphical indicator as well. (Example: errors are not only marked with a red border but also with an error message in the text.) In addition, all text and controls have sufficient contrast. For body text at normal size, the contrast ratio is at least 4.5:1 (for large text from 18pt, or 14pt bold, at least 3:1). Likewise, graphical UI elements and icons have a contrast of at least 3:1 against the background. (Exceptions apply only to incidental decorations, logos and the like.)

• No forced audio: No audio or video is played automatically as soon as a page loads, or the user can immediately pause or mute media that start automatically. In particular, background music or background videos must not play unprompted and endlessly (WCAG 2.1 Success Criterion 1.4.2 requires media that play automatically for longer than 3 seconds to have a pause/stop function).

• No images of text: Pure text in graphic form is avoided. Text (e.g. headings, labels) is implemented as real web text and not embedded in images, unless this is unavoidable (for example with logos or branding). If, exceptionally, text does appear as part of a graphic, the alternative text contains the corresponding information.

• Content on hover or focus: If content appears on hover or focus (e.g. tooltips, drop-down menus), it is accessible to the user: it does not obscure other content, remains visible for as long as the mouse pointer or keyboard focus stays on it, and can also be dismissed manually by the user. (Example: a tooltip that appears when a button receives focus can be closed by pressing the Esc key.)

• Sign language (BITV requirement): For key content, especially on the home page, an explanation in German Sign Language (Deutsche Gebärdensprache, DGS) is provided (e.g. as a video). It conveys the main content of the website and guidance on navigation clearly in sign language.

• Easy Read (BITV requirement): A section in Easy Read (Leichte Sprache) is provided that summarises the essential content of the website and the navigation in very simple, easy-to-understand language. This Easy Read content is easy to reach from the home page.

Operability

Keyboard navigation and focus

• Keyboard operation: All of the website's functions are fully operable with the keyboard. This means that every interactive element (links, buttons, form elements, menus, etc.) can be reached and activated using the Tab key or other keyboard input, without a mouse or touchscreen.

• No keyboard trap: There are no keyboard traps. Focus can be moved on at any time and released from an element again – for example, the user can enter an embedded widget or dialogue box using the keyboard and then leave it again without getting stuck.

• Visible focus: The keyboard focus is visually highlighted, so it is always clear which element currently has focus. (For example, the focused link or button is indicated by a clearly visible outline or a highlighted background colour.)

• Logical focus order: The order in which you navigate through the page using the keyboard is meaningful and logical. It follows the visual structure of the page and the logical sequence of steps (e.g. in forms), so that operation remains predictable. When dialogues or overlays are opened, the dialogue box receives focus, and when it is closed, focus returns to a sensible place.

Navigation and orientation

• Page titles: Every page has a meaningful title in the HTML <title> element that clearly describes its content or purpose (e.g. "Product catalogue – Company XYZ" instead of generic titles).

• Skipping sections: There is a way to skip repeated page elements – e.g. a “Skip to content” link at the top of the page that leads directly to the main content. (Alternatively, ARIA landmark roles can be used for the main areas, provided screen reader users can navigate effectively that way.)

• Multiple ways in: Larger websites offer alternative ways to navigate so that content is easier to find. For example, users can use a search function, a sitemap or a table of contents in addition to the normal menu navigation.

• Descriptive link text: Links and buttons are labelled so that their purpose is clear. Avoid meaningless labels such as “Click here”. Instead, the link text makes clear what the user can expect (e.g. “Download product brochure (PDF, 2 MB)” instead of “Click here”).

Time limits and animations

• Time limits: If there are functions with a time limit (e.g. automatic session timeouts or forms that are cancelled after a set time), the user is warned in good time and has the option to extend the time period if needed. By default, time limits are generous enough that slower users can also complete all tasks without coming under time pressure (WCAG 2.1 Success Criterion 2.2.1).

• Pausing animations: Motion effects or automatically running animations (e.g. image carousels, auto-scrolling content) can be paused, stopped or hidden by the user. Controls (pause/stop) are provided to control moving content if the animation runs for longer than 5 seconds.

• No hazardous flashing: The website contains no strongly flickering content, to minimise the risk of epileptic seizures. In particular, no elements are used that produce more than three flashes per second (WCAG 2.1 Success Criterion 2.3.1).

Input modalities (mouse, touch, gestures)

• No single-key shortcuts: Operating the website does not require any non-customisable single-key keyboard shortcuts (such as pressing “B” on its own to search) that could clash with screen reader or browser shortcuts. If such shortcuts are offered, the user can turn them off or remap them, or they are only active when the relevant element has focus.

• Alternatives to pointer gestures: Functions that require a complex pointer gesture (e.g. swiping, dragging with drag&drop, multi-finger gestures) can also be used in other ways. There are alternative controls or methods that trigger the same action – for example, additional forward/back buttons when content is controlled by swipe gestures.

• Pointer action on release: With mouse or touch operation, actions are not executed immediately on pressing (mouse-down/touch-start) but only on release (mouse-up/touch-end). This allows users to cancel an input by moving the pointer away, and accidental activations are avoided.

• Label in name: The visible label of a control (e.g. the text on a button) is contained in its programmatic name. This means that screen readers announce the same wording – or at least wording that contains it – as is shown visually on the element. (Example: a button with the visible text “Search” should also be named “Search” programmatically and should not have a different aria-label such as “Submit”.)

• Device sensors can be disabled: Functions that are triggered by moving the device or by sensors (e.g. shaking or tilting a smartphone to perform an action) can also be triggered via normal controls. In addition, motion detection can be turned off so that users are not forced to shake or tilt their device. (This ensures that, for example, someone with motor impairments can still use the function.)

Understandability

Language and content

• Main language specified: The default language of the web page is declared in the HTML (e.g. <html lang="de"> for German). This lets browsers and assistive tools know which language the content is written in.

• Language changes marked up: If the language changes within a page – for example in quotations, foreign words or English terms – this is indicated in the code (e.g. <span lang="en">...</span> for an English word on a German page). This allows screen readers to adjust their pronunciation automatically.

• Clear, simple language: Texts are written to be as understandable and clear as possible. Long or convoluted sentences are avoided. If technical terms, abbreviations or unusual words are used, they are explained the first time they appear or a simpler paraphrase is offered. (Aim: users with cognitive impairments or lower reading skills can also follow the content.)

Predictability and consistency

• No unexpected changes: The user interface behaves predictably. Neither focusing an element nor changing an input (e.g. selecting a drop-down option) leads to a drastic change of context without warning (such as automatically jumping to another page). Changes to the page only happen as a deliberate user action (e.g. when clicking a button), or the user is informed beforehand.

• Consistent navigation: Recurring navigation elements and menu structures are arranged and labelled consistently on all pages. For example, the main menu always appears in the same place with the same items in the same order, so that users do not have to reorient themselves.

• Consistent identification: Elements with the same function are named and presented consistently throughout. If, for example, an icon or button triggers the same action on different pages, it has the same text or the same symbol everywhere. This helps users to reliably recognise recurring functions (WCAG 2.1 Success Criterion 3.2.4).

Forms and error prevention

• Input fields labelled: All form fields have unambiguous labels that are visible to users or at least recognisable to assistive technologies. Where appropriate, input assistance is offered – such as placeholder text or hints on the expected format (e.g. “DD/MM/YYYY” for a date).

• Error messages: If a user fills in a form field incorrectly or makes another mistake, this is clearly indicated. An understandable error message appears that describes the problem and, where possible, gives hints on how to correct it (e.g. “Please enter a valid email address.”). Error texts are positioned (for example close to the field concerned) so that they are easily noticed.

• Error prevention for important transactions: For processes that have legal or financial consequences or submit important data (e.g. online orders, forms that conclude contracts), there are special review or confirmation steps to prevent errors. Users are given the opportunity to check and confirm their entries before the final action is triggered, or they can reverse transactions afterwards. (Example: before an order is finally submitted, a summary page showing all entries and costs is displayed, with the option to make corrections.)

Robustness

Technical implementation

• Valid markup: All of the website's code complies with common web standards. HTML and CSS are valid (check them with the W3C Validator, for example) and contain no serious syntax errors. Semantic HTML structures are used consistently to provide a robust foundation for a wide range of browsers and devices. (Tip: rather than programming complex custom solutions, use standard HTML elements and controls wherever possible, as they are accessible out of the box.)

• Scripts and ARIA: Interactive functions are implemented so that they remain robust even under atypical conditions (e.g. disabled JavaScript does not cause a complete loss of functionality). WAI-ARIA is only used where it is necessary, and is then applied correctly. This means that custom widgets or dynamic content have been given the appropriate ARIA roles, states and properties without unnecessarily duplicating or overriding the native semantics.

Compatibility with assistive technologies

• Name, role, value: All interactive controls expose their name, role and value programmatically. Particularly with custom controls (e.g. custom-built drop-down menus, tabs, sliders), care has been taken to ensure that they are understandable to assistive technologies – for example through suitable ARIA roles (role="menu" etc.), labels (aria-label or an associated <label>) and state information (aria-expanded="true" for expanded elements, etc.).

• Status messages: Dynamic status or notification texts (e.g. result displays, confirmations, loading indicators) are implemented so that screen readers automatically detect and read them out. For this purpose, live regions are used, for example (aria-live="polite" for less urgent messages or role="alert" for important, immediate messages). As a result, screen reader users receive feedback even if focus is not explicitly moved to the message.

• Testing with assistive technologies: The website has been tested with common assistive technologies to ensure that all content is robustly accessible. This includes tests with screen reader software (e.g. NVDA, JAWS or VoiceOver), screen magnifiers, refreshable Braille displays or voice-controlled systems. Result: all functions can be used and understood by these technologies without errors. (Recommendation: in addition, carry out regular manual tests and gather user feedback to check accessibility under real-world conditions.)

Note: This checklist summarises the key requirements of WCAG 2.1 (Level AA) and BITV 2.0. It is no substitute for a thorough audit, but it offers a practical guide to identifying and removing typical barriers. By consistently implementing the checkpoints above, you ensure that your website meets the legal requirements and is fully accessible to all users – including people with disabilities.