The Future of Digital Accessibility

Thoughts from SatheeshKumar G

Accessibility, for me, is not just about standards or compliance. It’s about how thoughtfully we design and build digital experiences so that no user is unintentionally left out.

In many organizations, accessibility is often approached as a checklist item—something to validate before a release or when preparing for an audit. But through our journey, we realized that accessibility is far more than that. It’s a leadership decision, an engineering discipline, and ultimately a commitment to building inclusive digital products.

In this blog, I’d like to share some practical perspectives from our journey—what worked, what challenged us, and how we’ve begun thinking about accessibility as a scalable, engineering-driven practice.

What Is Accessibility Testing?

At its core, accessibility testing ensures that digital products can be used by people with diverse abilities. This includes users who rely on assistive technologies such as screen readers, keyboard navigation, voice control, or other accessibility tools.

Practically speaking, accessibility testing involves validating applications against standards like WCAG (Web Content Accessibility Guidelines). These guidelines ensure that websites and applications are perceivable, operable, understandable, and robust for all users.

From a leadership perspective, accessibility isn’t just about passing compliance audits. It’s about building inclusive, resilient, and future-ready digital experiences that serve every user.

Types of Accessibility Testing We Perform

In real-world engineering environments, accessibility testing is not a single activity. It requires a combination of approaches working together.

Automated Testing

Automation plays a critical role in identifying common accessibility violations quickly and consistently across large applications.

For example, automated scans can detect issues such as:

  • Missing form labels
  • Low color contrast
  • Improper heading structure
  • Missing alt text for images

During regression cycles, these automated checks allow teams to scan hundreds of pages efficiently.

However, automation alone cannot validate real user experience.

Manual Testing

Manual testing remains essential for validating real user flows where human judgment is required.

A typical example is verifying whether a user can complete a full workflow—such as checkout, onboarding, or form submission—using only keyboard navigation.

Manual testing helps uncover usability issues that automated tools often miss, such as confusing focus states or unclear error messaging.

Assistive Technology Testing

This is where we validate the actual experience using assistive technologies such as screen readers.

Screen readers are tools used by people who are blind or visually impaired. Instead of seeing the screen, users listen to the content and navigate using keyboard commands or gestures.

Common screen readers include:

  • NVDA – widely used on Windows in enterprise environments
  • JAWS – commonly used in regulated industries
  • VoiceOver – built into macOS and iOS

During testing, we typically validate:

  • Whether buttons, links, and form fields are announced correctly
  • Whether the reading order is logical
  • Whether form errors are communicated clearly
  • Whether users can understand context without visual cues

A simple analogy I often use is this:

A screen reader experience is like listening to a webpage. If the structure isn’t correct, the story doesn’t make sense.

Screen reader testing often reveals usability issues that automation simply cannot detect.

Visual and Responsive Testing

Accessibility also includes visual adaptability.

Users may rely on features such as:

  • Zooming content up to 200% or more
  • Reflow of layouts on smaller screens
  • High-contrast or readable typography

We validate whether content remains usable and readable across different zoom levels and devices.

The key takeaway is simple:

Accessibility works best as a layered strategy. No single testing method is sufficient on its own.

Our Accessibility Journey and Pain Points

Like many organizations, our accessibility journey didn’t start perfectly.

Initially, we relied heavily on manual testing and browser-based tools such as AXE plugins. These tools were helpful for early awareness and basic validation, but as our applications grew larger, we began encountering significant limitations.

Key Challenges We Faced

Manual testing was extremely time-intensive. Running accessibility checks across hundreds of pages required significant effort and was difficult to repeat consistently.

Automation through browser plugins lacked scalability. While plugins could scan individual pages effectively, they were not designed for large-scale regression testing.

There was heavy dependency on a small group of accessibility experts. This created bottlenecks and limited how quickly teams could scale accessibility testing across projects.

We also evaluated enterprise accessibility platforms in the past. While they offered deep capabilities, many of them followed page-based or usage-based licensing models. This made it difficult to scale accessibility testing across large applications without frequent cost discussions.

