The deadline for digital accessibility is fast approaching. The Accessibility Strengthening Act will come into force in Germany on 28 June 2025. But what does this mean in concrete terms for qnips as a company and for you as our customers?  

In our last blog post, we highlighted the basics of the new directive. Today, we show how we at qnips and you as our customers can actively implement accessibility.   

Accessibility starts with us: How qnips works without barriers  

At qnips, we do not see accessibility as an additional feature, but as an integral part of our product development. We started integrating accessibility criteria into our platforms early on. Find out which guidelines of the new law are qnips’ responsibility here:  

The four principles of digital accessibility  

Perceptibility: Digital content must be perceptible to all senses – regardless of whether you can see, hear or use other senses.  

Operability: All functions of a website or app must be operable – even without a mouse or in the case of motor impairments.  

Understandability: The content and operation must be understandable for all user groups – even those with cognitive impairments or limited language skills.  

Robustness: In the context of accessibility, this refers to the ability of content to be reliably interpreted by different user agents (e.g. browsers or assistive technologies) – even as technologies evolve.  

The following points are considered to be within the scope of qnips’ responsibility:  

• Necessary instructions must not be operable solely by sensory means (1.3.3)  

Example: Instructions such as ‘Click on the red button’ are problematic because they refer only to colour. Accessible would be: ‘Click on the red button labelled “Continue”.’  

• The meaning and requirement of each input field can be determined by assistive software using program code (1.3.5)  

• Videos longer than 3 seconds must be pausable and the volume must be adjustable independently of the system’s own volume (1.4.2) 

• The size of the text can be enlarged up to 200% if necessary without restricting functionality (1.4.4)  

• Text fits into the display in such a way that scrolling is only necessary in one direction (1.4.10).  

• Text or letters must not be restricted in terms of content or function if certain text parameters, such as line spacing, are changed by program code (1.4.12).  

Example: A user changes the line and paragraph spacing in their browser to make content easier to read. The qnips page adapts without any problems: texts remain fully visible, and functions such as ‘Order’ or ‘Remember dish’ continue to work. Content does not overlap and nothing is cut off – thus qnips meets the requirements for flexible, accessible text display.  

• Mouse-over content remains visible as long as the mouse pointer hovers over it and can be closed manually (1.4.13)  

The following guidelines apply to operability:  

• All functions of a website or app must be fully operable with the keyboard – even without a mouse or touch gestures (2.1.1)  

• If the keyboard focus can be moved to a specific location using the keyboard, it must also be possible to move the focus back in the same way (2.1.2)  

• Software-specific commands via keyboard shortcuts must be deactivatable or customisable (2.1.4)  

• Time limits, such as countdowns, must be preceded by warnings and offer the option of extension, unless these time limits are linked to unchangeable or externally determined events (2.2.1)  

• Automatically moving, flashing and scrolling elements must be pausable or switchable off (2.2.2) 

• Repetitive content must be skippable (2.4.1) 

• Websites have a title that describes the topic and/or content (2.4.2)  

• Elements of the website should be accessible in the same order as they are arranged visually and in terms of content on the page (2.4.3)  

• The text of a link must clearly describe the purpose of the link (2.4.4)  

• Subpages of a website must be accessible independently of the home page (2.4.5)  

Example: In the qnips catering portal, you can access any subpage – for example, the menu, the order overview or the allergy information – directly without first going to the home page. This is particularly helpful for people who use reading aids or voice control, because they can jump directly to where they want to go.  

• When navigating a website with the keyboard, it must always be clearly recognisable which element is currently active – for example, by means of a visible border. People using screen readers must also be able to hear the focus. Actions should also be possible via keyboard or voice – i.e. without a mouse (2.4.7)  

• The user should receive information about the current status of the website (e.g. whether they are on the home page or a subpage) (2.4.8).  

• All functions that normally require multiple fingers or a specific movement should also be usable with a single finger and without complicated gestures – unless this specific gesture is absolutely necessary (2.5.1).  

• A ‘Delete’ button should not respond immediately when clicked, but only when released – this allows the user to cancel if they have made a mistake (2.5.2)  

• The text content of a single text or even a text in images must also be stored in the programme code (2.5.3)  

• If the operation requires moving the device (e.g. shaking or tilting), there should also be another way to operate it via buttons or menus – unless the movement is necessary or specifically intended for accessibility (2.5.4). 

qnips handles the following points of comprehensibility:  

• The programme code indicates the language in which the content is written – for example, whether it is German, English or another language (3.1.1).  

• If the language changes within a text – for example, from German to English – the software should be able to recognise this so that screen readers, for example, can read it correctly. Exceptions are proper names, technical terms or special jargon (3.1.2)  

