Accessible design in practice
Accessibility in web design goes far beyond aesthetic aspects. The main goal is to create digital experiences that are accessible and usable for all people - regardless of their abilities or limitations. This article highlights the key factors of accessible design and provides deeper insights into how we consider and implement accessibility in real client projects.
Where does the requirement come from?
Although accessibility must be taken into account to a certain extent in all of our customer projects, compliance with international standards such as WCAG2.2 AA or AAA is not always desired or simply not part of the project budget and scope.
In general, a trend can be observed in which more and more of our customers are approaching us with this requirement. This development is being driven by various factors:
- Legal obligations: Public institutions and companies that take part in public tenders are already legally obliged to provide accessibility.
- The German Barrierefreiheitsstärkungsgesetz (BFSG): From 2025, the Barrierefreiheitsstärkungsgesetz will come into force, which will further tighten the accessibility requirements for websites and apps for a large number of companies and organizations in Germany.
- Improving usability for everyone: Accessible design not only benefits people with disabilities, but also improves the user experience for everyone. A well-structured, easy-to-navigate and understandable website is beneficial for all visitors.
Accessibility and corporate identity
In many of our projects, a visual corporate identity (CI) already exists on the client side before the start of the project, which we use as the basis for the design of the future website. These CIs are not always designed to take accessibility into account, but sometimes focus exclusively on strengthening the company's brand image.
Often, these CIs are implemented by design agencies that are very good at combining visually appealing colors in combination with shape and fonts to develop the logo and the associated brand image. Designers don't like to limit themselves in order to be able to work creatively. The results are usually very appealing color palettes, logos and fonts that can be printed on numerous advertising spaces, letterheads and textiles.
Unfortunately, the use case for the web and accessibility in particular is often neglected.
Whats missing?
Many corporate identities have limited color palettes that focus on picking up the primary and secondary brand colors. Neutral shades, which are part of every design, are either not considered or only added in the form of individual shades. This often results in a color palette that limits design possibilities and makes it almost impossible to provide sufficient contrast.
Limited color palette
With the color palette shown, trained eyes can see this at first glance: The primary and secondary colors are extremely bright and cannot be placed on a white/bright background with sufficient contrast. In fact, only the display on a dark background is possible if the color contrast is to be sufficient for WCAG level AA.
Adding new colors
It is not always possible to simply define a new secondary color or change the existing colors of the brand. In addition, although the solution with the new secondary color offers us a good display for light and dark backgrounds, it is not possible to combine the primary and secondary buttons, as one of these buttons does not meet the requirements for contrast.
Combining button style and color sensibly
This proposal uses neutral tones to create sufficient contrast between the text and the button background. In addition, different button styles are sensibly combined with the CI colors to enable button groupings with hierarchy.
It always depends on the individual application and the required flexibility of the system. There is no perfect solution, but with the right approach, barriers can be effectively removed.
Retrofitting accessibility
We are not commissioned to set up websites from scratch for all of our projects. Often enough, clients commission us to adapt and expand individual modules in order to ensure the accessibility of the entire site.
In fact, this case is much more complex, as fundamental changes to the system are certainly possible if they are necessary to ensure accessibility, but the actual appearance of the site should only change minimally.
Check accessibility
Checking existing pages for accessibility can be a lengthy process in which all the necessary criteria have to be checked against the current system. In any case, the scope exceeds the pure design and a little technical expertise is essential.
This begins with the correct operation of the screen reader and keyboard navigation, through the inspection of individual elements with the browser's own dev tools for set labels, to the analysis of the correct semantic sequence of the heading hierarchy.
All these things and much more need to be checked before solutions can be found for those areas that stand in the way of accessibility requirements. There are a variety of plugins, tools and checklists that can be used before and after implementation to check the criteria. Here are some examples:
- A11Y Project Checklist
- Stark Figma Plugin
- Silktide Browser Extension
- Wave Extension
- Simulation of color blindness
- Automated tests (visual regression, semantic sequence, contrasts)
- Real user monitoring and testing
However, you should not rely on the tools without reflection, as the tools cannot detect all barriers that individual users may encounter. If possible, the experiences of real users should always be used, especially those of people who depend on the accessibility of the systems.
After checking
Once individual problem areas of the system have been identified, low-barrier solutions must now be designed to eliminate the problems. Close cooperation between design and development is essential here, as most solutions go beyond pure visual design and both disciplines can benefit from each other's expertise.
The most important step in ensuring accessibility does not end with the technical implementation and provision of the system, but initiates the next phase for another stakeholder who is needed to enable an accessible web presence.
Editorial responsibility
No matter how well a system is conceived, designed and implemented, it can still fail miserably to meet the accessibility criteria of WCAG 2.2. This is because it is not only the system that is important, but also the content that is displayed and presented via the system.