Bored sloth, at their computer rendered in half-tone. Dark gray over a field of red.

Divider

In the digital accessibility industry, a pervasive narrative persists: "If only developers cared more about accessibility...". But this narrative is unfair, and it misrepresents the real problem. Accessibility failures are rarely about individual laziness; they stem from systemic organizational shortcomings. This article examines why blaming developers is counterproductive and proposes a holistic approach to improving digital accessibility across organizations.

## The Agile Illusion: Scrumfall? Wagile?

<div style="text-align: center">![Ron Burgundy - By "agile" you mean "waterfall in sprints"?](https://preview--jasonbday-f2e75.stackbit.dev/_static/app-assets/public/images/sprints.webp)</div>

Many tech companies tout their agile methodologies such as daily stand-ups, sprint planning, iterative design - it all sounds great, but the reality often feels like waterfall projects timeboxed to two-week sprints. This "Scrumfall" approach combines the sequential phases of waterfall with the time constraints of Scrum, without embracing true agile collaboration. We're still in linear product development, with engineers at the end of the process. This approach leads to compressed timelines, more bureaucracy, and lack of collaboration, where it's easy to point the finger at the last person to touch the product when things go wrong.

When it comes to accessibility, these "Wagile" processes break down even further. Product requirements may include vague accessibility stories like "As a user, I want WCAG 2.1 AA compliance." Designs may be finalized without accessibility annotations or clear communication of intent.

Imagine being a developer in this scenario. You're the last link in a chain where accessibility was an afterthought or wasn't properly planned for, and now, you're tasked with retrofitting accessibility into a nearly complete product.

What appears as "resistance" or "laziness" is often just the inevitable result of a broken process.

## Collective Responsibility: Setting the Stage for Systemic Solutions

While developers often bear the brunt of accessibility criticisms, it's crucial to understand that accessibility shortfalls occur across the entire product development lifecycle. According to research from DeQue, a staggering [67% of accessibility defects originate in the design phase](https://www.deque.com/blog/is-closing-the-web-accessibility-design-development-gap-a-bridge-too-far/#:~:text=But%2067%25%20of%20accessibility%20issues,do%20we%20cross%20that%20chasm?) - long before developers write a single line of code.

<figure>
<img src="/images/Picture1-10.png" alt="DeQue chart, showing software development lifecycle, indicating 67% of accessibility defects originate in design."/>
<figcaption>DeQue case study indicating that the bulk of accessibility defects originate in design.</figcaption>
</figure>

To truly understand the accessibility challenge, we must acknowledge the role-specific failures that contribute to systemic barriers:

*   **Incomplete User Stories:** A product manager may write a user story like "As a user, I want to filter results," with no mention of keyboard navigation or screen reader compatibility. Accessibility may not be included as a core and specific requirement.

*   **Design Gaps:** A designer might create a visually appealing custom dropdown but overlook essential accessibility features like focus states and ARIA attributes. Accessibility is not consistently factored into the design process.

*   **Developer Guesswork:** Consequently, developers are left to guess about accessibility requirements. Should the dropdown announce selections? Should filter actions trigger screen reader notifications? This inconsistency forces developers into a no-win situation.

The cumulative result is a product that excludes users with disabilities.

As accessibility specialists, we often say, "accessibility is a team effort." This means we must move beyond individual blame and recognize that accessibility failures are often systemic, requiring collective solutions. By understanding how each role contributes to the problem, we can begin to implement the strategic interventions needed to transform our approach to accessibility.

### Shifting from Reactive to Proactive Approaches

Most organizations remain frustratingly reactive when addressing accessibility, identifying and fixing issues only after development is underway, or worse, after product launch. The cost of this reactive approach is significant. What might have been a simple design adjustment becomes an expensive, time-consuming retrofit. Read Karl Grove's [Understanding the cost of not being accessible](https://karlgroves.com/understanding-the-cost-of-not-being-accessible/), which takes a stab at breaking down the costs and ROI of accessibility.

A strategic approach involves integrating accessibility expertise throughout the entire development lifecycle, from leadership decisioning to implementation. Organizations that prioritize accessibility establish consistent practices across all roles, with accessibility experts guiding the process:

*   **Explicit Accessibility Requirements:** Product managers should embed accessibility requirements directly into user stories, such as: "As a keyboard-only user, I need to navigate through search filters using standard keyboard controls" or "As a screen reader user, I need to be notified when search results update."

*   **Comprehensive Design Specifications:** Designers should provide detailed specifications that communicate intent and consistently include focus states, content structure, ARIA roles, expected screen reader announcements, and keyboard interaction patterns.

*   **Strategic Knowledge Dissemination:** Rather than focusing solely on developer training, accessibility knowledge should be strategically distributed throughout the organization. This means providing specialized guidance tailored to each role's needs, empowering everyone to contribute to inclusive outcomes.

*   **Incentive Alignment:** Working with leadership, accessibility experts can help ensure that accessibility achievements are recognized and rewarded with the same enthusiasm as other technical accomplishments. This means incorporating accessibility metrics into performance reviews and celebrating successes across the organization.

When accessibility considerations are consistently integrated at every stage of development, and when accessibility experts act as allies and strategic partners rather than solely as "reviewers", organizations can effectively transform the "lazy developer" narrative into one of shared responsibility and collective success. This proactive approach drives lasting cultural change, making accessibility a core value and not an afterthought.

### Tackling the whole problem

Implementing collective responsibility when we encounter an accessibility issue, rather than asking "why didn't the developer fix this?", we should examine the entire process that produced the failure.

Consider a common accessibility issue: a heading that isn't properly marked up in HTML. Instead of placing blame, trace the journey:

*   **Process Examination:** Was the heading structure clearly documented in requirements? Did designers annotate their mockups to indicate heading levels? Was there a design walkthrough where this was discussed?

*   **Knowledge Assessment:** Do team members across disciplines understand why proper heading structure matters? Does everyone have access to accessibility guidelines and training?

*   **Procedural Integration:** Does the Definition of Ready include accessibility requirements? Does the Definition of Done include accessibility testing? Are there checkpoints throughout development where accessibility is verified?

*   **Cultural Evaluation:** Does leadership emphasize the importance of accessibility? Is time explicitly allocated for accessibility implementation?

When a component fails accessibility testing, the problem rarely begins and ends with developer implementation. By examining these broader questions, we can identify systemic breakdowns and address the root causes rather than symptoms.

### Moving Forward: From Blame to Collaboration

Shifting our perspective from blame to collaboration isn't just a mindset shift, but the key to lasting accessibility change. Organizations must move beyond pointing fingers and start integrating accessibility into every phase of development. The question isn't "Why didn't the developer fix this?" but rather, "How can we prevent these failures in the first place?"

When organizations embrace collective responsibility for accessibility, they not only create more inclusive products but also improve their overall development processes in several key ways:

*   **Increased team knowledge:** When accessibility becomes everyone's responsibility, team members naturally develop a broader understanding of inclusive design principles that benefit all aspects of product development.

*   **Faster problem-solving:** As accessibility knowledge spreads throughout the team, identifying and fixing issues becomes more efficient. Problems that once required specialist intervention can be addressed directly by team members who encounter them.

*   **Enhanced collaboration:** A shared commitment to accessibility naturally fosters better communication and teamwork across disciplines, breaking down the silos that often lead to accessibility failures in the first place.

The path to truly accessible products begins by dismantling the "lazy developer" myth and cultivating a culture of collective responsibility. Because when accessibility becomes everyone's responsibility, we transform not just our products, but our entire approach to digital innovation and inclusion.


The Accessibility Blame Game: The Fallacy of the "Lazy Developer"

Broken robot, smoking and electricity sparking, saying "install me"

a broken robot, badged with the universal design logo, electricity crackling and smoke rising from it saying 'install me'

Good evening, and welcome to Masterpiece Digital Theater. Tonight we present a compelling drama that explores the world of digital accessibility - or rather, its charlatan counterfeits.

"Accessibility Theater: The Cautionary Tale of Overlays" takes us into the modern boardrooms and living rooms where the drama of digital inclusion, or exclusion, plays out daily. Our story examines how not-so-well intentioned solutions can become mere performance, a facade of accessibility that ultimately fails those it claims to serve.

A play in three acts...

## Characters

*   WEBSITE OWNER: A well-meaning but uninformed business owner

*   OVERLAY VENDOR: A smooth-talking sales rep

*   ANGELA: A blind screen reader user

*   MARCUS: A web developer with accessibility expertise

*   CHORUS OF USERS: Various people with disabilities

*   THE GHOST OF ACCESSIBILITY PAST: A spectral figure representing early web accessibility efforts

*   WIDGET: A personified accessibility overlay widget

## Act I: The Promise

*Scene: A modern office. WEBSITE OWNER sits at their desk, looking worried over their desk*

WEBSITE OWNER: *(reviewing papers)* These accessibility requirements... the lawsuits... the costs... What am I supposed to do?

*( OVERLAY VENDOR appears in a cloud of smoke wearing a flashy suit with a glowing "Install Now" button as a tie pin)*

OVERLAY VENDOR: Did someone say accessibility? Fear not! With just one line of code, I can make all your problems disappear!

WEBSITE OWNER: One line of code? That sounds too good to be true!

OVERLAY VENDOR: *(grandly)* Watch this! *(waves a wand)* This little beauty, powered by cutting-edge AI, fixes everything. Fonts, contrast, screen reader compatibility – you name it!

*\[A glowing widget appears on the stage]*

WIDGET: *(mechanical voice)* I can change fonts! Adjust contrast! Read text aloud! I am the future of accessibility!

WEBSITE OWNER: Does this really work?

OVERLAY VENDOR: Trust me. Automation is the future! Why waste time and money when you can have instant results?

## Act II: The Reality

*Scene: A small office. ANGELA sits at her computer, trying to use the website.*

ANGELA: *(frustrated)* Ugh, another one of these things? “This site is now accessible!” Yeah, right. I can’t even find the damn menu. My screen reader’s going haywire.

CHORUS OF USERS: *(entering from all sides, voices overlapping)* “I already have my own tools!”**,** “This widget’s blocking everything!”, “It’s making things worse!”, “And it's tracking my data?”

*\[WIDGET starts glitching]*

WIDGET: *(stuttering)* Detecting... detecting... user preferences... Would you like to... Would you like to... Would you like to...

*(Enter THE GHOST OF ACCESSIBILITY PAST)*

GHOST: Remember when we said accessibility should be built in, not bolted on? When we wrote the WCAG guidelines way back in 1999? When we emphasized user testing? Remember...?

## Act III: The Awakening

*Scene: Back in WEBSITE OWNER's office. WEBSITE OWNER is meeting with MARCUS.*

MARCUS: The overlay can't fix most issues. It can't reliably repair:

*   Image descriptions

*   Form labels

*   Keyboard navigation

*   Complex interactive components

*   PDFs, documents, or media files

WEBSITE OWNER: But the vendor promised compliance!

*\[CHORUS OF USERS returns, each holding up their phones and laptops]*

CHORUS OF USERS: "We've started blocking these overlays!" "They collect our disability status without consent!" "They slow down pages!" "They break the tools we use!"

WEBSITE OWNER: *(to OVERLAY VENDOR)* You promised a solution, but it's all theater – a mere illusion of accessibility!

OVERLAY VENDOR: *(backing away)* But our AI... our automation... our one line of code...

MARCUS: Real accessibility takes work. Human work. Good design, proper coding, and actual user testing. There are no shortcuts.

## Epilogue

*\[All characters face the audience]*

ANGELA: True accessibility inclusion doesn’t come from an overlay.

MARCUS: It's a fundamental right.

WEBSITE OWNER: *(removing the overlay code)* We have to do this the right way.

CHORUS OF USERS: *(together)* No more theater. No more overlays. Just thoughtful, accessible design.

\[End]

Get more info at [overlayfactsheet.com](https://overlayfactsheet.com/)


Accessibility Theater: The Cautionary Tale of Overlays

three hurdles standing in the way of the flag/object

Three hurdles standing in the way of the flag, or objective

In an increasingly digital world, web accessibility isn't just a nice-to-have, it's a necessity. For six consecutive years, WebAIM, a non-profit with a focus on digital accessibility, has conducted comprehensive evaluations of the top one million websites' home pages. Their [2024 WebAIM Million Project](https://webaim.org/projects/million/) report paints a concerning picture of the current state of web accessibility, while also offering valuable insights into potential improvements.

Note: WebAIM typically publishes the report in February or March, so we should be able to view the 2025 results soon. For the sake of this article, I am using the 2024 report.

## The Current Landscape

The numbers are stark: across one million home pages, researchers detected over 56.7 million distinct accessibility errors—averaging 56.8 errors per homepage. More troubling still, this represents a 13.6% increase from 2023. When we consider that automated testing can only detect approximately 40% of potential Web Content Accessibility Guidelines (WCAG) conformance failures, the actual number of barriers faced by users with disabilities is likely significantly higher.

## The Most Common Barriers

While the scope of accessibility issues might seem overwhelming, the data reveals that 96.4% of detected errors fall into just six categories:

<figure>
    <img src="/images/webaim-graph.png" alt="Chart identifying most prevalent wcag failures"/>
    <figcaption>WCAG 2.1 Failure Types Prevalence, results via WAVE</figcaption>
</figure>

1.  [Low contrast text](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) (81.0% of home pages)

2.  [Missing alternative text for images](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html) (54.5%)

3.  [Missing form input labels](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html) (48.6%)

4.  [Empty links](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html) (44.6%)

5.  [Empty buttons](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html) (28.2%)

6.  [Missing document language](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html) (17.1%)

These same issues have persisted as the most common errors for the past five years, suggesting that focusing on these specific areas could dramatically improve web accessibility.

Note: These issues were identified, using WAVE an automated accessibility error detection tool. Automated tools can only identify specific types of WCAG 2.1 failures and it's generally estimated that only \~40% of WCAG 2.1 Success Criteria can be identified via this method. This means that manual testing is imperative to uncovering the full scope of accessibility errors.

## The Real-World Impact

The implications of these accessibility barriers are significant. Studies show that users with disabilities often require more time to complete tasks, face lower success rates, and encounter more "blocking" errors that prevent them from achieving their goals.

How many errors would you tolerate? Errors accounted for 17% of checkout abandonment ([Baymard 2024](https://baymard.com/lists/cart-abandonment-rate)) across all users, and 88% of online consumers are less likely to return to a website if they’ve had a negative experience ([Toptal 2018](https://www.toptal.com/designers/ux/ux-statistics-insights-infographic)).

### How do errors affect people with disabilities?

*   71% of disabled users will abandon a website that they find difficult to use ([Click-Away 2016](https://www.clickawaypound.com/cap16finalreport.html))

*   In an older [Nielsen Norman Group study](https://www.nngroup.com/reports/usability-guidelines-accessible-web-design/), the time on task for assistive technology users was double that of the control group with a 60% lower success rate.

With an average of 56.8 accessibility errors per homepage, that represents a significant hurdle to expect users to overcome.

## A Mixed Picture of Progress

While the overall statistics might seem discouraging, with 95.9% of home pages showing WCAG 2 failures, there are some signs of hope. WebAIM suggests that "pages with fewer errors have gotten better while pages with many errors have gotten worse." This indicates that when organizations prioritize accessibility, they can make meaningful improvements.

Although nearly 96% of homepages had detected WCAG 2.1 failures, just under a third of homepages (31.2%) had 10 or fewer accessibility errors and this number of homepages with fewer errors is growing year over year. What this means is that **a focus on accessibility can make an impact.**

No website is free from error, and there will always be some user experience barriers as users may have conflicting user needs, however a focus on accessibility can eradicate these “low hanging fruit” WCAG failures and free up resources to focus on more complex issues leading to an org "getting beyond compliance" - i.e. being more inclusive and holistic in their approach to accessibility.

## Looking Forward

As websites continue to grow in complexity, the challenge of maintaining accessibility appears to be increasing rather than decreasing. The data suggests that website creators are often asking too much of users with disabilities in terms of overcoming barriers to access. However, the fact that some websites are improving shows that progress is possible when accessibility is made a priority.

### Where to start?

*   **Start small.** Start using an automated tool to detect low hanging fruit accessibility issues.

*   **Skill up.** Get training on incorporating accessibility into your Software Development Lifecyle (SDLC), and learn how to do accessibility testing.

*   **Understand current state.** Get an audit from an experienced professional.

Digital accessibility is a journey and can't be accomplished overnight. Avoid "too good to be true" solutions, as accessibility requires thoughtful implementation. Read the [Overlay Fact Sheet](https://overlayfactsheet.com/en/) for more information.

## Conclusion

The WebAIM Million project reveals both challenges and opportunities in web accessibility. While the current state of accessibility remains problematic, the concentration of issues in a few key areas suggests that targeted improvements could have outsized benefits. By focusing on these common issues and making accessibility a priority from the start, we can work toward a more inclusive web for all users.

The key lesson is clear: accessibility isn't just about compliance—it's about ensuring equal access to digital resources for all users. As the web continues to evolve, making accessibility a fundamental part of web development rather than an afterthought becomes increasingly crucial.


Blog

The Accessibility Blame Game: The Fallacy of the "Lazy Developer"

Accessibility Theater: The Cautionary Tale of Overlays

The State of Web Accessibility: What We Can Learn from the WebAIM Million Project