Automation should help you understand accessibility. Not pretend it solved it.
We believe in accessibility automation. We built an entire platform around it. But there's an important line we won't cross: finding an accessibility problem isn't the same as fixing it.
Beta interest only. No payment or subscription required.
Definition
So, what is an accessibility overlay?
Accessibility overlay is a broad term, but it commonly refers to technology added to an existing website, often through a script, plugin, or widget, that attempts to identify, or modify accessibility issues without requiring those issues to be fixed directly in the underlying website.
The appeal is clear.
Add a script.
Turn something on.
Avoid a long remediation project.
And make accessibility problems disappear.
We don't think accessibility works that way.
We don't want to hide the barrier. We want you to know it's there.
Imagine your website has a navigation menu that doesn't work correctly with a keyboard.
Ility isn't going to modify the experience for the visitor and tell you the navigation is fixed.
Then your team, or an accessibility expert, can address the problem where it actually exists. In the navigation.
There's a problem with the navigation.
Here's where we're seeing it.
Here's how widespread it appears to be.
Here's the work associated with addressing it.
Here's what happened after it was remediated.
The same goes for the rest of your website.
Technology can help you find and manage those problems. But the goal should still be to address the actual barrier.
If something is broken
- A form doesn't work with assistive technology? Fix the form.
- A component has incorrect semantics? Fix the component.
- Keyboard focus isn't managed correctly? Fix the interaction.
If something keeps happening
- A content pattern repeatedly creates problems? Fix the pattern.
- A third-party integration creates a barrier? Understand it, document it, and decide how you'll address it.
Automation is incredibly valuable.
Being anti-overlay doesn't mean being anti-automation. Quite the opposite. Automation is one of the most useful tools available for operating an accessibility program at scale.
Discover
Continuously crawl your website and find pages that should be part of your program.
Monitor
Repeatedly evaluate pages for issues that can be detected automatically.
Compare
Understand how findings change as your website evolves.
Identify patterns
See when the same kinds of problems appear repeatedly across pages.
Measure coverage
Know how much of your website is actually being monitored.
Keep history
Preserve what was found, what changed, and what happened afterward.
That's exactly where we want technology working hard.
But automation has limits.
Some accessibility questions require human judgment. Those aren't always questions a rule engine can answer.
That's why Ility doesn't present automated monitoring as proof that every experience is accessible. Automated testing is one layer of an accessibility program. A very useful layer. But still one layer.
Can someone understand the page?
Does the interaction make sense with a screen reader?
Is the focus order logical?
Is alternative text actually useful in context?
Can someone complete an important customer journey?
Does an error message explain what happened?
Detection and remediation should be different things.
This distinction is central to how we've designed Ility. It helps connect the two parts of the process without pretending they're the same thing.
Detection asks
- What's happening?
- Where is it happening?
- How widespread is it?
- Is it new?
- Is it recurring?
- Is there a pattern?
Remediation asks
- Why is this happening?
- What needs to change?
- Who should fix it?
- How should it be tested?
- Did the fix actually remove the barrier?
Find. Understand. Fix. Verify. Learn.
Our philosophy looks more like this.
Find, then Understand, then Fix, then Verify, then Learn, then Monitor
Step 1: Find
Use automation to identify detectable issues across the website.
Step 2: Understand
Look at context, impact, patterns, and the experience behind the finding.
Step 3: Fix
Address the underlying code, component, content, template, integration, or experience.
Step 4: Verify
Determine whether the remediation actually addressed the barrier.
Step 5: Learn
Improve the system and reduce the chance of creating the same problem again.
Step 6: Keep monitoring
Because the website is going to change again.
That's not a shortcut. It's a program.
Ility doesn't remediate your website for you. And that's intentional.
Ility gives your organization the platform to discover, monitor, understand, prioritize, manage, and document accessibility work.
That keeps the platform independent of who performs the work.
- Your internal developers.
- Your accessibility team.
- Your digital agency.
- Your existing accessibility consultant.
- Or an Ility remediation partner.
Your program stays yours.
Why does that distinction matter?
Because your accessibility work should be visible. Your team should be able to understand:
That creates something much more valuable than the appearance of accessibility: an accessibility program your organization can understand, operate, and improve.
- What did we find?
- What does it affect?
- Who owns the work?
- Was it actually fixed, and verified?
- Did the same problem return?
Accessibility overlays: common questions
Still have questions?
Tell us about your website and what you need. We'll follow up personally.
Join the BetaAn accessibility overlay is technology added to an existing website, usually a script, plugin, or widget, that tries to identify, or modify accessibility issues without fixing them in the underlying website.
No. Ility never injects code into your website or changes what visitors experience. It monitors your site, helps your team understand and prioritize findings, and manages the remediation, and verification of fixes in the website itself.
No, and that's intentional. Detecting an issue isn't the same as fixing it. Remediation is done by your developers, content team, agency, consultant, or an Ility remediation partner, and Ility keeps that work connected to the original finding.
Automation is the best way to discover pages, evaluate detectable issues, monitor change, measure coverage, and spot patterns at scale. Ility uses it for exactly that, and relies on human judgment for impact, experience testing, remediation, and verification.
No. Automated testing is one layer of an accessibility program. Questions like whether a page is understandable, whether focus order is logical or whether alt text is useful in context need manual and assistive-technology testing.
- Use automation where automation works.
- Use human expertise where human judgment matters.
- Fix barriers where they actually exist.
No magic button. Better tools.
We don't think software can replace every part of accessibility work. We do think software can make that work dramatically easier to see, organize, measure, document, and manage. That's what we're building Ility to do.
Beta interest only. No payment or subscription required.