• If you use the keyboard or mouse to focus on a drop–down menu, for example, it must be easy to exit using the ‘Escape’ key, for example, allowing the user to move the focus to the next element. This prevents the keyboard focus from getting stuck in such elements (3.2.1).  

• If elements change as a result of user input, the user must be informed in advance about what is changing and to what extent (3.2.2).  

• It is important that the menu navigation always looks the same on every page and is always in the same place. This makes it easier for all visitors to find their way around (3.2.3).  

Example: Imagine you are visually impaired and you visit a website and find the menu at the top right. You click through various pages – but suddenly the menu has disappeared or is in a different place. You have to search again and lose your bearings. To prevent this from happening, a consistent menu navigation is crucial: if the menu looks the same on every page and always stays in the same place, you can find your way around more easily and use the website without stress.  

• If an element on a website has the same function (e.g. a submit button), it must always look the same and work the same way. This helps everyone to find their way around more easily (3.2.4).  

• If someone fills out a form incorrectly, the website should specify exactly where the error is and what was wrong – in clearly legible text (3.3.1).  

Example: An employee wants to pre-order lunch via the qnips catering portal. She enters her name and the desired meal correctly in the form, but forgets to enter her email address – a mandatory field for the order confirmation. After submitting the form, she receives the following message directly below the corresponding field:  

Error: Please enter a valid email address. Example: marie.mustermann@example.com 

The email field is also clearly marked with a red border so that the error is immediately visible. The form automatically sets the keyboard focus on the incorrect input field. In addition, the error message is integrated in such a way that it can be read aloud by screen readers. 

• If users are required to enter information, such as their name or email address, the fields must be clearly labelled or provide brief instructions on what is expected (3.3.2).  

• If an error is detected and it is clear how it can be corrected, the website should assist the user in doing so, for example with a hint. Unless this would reveal sensitive data that could be seen by several people, e.g. on a display that can be used in public (3.3.3)  

• For important data entries such as purchases or contracts, the user must be able to correct errors and/or review their entries collectively before submitting them and/or cancel data that has been sent (3.3.4)  

The following guidelines fall under robustness:  

• In the programme code, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and all IDs are unique, unless the specifications allow these properties (4.1.1).  

• Control elements must be understandable for assistive software. Therefore, the program code must identify the name, role, state and changes for each element (4.1.2)  

Example: To enable people with assistive programmes such as screen readers to use qnips effectively, the code specifies exactly what each button or selection field is, what it is called and whether it is currently activated. For example, when you click on the ‘Order now’ button, you hear that it is a button and whether the order has been received. This way, all users know exactly what is happening on the page.  

• Status messages for elements must be recognisable by assistive software without being actively controlled by the user (4.1.3)  

The following is the responsibility of our customers:  

qnips provides the technical basis for barrier–free accessibility. Our customers are also independently responsible for barrier-free use. They must consider and integrate aspects of accessibility into their daily tasks/work routine.  

The following aspects are considered perceptible:  

• Alt texts must be provided for images that the customer maintains themselves via the content description (1.1.1).  

• Videos must contain either subtitles or a text alternative. This means either providing a video with embedded or switchable subtitles. If no video is necessary, offering the same content in text form that can be read aloud by screen readers (1.2.1 to 1.2.5).  

• Videos with sound need subtitles, unless the audio is already an accessible alternative to text (1.2.2).  

• Documents or audio descriptions are available as alternatives to audio and video media (1.2.3).  

• Recorded videos offer audio descriptions (1.2.5).  

• Information must not be conveyed solely through colour. At least one explanatory text is required (e.g. a traffic light system) (1.4.1).  

• For text and images that contain text, the contrast ratio must be at least 4.5:1. A lower ratio of 3:1 is only permitted if the text is at least 18pt in size or 14pt in bold. Purely decorative images and text, as well as logos, are excluded from this rule (1.4.3).  

More readable, real text should be used instead of embedded text in images – unless there is no other option (1.4.5)  

• Important visual elements such as status indicators or parts of graphics must be clearly recognisable and have a colour contrast ratio of at least 3:1 to their surroundings. Unless they are inactive, coloured by the user afterwards or must be used in this colour scheme (1.4.11).  

You should also consider the following aspects of usability:  

Visual effects that flash rapidly or contain intense colour changes must be designed so that they do not flash more than three times per second and do not contain strong contrasting flashes. Otherwise, adjustments or alternatives are necessary to avoid the risk of photosensitive seizures (2.3.1).  

Each heading must clearly state the topic of the following section. Each label on buttons or input fields must clearly state what happens or what is entered. This allows all users to find what they are looking for more quickly and use interactive elements correctly (2.4.6). 

Helpful tools that support an accessible platform 

