Success Factors for digital Accessibility Projects
If 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 pay more afterwards if in doubt.
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 additional loops are necessary.
From this point of view, you should express yourself as clearly and clearly as possible. Text module management can save time here. It's mostly the same things that you have to convey.- 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.
Is success guaranteed?
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.