Reading time: 8 minutes

Correct technical implementation of web accessibility

Hands On - The BFSG 2025

The German Accessibility Improvement Act (BFSG) will bring new requirements for digital accessibility from June 2025. For developers and technical teams, this means they face the challenge of designing inclusive and accessible websites. In this article, you will learn which technical aspects are particularly important and how to implement them successfully. The focus here is on the technical implementation.

We support you with the technical implementation of accessibility

Usability - Several ways to navigate

The Web Content Accessibility Guidelines (WCAG) stipulate that websites must be navigable in at least two independent ways. The navigation methods include:

• Keyboard navigation: All functions must be accessible via the keyboard.
   
• Voice control: Users should be able to operate the device using voice commands.
   
• Gesture control: Gestures can be used for navigation on mobile devices.
   
• Search function: A search function enables users to search for specific content.
   
• Breadcrumb navigation: Shows the position within the website and facilitates orientation.
   
• Table of contents: Especially with long pages, a table of contents helps you to navigate to specific sections.
   
• Sitemap: Provides an overview of the entire website.

The most important option apart from using the mouse is still navigation via the keyboard. A search is also a good option. If you cannot integrate a search, you should use breadcrumb navigation or, not popular but sufficient, the sitemap.

Ensuring keyboard accessibility

The complete operation of a website must also be possible without a mouse. This requires a second type of navigation using keyboard or voice control. Keyboard operation is essential, especially for users who rely on assistive technologies such as screen readers. Screen readers interpret the HTML code of a website and output the content acoustically or in the form of Braille. To do this, all interactive elements such as buttons, links and forms must be able to be focussed and activated using the keyboard.

To ensure operation via the keypad, the following requirements must be met:

• Logical HTML structure: Elements such as headings (h1-h6) must be in a sensible order.
   
• HTML structure elements, such as <nav> for the navigation or <header> for the header element, help both search engines and assistive technologies (screen readers) to better understand the structure of the page and should therefore be used.
   
• Avoid keyboard traps: Iframes and elements that are irrelevant for navigation should be excluded by tabindex -1
   
• Skip navigation

Skip navigation

To make your website accessible, users should be able to skip over repetitive areas such as headers or footers. A skip link makes it possible to jump directly to the main content without having to go through menus or headers. These links are usually invisible and only appear when using a keyboard or screen reader.

A code example for the implementation of skip links:

In addition to skip links, semantic HTML elements like <header>, <nav> and <main> or ARIA roles ensure clear and logical navigation. Screen readers can thus jump directly to important areas such as headings or paragraphs. ARIA roles offer additional flexibility by assigning specific meanings such as ‘navigation’ to elements like <div>. Further information can be found in the ARIA documentation.

Focus indicator - visible navigation

A visible focus for interactive elements such as buttons, links or form elements is essential. This is usually achieved by changing the border or background with a CSS adjustment of the element's outline property:

Adjust colours and styles to integrate the focus harmoniously into the design. Buttons and links should clearly indicate that interaction is possible here, even when inactive.

When using the browser's own outline, it must be checked during implementation whether the contrast strength is sufficient. Unfortunately, this is usually not the case, so the colour must be adjusted using CSS.

Even when inactive, buttons and links should clearly indicate that interaction is possible here, e.g. by underlining and clearly labelling links.

Overlay elements

Overlay elements, such as hamburger menus, pose a particular challenge. These elements must be correctly semantically labelled in order to be accessible for screen readers and other technologies. For example, use the aria-haspopup attribute. This way, a screen reader user also knows directly that the new content must be operated using arrow keys. In the case of the hamburger button, the value ‘menu’ or ‘true’ should be assigned.

Here is an example:

A few points must be taken into account to ensure that a overlay element is semantically correct. As can be seen in the previous code example, a overlay element is usually technically realised as a <button> element or is given the role of a button via ARIA.
A meaningful label is essential so that users understand what the button does. This can either be placed directly in the <button> element or added via the aria-label or aria-labelledby attribute.

In addition, an aria-describedby attribute can be used to provide a detailed description of the button and its function. This description can be in a separate element and is then referenced via the ID. This is particularly helpful if the function of the button is not immediately obvious or if additional information is required, such as operating instructions. You can also find more detailed information on this under the following link:  https://www.barrierefreies-webdesign.de/knowhow/links-oder-buttons/menu-button.html

To stay on the subject of menus: Buttons for closing the menu or pop-ups are often neglected, so that in the end they are often only accessible to mouse users. There are a few possible ways to avoid this:

