Digital Accessibility in Practice: How menio and its customers implement accessibility

At menio, we don’t view accessibility as an additional feature, but as an integral part of our product development. We began integrating accessibility criteria into our platforms systematically at a very early stage. Find out here which guidelines of the new law fall under menio’s responsibility:

1. Perceptibility: Digital content must be perceivable through all the senses – regardless of whether a person can see, hear, or use other senses.
2. Usability: All functions of a website or app must be usable – even without a mouse or for users with motor impairments.
3. Comprehensibility: The content and user interface must be understandable to all user groups – including those with cognitive impairments or limited language skills.
4. Robustness: In the context of accessibility, this refers to the ability of content to be reliably interpreted by various user agents (such as browsers or assistive technologies) – even as technologies continue to evolve.

The numbers listed before each guideline correspond to the official reference numbers of the respective WCAG success criteria. This allows the requirements listed to be clearly identified and looked up as needed.

• Essential instructions must not be operable solely through sensory perception (1.3.3)

Example: Instructions such as “Click the red button” are problematic because they refer only to color. An accessible alternative would be: “Click the red button labeled ‘Next.’”

• The purpose and requirements 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 their volume must be adjustable independently of the system's default volume (1.4.2)
• If necessary, the text size can be increased up to 200% without affecting functionality (1.4.4)
• Text is formatted to fit within the display so that scrolling is required in only one direction at most (1.4.10)
• Text or characters must not be restricted in terms of either content or function if certain text parameters – such as line spacing – are changed via program code (1.4.12)

Example: A user changes the line and paragraph spacing in their browser to make the content easier to read. The menio page adapts seamlessly: Text remains fully visible, and features such as “Order” or “Save Dish” continue to work. Content does not overlap, and nothing is cut off – this is how menio 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)

• All features of a website or app must be fully operable using only 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 to that location in the same way (2.1.2)
• Software-specific commands accessed via keyboard shortcuts must be able to be disabled or customized (2.1.4)
• For time limits, such as countdowns, there are advance warnings and the option to extend the time limit, unless these time limits are linked to unchangeable or externally determined events (2.2.1)
• Automatic moving, flashing, and scrolling elements must be pausable or turnable off (2.2.2)
• It must be possible to skip repetitive content (2.4.1)
• Websites have a title that describes the topic and/or content (2.4.2)
• Website elements should be navigable in the same order in which they are arranged on the page, both visually and in terms of content (2.4.3)
• The text of a link must clearly describe the purpose of the link (2.4.4)
• It must be possible to navigate to a website's subpages independently of the home page (2.4.5)

Example: In the menio Catering Portal, you can access any subpage – such as the menu, the order summary, or the allergy information—directly, without having to go through the home page first. This is especially helpful for people who use screen readers or voice control, because they can jump directly to the page they want to visit.

• When navigating a website using the keyboard, it must always be clear which element is currently active – for example, by means of a visible border. People who use screen readers must also be able to hear where the focus is. Actions should also be possible via the keyboard or voice commands – that is, without a mouse (2.4.7)
• The user should be provided with information about the website's current status (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 that particular gesture is absolutely necessary (2.5.1)
• A "Delete" button should not respond immediately when clicked, but only when the button is released – this way, you can still cancel the action if you made a typo (2.5.2)
• The text content of a single text or a text presented in images must also be stored in the program code (2.5.3)
• If operating the device requires physical movement (e.g., shaking or tilting it), there should also be an alternative way to operate it using buttons or menus – unless the movement is necessary or specifically intended to ensure accessibility (2.5.4)

• The program 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 recognize this so that, for example, screen readers can read it aloud correctly. Exceptions include proper nouns, technical terms, or specialized jargon (3.1.2)
• When the focus is moved to a dropdown menu, for example, using the keyboard or mouse, it must be possible to exit the dropdown easily – for example, by pressing “Escape” – thereby 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 of what is changing and to what extent (3.2.2)
• It is important that the menu layout always looks the same on every page and is always located in the same place. This helps all visitors navigate the site more easily (3.2.3)

Example: Imagine you are visually impaired and you visit a website where you find the menu in the upper right corner. You click through various pages – but suddenly the menu has disappeared or moved to a different location. You have to start searching again and lose your bearings. To prevent exactly that from happening, consistent menu navigation is crucial: If the menu looks the same on every page and always stays in the same place, you’ll find your way around more easily and can use the website without stress.

• If an element on a website serves the same purpose (e.g., a submit button), it must always look and function the same way. This helps everyone navigate the site 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 clear, readable text (3.3.1)