That’s when we realized an important principle:

Accessibility tooling should scale with the application—not restrict it.

Scaling Accessibility: What Made the Difference

At one point, we were looking for a solution that teams would actually adopt—something that could integrate naturally into existing QA workflows and allow accessibility testing to scale alongside development.

The key change came from consolidating accessibility testing within a unified testing environment where teams were already running cross-browser and automation tests.

This had several advantages:

  • Cross-browser testing, automation testing, and accessibility checks could run on a single platform
  • Execution time was reduced significantly
  • Teams didn’t need to switch between multiple tools

One capability that particularly changed how we approached accessibility was unlimited page coverage.

Instead of constantly deciding which pages to scan and which pages to exclude, teams could simply test the application comprehensively.

Accessibility became a continuous testing activity rather than a selective one.


Accessibility at Scale: A Practical Example

In one of our larger accessibility engagements, we were responsible for validating hundreds of application pages across multiple testing cycles.

The challenge was not just identifying accessibility issues—it was ensuring that accessibility checks could be repeated consistently across releases without slowing down delivery.

By adopting a scalable accessibility testing approach, teams were able to:

  • Perform accessibility scans across large application areas
  • Integrate accessibility validation into regression cycles
  • Maintain testing consistency across releases

The real benefit wasn’t just faster testing.

It was the confidence that accessibility was being handled systematically and at scale, rather than as a one-time exercise.

Business Outcomes and Engineering Impact

From a leadership standpoint, the outcomes were clear.

Accessibility improvements led to several tangible benefits:

Reduced dependency on manual-only testing Automation allowed teams to shift focus toward higher-value usability validation.

Faster audit readiness Centralized accessibility reporting enabled teams to run automated scans, workflow tests, and assistive technology validations and combine them into consolidated reports aligned with WCAG criteria.

This made it easier for engineering teams to prioritize fixes and for compliance teams to provide evidence of progress.

Improved collaboration across teams Accessibility became a shared responsibility between QA, developers, and product teams.

Better release confidence Accessibility issues were identified earlier in the development lifecycle rather than becoming last-minute blockers.

In short, accessibility stopped being a last-minute risk and became part of the engineering culture.

VPAT and Accessibility Transparency

Another important element in enterprise accessibility programs is the VPAT (Voluntary Product Accessibility Template).

A VPAT is a standardized document that explains how well a product conforms to accessibility standards.

It is commonly requested by:

  • Government agencies
  • Enterprises operating in regulated markets
  • Procurement and compliance teams

It’s important to note that a VPAT is not a certification.

Instead, it is a transparency document that provides evidence of accessibility conformance and testing efforts.

For organizations operating globally, maintaining accurate accessibility documentation is increasingly becoming a requirement.

The Compliance Reality in the US and UK

Organizations operating in the United States and United Kingdom are facing growing regulatory scrutiny around digital accessibility.

Key regulatory frameworks include:

  • ADA (Americans with Disabilities Act)
  • Section 508 compliance in the US
  • Equality Act in the UK
  • EN 301 549 across the EU

What many organizations underestimate are the hidden costs of reactive accessibility fixes, including:

  • Delayed releases
  • Expensive remediation work
  • External audit costs
  • Legal exposure and reputational damage

In our experience, proactive accessibility investment is always more cost-effective than reactive remediation.

The Future of Accessibility

Accessibility is evolving from a niche specialization into a core pillar of digital engineering.

The organizations that succeed will be the ones that treat accessibility not as a compliance task—but as part of product quality, user experience, and digital trust.

As leaders, the real question is no longer “Are we compliant?”

The better question is:

“Are we building digital experiences that truly work for everyone?”

When accessibility becomes part of everyday engineering practice, inclusion stops being an afterthought—and becomes a natural outcome of good design.

 

-Thank you

Satheesh Kumar G

Hi, we are looking for IAAP Specialist from Bangalore who can help us. Please message me.

To view or add a comment, sign in

Others also viewed

Explore content categories