1. text without icon: (close)
2. button with text and only visibly accessible icon: (close x)
3. hidden text and only visibly accessible icon: (x)

Here is a code example from Manuel Matuzovic (https://codepen.io/matuzo/pen/zYvbmvm?editors=1100) for the third variant:

Making online forms accessible

Semantics are crucial for accessible forms. All control elements must have these properties:

• If possible, only the standardised HTML controls such as <input> or <select> should be used. If you use other controls such as drag-and-drop functions, these must be supplemented by WAI-ARIA.
   
• Form elements are always labelled with names. These form labels can be added using the label element or the title attribute, some WAI-ARIA attributes and the legend element.
  When labelling, it is also important to ensure that the user recognises what they are supposed to enter even without further context. The labelling should be consistent in terms of presentation and function across all pages.

An example of an accessible form field:

Forms and error prevention

• Input fields: For input fields, the mandatory fields must be clearly labelled. Ideally, this is done directly in the labelling, e.g. with an asterisk. If you have predefined values, e.g. in a dropdown, these must also be clearly labelled.
   
• Error messages: If the user makes incorrect entries, the system must provide direct feedback. If possible, specific suggestions for corrections should also be made.
   
• Confirmation and cancellation: Before final submission, the user should have the opportunity to check their entries. For transactions with far-reaching consequences (financial or legal), the user must also have the option of cancelling the transaction.

Accessible media

Audiovisual content must contain subtitles and audio descriptions. Select a player that has the following properties:

• Complete operability via keyboard
   
• Volume control independent of system volume
   
• Customisable display of subtitles

Live content

Synchronised subtitles are essential for live content such as audio and video. These can be created manually or generated using ASR (automatic speech recognition) systems. Good audio quality, minimal background noise and clear pronunciation are crucial for the accuracy of these systems.

Choose a video or audio player that can be operated using a keyboard, controls the volume independently of the system volume and supports functions such as pausing or adjusting subtitles.

Perceptibility of content

Zoom and text size

Text and other content must be able to be enlarged up to 200 % without losing functions or content. Therefore, avoid fixed pixel values and use relative units such as em or rem.

Example of scalable text:

Image maps

If client-side image maps are used, each <area> must have an alternative text indicating the destination or function. This is important because screen reader users cannot see the image map and therefore need the alternative text to understand what is behind the individual areas.
In concrete terms, this could look like this:

Accessible downloads

Downloadable content such as PDFs or Word documents should also be designed to be accessible so that all users can access them without any problems. Please note here:

• Structuring:
  • Use headings to clearly show the structure of the document.
  • Use lists and tables correctly.
  • Use paragraph formatting to organise the text visually and semantically.
     
• Images:
  • Alternative texts describing the content should be provided for images and graphics.
     
• Tables:
  • Tables should have a clear structure and be provided with headers.
  • Do not use tables to format text.
     
• Colour contrasts:
  • Ensure sufficient colour contrasts between text and background.
     
• Fonts:
  • Choose fonts that are easy to read.
     
• PDF/UA:
  • When creating PDFs, use the PDF/UA format, which was specially developed for accessible documents.

Besides:

• Choose widely used and accessible file formats (e.g. PDF, DOCX, MP3, MP4).
   
• Make sure the file size is appropriate to ensure fast loading times.
   
• Use meaningful file names and metadata (title, author, description) to make searching and organising easier.
   
• Use tools to check the digital accessibility of your documents (e.g. Accessibility Checker in Microsoft Word, Adobe Acrobat Pro).

CAPTCHA alternatives

Sensory CAPTCHAs (visual or auditory) must offer at least one alternative to acoustic CAPTCHAs or other methods such as honey pot traps. The aim is to ensure that users with disabilities can also pass them. Clearly describe the purpose of non-text content via text.

Language of the website

In order for computers to understand and correctly process the language of a website, the language of the website must be defined in the <html> tag using a lang attribute (e.g. <html lang="de"> for German). If a different language is used in individual sections, this can be indicated via a lang attribute in elements.

Closing words

The technical implementation of web accessibility requires thoughtful planning and detailed testing. Use standards such as WCAG 2.1 to ensure that your website is accessible to all users. This not only creates a better user experience, but also ensures compliance with legal requirements.

Get active and make your website accessible with us!

References

[1] dkd experts for your accessible website
[2] Accessibility Reinforcement Act 2025
[3] Accessible responsive website relaunch for the BSBH