Example: An employee wants to pre-order lunch through the menio Catering Portal. She enters her name and the desired meal correctly in the form, but forgets to include her email address – a required 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 highlighted with a red border, so the error is immediately visible. The form automatically places the keyboard focus on the field containing the error. In addition, the error message is formatted so that it is read aloud by screen readers.

• If users are asked to enter information, such as their name or email address, the fields must be clearly labeled or include brief instructions on what is expected (3.3.2)
• If an error is detected and it is clear how to correct it, the website should assist the user in doing so – for example, by displaying a message. Unless doing so would reveal sensitive data that could be viewed by multiple people, such as on a publicly accessible display (3.3.3)
• When entering important data – such as for purchases or contracts – the user must be able to correct errors and/or review all of their entries before submitting them and/or cancel data that has already been submitted (3.3.4)

• In the program 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 permit these characteristics (4.1.1)
• Controls must be understandable to assistive software. Therefore, the program code must clearly identify the name, role, state, and changes for each control (4.1.2)

Example: To ensure that people using assistive technologies, such as screen readers, can use menio effectively, the code specifies for each button or selection field exactly what it is, what it’s called, and whether it’s currently active. For example, when you click the “Order Now” button, you’ll hear that it’s a button and whether the order has been received. This way, all users know exactly what’s happening on the page.

• Status messages for elements must be detectable by assistive technology without the user having to actively trigger them (4.1.3)

menio provides the technical foundation for accessible use. Our customers are also independently responsible for ensuring accessibility. They must take accessibility into account and integrate it into their daily tasks and work routines.

• Alternative text must be provided for images that the customer manages themselves via the content description (1.1.1)
• Videos must include either captions or text alternatives. This means either providing a video with embedded or optional captions or – if a video is not necessary – offering the same content in text form that can be read aloud by screen readers (1.2.1 through 1.2.5).
• Videos with audio must include captions, unless the audio itself is already an accessible alternative to text (1.2.2)
• As an alternative to audio and video media, there are documents or audio description (1.2.3)
• Recorded videos offer audio description (1.2.5)
• Information must not be conveyed solely through color. At least one explanatory text is required. (E.g., a traffic-light system) (1.4.1)
• For images that contain text, the contrast ratio must be at least 4.5:1. A lower ratio of 3:1 is permitted only if the text is at least 18pt in size or 14pt in bold. Purely decorative images and text, as well as logos, are exempt from this rule (1.4.3)
• It is better to use readable, actual text rather than text embedded 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 recognizable and have a color contrast ratio of at least 3:1 with their surroundings – unless they are inactive, have been colored by the user, or must be used in that specific color scheme (1.4.11)

• Visual effects that flash rapidly or involve intense color changes must be designed so that they do not flash more than three times per second and do not contain sharp contrast 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 indicate what will happen or what should be entered. This helps all users find what they’re looking for more quickly and use interactive elements correctly (2.4.6)

Here is a checklist that outlines, at a glance, all the items for which you are responsible to ensure an accessible implementation: Checklist

You, too, can help make the content on your platform accessible with just a few tools. These three free resources are particularly helpful:

1. W3C Decision-Making Guide for Alt Text
Alt text makes image content accessible to people who use screen readers. The W3C’s decision-making guide uses simple questions to determine whether an image needs a description and what information it should include. For a photo of a dish, for example, the dish shown can be named, while purely decorative images do not require descriptive alt text.
Go to the W3C Decision Guide

2. WebAIM Contrast Checker
With the Contrast Checker, you can check whether text and background colors contrast sufficiently with each other. To do this, simply enter the respective color values. The tool immediately shows whether the combination meets WCAG requirements. This is helpful, for example, when you design promotional messages, menus, or banners using your own colors.
Go to the WebAIM Contrast Checker

3. WAVE Accessibility Checker
WAVE checks a website for common accessibility barriers and highlights potential issues directly on the page. Among other things, this allows you to identify whether alt text is missing, color contrasts are insufficient, or the content structure is unclear. The tool provides an initial overview but does not replace a thorough manual review.
Go to the WAVE Accessibility Checker

This makes it possible to identify and avoid many potential barriers as early as the content creation and maintenance stages.

Accessibility is more than a legal obligation  – it is an expression of respect and sustainability. It demands – and it fosters: innovation, user-centered design and social responsibility. Here at menio, are on this journey together with our clients—through consulting, technological solutions, and collaboration based on partnership.