Why digital accessibility projects often fail and how to avoid this

Accessibility is a complex project. In my experience, however, there are three aspects in particular where accessibility projects mainly fail or go beyond the scope.

My customers can't hear it anymore: No matter what the topic, if you want or need to implement accessibility, you have to plan for it from the beginning. If you don't, you are responsible if a project fails or is significantly delayed. I like the image with the raisin cake. You don't bake the cake first and try to put the raisins in afterwards somehow.

Digital accessibility is often pirated down, which can cause the project to fail or drag out.

Qualify employees

Employees often don't see the need for accessibility measures. Because of this, they will implement many things sloppily. That's why training and awareness are necessary: Training so stakeholders know how to implement it, awareness so they know why they should implement it. There are now numerous offerings from free YouTube channels to sinfully expensive training packages, there will be something for your organization. The argument that it's too expensive is no longer acceptable with the wide variety of offerings.

Another important reason for failure is the lack of interest on the part of managers. This ranges from the responsible project manager to the executive board. Experience shows that the lack of interest, actively or passively displayed, also reduces interest in implementation among those involved.

Clear briefings

This is another thing my clients can't hear anymore, but we need clear briefings. "Make it accessible" is as helpful as "Live healthy." Especially for inexperienced service providers, clear requirements and frameworks are important. For internal editors, for example, instructions also need to be provided. The customer does not have to be an expert, but he must either define exactly what he wants or be aware of his lack of expertise and let us advise him - as a paid service, of course. And he must also be prepared to implement these recommendations or take responsibility if he doesn't.

When I recap, most accessibility measures fail or are delayed because of the three factors mentioned above. It's so complicated because you make it too hard on yourself.

In the end, it's a question of the right or wrong framing: Many persons in charge still look at accessibility from a charity perspective - you can do it, but you can also let it be. Instead, it should be seen as an added value for everyone and a quality feature.

Key Success Factors

When you work in digital accessibility for any length of time, you feel like a parrot. This is because you have to tell the same thing over and over again - sometimes even to the same person.

I know both perspectives: On the one hand, I was a freelance service provider for a long time, and on the other hand, I was also responsible for digital accessibility management for some customers. I have been working for agencies as a service provider for almost four years. The perspectives and approaches may differ, but essentially it is relatively similar.

Of course, as a service provider you are initially interested in generating as many creditable hours as possible. In my opinion, this is not always intended to be productive: the customer always has the choice to replace their service provider if they have the impression that they are not working efficiently. So it's not a good idea to muddle something together first and then worry about accessibility at some point.

Conversely, the customer should note that correctly implementing accessibility is more of a marathon than a sprint. If you choose the cheapest provider, you will perhaps pay twice afterwards if.

Here I would like to summarize what I believe are the key success factors. The steps are deliberately not put in a specific order here.

Design/conception

Some aspects must be taken into account during the design and conception of a product: These are primarily colors, contrasts and visual indicators. Basically there are a few aspects that are neglected in every project that I have had to do with.

On the customer side, it makes sense to include these aspects in the corporate design. If this is not possible or desired, you have to define special CD rules for the digital area.

From the service provider side you can work with acceptance criteria. These criteria define the minimum requirements for all UI components. An example: A link must 1. have a contrast of at least 4.5:1 or 3:1 to the background at every stage (visited, unvisited, focused, etc.

On the customer side, it makes sense to build your own component library if possible if you have numerous digital products. This can also make sense for the service provider, although of course it has to be more flexible because it has to be adapted to each customer, for example when it comes to color schemes.

Development

Such a library is also helpful for developers. A lot depends on whether you are a small agency. Small agencies have a limited set of libraries and CM systems in which they specialize. Then it makes sense to adapt the libraries so that they meet accessibility requirements. In the medium term, however, it should be almost easier to create your own reusable components that are accessible. While frameworks need regular updates, large parts of HTML, CSS and JavaScript could still be used today without any problems.

However, it is essential for large service providers to introduce rules for the use of libraries. If a library always produces a certain problem with a certain component, it should be fixed so that it no longer occurs. Of course, it would be best to let the library provider fix the problem, but I don't know how complex such processes are.

Automation and standardization

Whatever can be reasonably automated should be automated at the earliest possible point. One possibility, for example, is the Ax Figma plugin. Even in development, using these tools is no longer an option, but a must.

There is generally nothing wrong with generative technologies like Microsoft's Copilot. It saves a bit of time for the developers. However, that doesn't mean that such code should be adopted uncritically - that never actually applies to generative tools.

Last but not least, there is nothing wrong with automated tests, on the contrary. According to a study by Deque, around 2/3 of problems can be detected automatically. If these two thirds are detected or avoided at an early stage, then we are already one step further.

Annotations

Tools for commenting on accessibility issues also seem to have exploded in recent years. But annotations should always be the second or third step. You're probably familiar with this: correcting a text full of spelling errors takes significantly more time than correcting one with just a few. In the best case, only a few comments should be necessary because design and development worked properly.

Efficient communication

While code can be standardized, this is less true for language. The Terster doesn't want to write novels, the developer doesn't want to read them. So you try to be as brief as possible, but this can lead to you being misunderstood or not understood. In the end, no time was saved because further loops are necessary.

From this point of view, you should express yourself as clearly as possible. Text module management can save time here. It's mostly the same things that have to be conveyed.

Description of the problem
Desired behavior
possible solution

In general, I noticed that communication is often not organized efficiently. What is meant is project-oriented communication; communication for relationship maintenance is a different topic. Hundreds of hours could be saved if people worked properly here. Perhaps strict standards and a clear vocabulary will help here.

It is also rather tragicomic for accessibility experts when they train people or present test reports and in the next test the exact same mistakes are often made by the same people.

Language is not perfect and misunderstandings can always occur. But sometimes it seems to be because people just don't want to or can't really participate.

Agile project management

The agile project approach has become established in software development and can also have a positive effect on accessibility. Can, but doesn't have to. My experience here is not only positive.

Here, too, the problem can be that the accessibility experts are involved very late in the development cycle.

Is success guaranteed with this?

If we take these factors into account, is success guaranteed? Unfortunately no, no reputable person will give you a guarantee of success for IT projects, at least not without further ado. But if a few essential factors are taken into account, you reduce the overhead that comes from not taking them into account.