Barriers to Digital Accessibility – Time Pressure

In this blog series, we explore the reasons why accessibility remains a challenge for many web development projects. In this article, we take a closer look at time pressure, or time as a bottleneck.

Time as a Barrier to Accessibility

Modern web development, despite its relatively young existence, already faces complex challenges. Like nearly all areas of computer science, this young discipline encounters unprecedented global demand. The resulting user base is unparalleled in its diversity. While other disciplines—such as medicine—have had millennia to evolve in manageable contexts with limited user groups, the “maturation phase” of web development feels like the blink of an eye.

However, this must not serve as an excuse to avoid doing everything necessary and possible to include the maximum number of willing users. UX designers and web developers, as gatekeepers of access, bear immense responsibility. Consciously or unconsciously, they often become gatekeepers of services, knowledge, or information in general. This effect is rarely intentional on the part of individual web developers or designers. We hardly know any developers or designers who dedicate multiple design sprints in every project to making their work harder to find, less clear, or outright confusing.

Time Pressure

One of the most significant bottlenecks—often referred to as a “chokepoint” in IT—is time pressure. Many readers will be all too familiar with this. At some point in project planning, no longer traceable to a specific individual or committee, it was decided that a project must be completed within a certain timeframe. This decision is then passed from the “management silo” to the “development silo” without much discussion. Now, the development team is under pressure to deliver within this predetermined timeframe—pushing anything deemed “unnecessary” to the back burner.

This often affects not only good design and thorough testing but also accessibility. Terms like “treated as an afterthought” come to mind—especially for those with a DevOps background. Accessibility, like many areas of continuous improvement, is seen as a bonus. There’s only time for the bonus once the “important” tasks are done or “the next release is out.” Experience shows that this moment comes maybe once a year, but then, unpredictably, all team members are on vacation, and unfortunately, nothing can be done.

It’s undeniable that manual testing—particularly for accessibility—requires time and expertise. First, a decision must be made about which set of guidelines will define the often vague concept of “accessibility.” Once that decision is made and approved, implementation can drag on significantly because insufficient time is typically allocated. It can take years to read, understand, apply, continuously review, and ideally integrate the over 70 success criteria of WCAG 2.1 into automated tests. The time for manual checks or regression testing isn’t even accounted for yet!

Lastly, implementing all these steps requires a certain level of specialized knowledge. This must first be trained and embedded in daily project routines. We estimate that it takes an average of 40 hours to retrofit a single website to comply with WCAG. Is this an exact number? No. But in our view, it’s not exaggerated either. We see this time investment as a barrier to accessibility that our work aims to address.

Conclusion

When accessibility is only addressed retroactively, it requires time, patience, and specialized knowledge. Additionally, convincing stakeholders to allocate time for this supposed “bonus topic” is often necessary. It must be clarified what exactly is required—and then how a clean implementation can look in the given context. This means for the responsible professional: reading guidelines, revising content, adjusting code, conducting tests—all while trying not to break the existing design. Often, the motivation, time, and knowledge are simply lacking. Even a competent and motivated individual is too often hindered by ever-present time pressure. The no-longer-traceable project plan takes precedence over altruistic values—and accessibility, if not considered from the start, must be patched up in painstakingly scraped-together time.

This highlights a fundamental problem with improvement: Those who strive for it often stand alone initially—and are “punished” with more work. In the case of accessibility, what was “forgotten” due to time pressure at the start costs motivated team members significant effort and time later.

Accesstra is intended to be a building block in tackling this unacceptable status quo.

Written by Georgia König
Accesstra Instructor