Companies that want to implement an accessible website can use various helpful tools: Screen readers such as NVDA, VoiceOver or TalkBack can be used to test whether content is easily accessible for visually impaired users. Browser extensions such as axe DevTools, Lighthouse or Accessibility Insights automatically check WCAG compliance and highlight missing alt texts, incorrect ARIA attributes or poor focus guidance. Colour contrast checkers (e.g. Contrast Checker from WebAIM or the Colour Contrast Analyser tool) ensure that text and graphic elements are sufficiently legible. Developers can also integrate CI integration tools such as Pa11y or axe-core into their build processes to run continuous automatic tests. For design, plugins in Figma or Adobe XD (such as ‘Able’ or ‘Stark’) offer contrast and colour blindness simulation as early as the design phase. Accessible component libraries such as Material UI or Reach UI ensure that common widgets (buttons, forms, modals) are accessible by default.  

Our goal: digital participation for all 

Accessibility is more than a legal obligation – it is an expression of respect and sustainability. It demands – and promotes – innovation, user centricity and social responsibility. At qnips, we are ready to walk this path together with our customers – through consulting, technological solutions and partnership–based cooperation. 

In Germany, the Accessibility Improvement Act, which is based on the EN 301 549 directive ‘Accessibility requirements for information and communication technology products and services’ for product-related accessibility, will come into force on 28 June 2025. But to whom does this regulation explicitly apply and what does it cover? Find out here!  

What exactly is EN 301 549?  

EN 301 549 stands for ‘Accessibility requirements for information and communication technology products and services’, which will be a standard in Germany from 28 June 2025. The aim of this standard is to make digital products and services – such as websites, apps, software, hardware and digital documents – accessible to people with different disabilities. The aim is to ensure that all users, regardless of physical, sensory or cognitive limitations, can access digital content and technologies without any problems.  

What topics does the new directive cover?  

Accessibility is a key aspect of digital services. Websites and apps should have intuitive navigation, e.g. sufficient contrast, full keyboard operability and be compatible with speech output. Documents and PDFs must be designed to be accessible, for example by providing alternative text for images. Hardware should also be inclusive, with tactile controls or voice control. Audiovisual content benefits from subtitles and image descriptions, while compatibility with assistive technologies such as reading programmes or tactile text lines is essential. This is the only way to ensure digital participation for all people.  

Who do these guidelines apply to?  

 The new guideline on accessibility in general applies to  

• Public bodies  
• Private companies   
• Public contracting authorities  
• Developers and designers  

Therefore the directive affects both public and private companies, especially those that offer digital content or services. The aim is to make the digital world accessible and usable for all people, regardless of their abilities.  

What are the consequences for breaches of the Directive?  

What happens if companies do not comply with them?  

Public bodies:  

• In the event of violations, those affected can submit a complaint.  
• In some countries, penalties or sanctions may be imposed.  

Private companies: 

• National authorities can impose fines for violations.  

What are the advantages and disadvantages of the new requirement for companies?  

Advantages of accessibility for companies:  

In addition to the legal obligation, digital accessibility brings many advantages:  

It creates a larger target group, as people with disabilities will then also have the opportunity to use software or apps digitally. Better usability also plays an important role. It ensures clear structures and good readability for all users. Another advantage is search engine optimisation, as accessible websites are often better optimised for search engines. Compliance with the legally prescribed rules creates legal certainty, allowing companies to avoid warnings and fines.   

Challenges for companies when implementing accessibility:  

A common problem when implementing accessibility is that many developers are unaware of the requirements. In addition, they often lack the time or financial resources to make accessible adaptations. It is also common for companies to have older software or websites that are difficult to customise.   

How is qnips dealing with the new regulation?  

We are already working on the requirements of EN 301 549, including support for screen readers, also known as screen readers. This means that for components of the user interface that contain labels with text or images, the name contains the visually displayed text. For qnips, for example, this means that any interaction areas or buttons (and their respective status) are also labelled with text and can therefore be better interpreted by screen readers. Let’s take an example: You have a checkbox in the app that you have to tick in order to perform an action. Now imagine you can’t see anything and only rely on your mobile phone to read out what you should see on the screen. Then this checkbox must contain the information where it is located, what it is for and whether the tick is already set or not.

All previously active digital applications have a grace period of 4-5 years for their implementation of the Accessibility Directive. All current qnips applications already fulfil the new requirements to a large extent. Digital applications that will only appear in the future must already fulfil the requirements. At qnips, the requirements are already covered by the redesign of the apps. Adjustments are still being made to our catering portals until the deadline.   

Responsibility for an accessible digital future  

EN 301 549 is central to an accessible digital society. It gives people with disabilities equal access to digital services – and at the same time improves usability for older people and many others. Compliance is mandatory for organisations in the EU and promotes an inclusive, non–discriminatory online world. We at qnips are already implementing this directive.