The biggest blockers of digital Accessibility

In this article we will discuss change management in the context of digital accessibility and why it matters. Change management involves restructuring an organization so it can better handle new tasks. This is particularly important for accessibility, as the biggest hurdles are usually organizational rather than technical.

Initial Premises

Technical issues are rarely true blockers. Arguments like "Our technology doesn't support that" or "That’s hard-coded" no longer hold water. Modern technology stacks are not monolithic; they are constantly evolving. Anyone unable to cope with this constant change shouldn't be releasing software.

The same applies to regulatory requirements. You don’t have to like laws like the GDPR or accessibility mandates, but you still have to implement them.

It is often claimed that systemic reasons prevent digitalization or accessibility. This is frequently just a pretext. When a government cites systemic reasons, it forgets that it is part of the system itself and has the power to change it. This applies even more to companies. If an organization claims it cannot change its structures due to old habits, it is simply inflexible. In such cases, accessibility is usually just one of many problems.

Let's look at specific structural roadblocks—and how to overcome them.

Blocker: "This doesn't affect our customers"

In e-commerce, a notion persists among decision-makers that few voice out loud: "Blind people don't use computers. And even if they did, they wouldn't buy our products." For instance, there is an assumption that blind people do not buy brand-name running shoes.

The European Accessibility Act (implemented in Germany as the BFSG) now legally mandates accessibility in e-commerce. This reduces the need for debate, yet the work of persuasion remains crucial.

- Sharing knowledge: Even highly educated people often do not realize that blind individuals or those with paraplegia use computers. - Expanding target audiences: Many people are not tech-savvy or find complex online shops overwhelming as they age. Yet, older adults represent a hugely important target audience for online shopping.

- Making technology tangible: A playful approach helps. Have decision-makers test a screen reader on their own smartphones; it sparks fascination and fosters understanding.

- Establishing a personal connection: Many decision-makers are in their 30s or 40s. Their parents or grandparents often have vision impairments or struggle with modern interfaces. Showing them a smartphone’s accessibility features creates a bridge to their own families.

The key question for decision-makers is: "Do you want your own grandparents or parents to be able to use the online shop you built? Or does it not matter to you?"

Ultimately, digital accessibility is a matter of empathy. Everyone should, in principle, have the opportunity to participate—regardless of whether they actually end up buying those running shoes.

A strong awareness of the target audience's challenges and needs often ignites the team's ambition. Many developers and designers want as many people as possible to be able to use their applications. This empathetic approach usually works well in e-commerce. Watching people with disabilities use—or struggle to use—an application serves as a real eye-opener.

In online banking, decision-makers often think differently. The empathy argument rarely resonates here; instead, the legal argument takes precedence. Strict statutory requirements in the banking sector compel decision-makers to ensure compliance, even if they do not personally see the value in it. Nevertheless, raising awareness remains worthwhile in this context, too.

Roadblock: Accessibility as a "low priority" at the end of a project

A common phenomenon: accessibility is relegated to the end of the project as a trivial issue. The product is finished, the launch is scheduled for next week, and only then is accessibility checked. The result is usually a list of 50 issues. Remedying them blows past any schedule. However, since accessibility is a legal requirement, the launch is significantly delayed. Unfortunately, this happens even in organizations that really ought to know better.

Accessibility must be structurally embedded. It needs to be firmly integrated into design and development pipelines:

- Design pipelines: Anchor fixed criteria within design libraries and style guides.

- Developer pipelines: Integrate accessibility requirements into developer libraries.

- Automation: Incorporate automated accessibility tests directly into the CI/CD pipeline. This catches the majority of errors proactively.

- Exchange: Establish regular consultations with accessibility experts.

Another prioritization problem arises from the urge for new features. New features are constantly being added. As a result, the topic of accessibility is slipping further and further back on the roadmap.

This often applies to externally purchased third-party solutions, such as:

- Video players and streaming tools

- Chatbots

- Iframes for payment solutions

These tools are important, but must necessarily be barrier-free. Accessibility is not an optional layer (like an overlay) that you just slap on top of the product at the end.

If we integrate accessibility early in the pipeline, build skills and rigorously vet third-party solutions, the problem is almost solved. In the end, however, a clear quality gate is needed: If a new feature is not accessible - or at least the automatic check fails - the publication is blocked. The release will only go live once accessibility has been improved.

Blocker lack of competence

Lack of knowledge is currently one of the biggest blockers. We cannot solve this problem in the short term, but we can address it specifically. It makes sense to have accessibility experts on your team. But that is not enough. We need role-specific qualifications. A lot of resistance to accessibility comes from a lack of implementation knowledge. In this respect, the transfer of knowledge is also empowerment.

- Designers need to know how accessible design works.

- Developers need to know how to write accessible code.

Nobody has to become an all-knowing expert on their own. But every person should be qualified in their own area of expertise so that they can think about and implement accessibility from the start. This saves time and frustration.

h2>Blocker Why do we have to do this

It's understandable that many stakeholders find the issue of accessibility frustrating. It's just complex. However, this frustration can be specifically reduced by not only creating skills, but also explaining the “why”. Many accessibility requirements are not understandable on their own.

It is not enough to say: “This is the law, we have to do it this way.” It is better to show the specific impact.

Practical tip for Jira tickets and test reports: Always add the effect to error descriptions:

• “If you implement this feature in a barrier-free manner, it will have this positive impact…”

• “If we leave it like this, it will have this concrete negative consequence for the users...”

When developers and designers understand why a feature is important, it awakens their understanding. And it helps them do it right next time.

Block creativity

A common argument is: “Accessibility limits my design freedom and creativity.” Developers like to build cool, customized features. A standard checkbox or a classic HTML input field quickly becomes boring.

However, this is a false conclusion that often arises from the blind use of modern frameworks and ready-made design libraries. The fact is: HTML5 and CSS3 today offer countless opportunities to design standard elements in a comprehensive and modern way. To do this, however, you have to know the basics. You can expect professionals not only to copy the checkbox from Bootstrap, but also to master the web basics.

10 to 15 years ago, these overloaded frameworks didn't even exist. We still built attractive surfaces without compromising the design. There needs to be a real rethink here: away from bloated legacy code or convenience, back to clean, native code.

The argument that development with native HTML and CSS takes longer is often objectively wrong. If you use a complex framework, you first have to familiarize yourself with it, master its specialties and then laboriously think about how to make the construct somehow barrier-free. Styling a clean HTML element with CSS is often faster and more sustainable.

In addition, larger organizations today work with component libraries anyway. This means: An accessible checkbox only needs to be built correctly once.

It can then be used again and again throughout the system.