Accessibility testing Archives /Tag

Is ChatGPT a Substitute for Web Accessibility Remediation?

If you’ve worked in digital long enough, you’ve probably heard it: “Couldn’t we just use ChatGPT to fix the accessibility stuff?”

It’s an honest question. The tools are impressive. AI can summarize dense docs, spit out code snippets, even draft copy that sounds decent. When you’re staring at a backlog with limited budget, “free and fast” feels like a gift.

Here’s the truth: speed without understanding rarely saves time. ChatGPT is great at producing. What it isn’t great at is deciding. And web accessibility—the real kind, not just error cleanup—is full of decisions.

So, while it can support web accessibility remediation, it can’t replace it. Because remediation isn’t just about fixing what’s broken; it’s about understanding why it broke and what the right fix means in the context of your design, your users, and your codebase.

What Remediation Really Looks Like

Real remediation is closer to detective work than to one-off development. You trace how a problem shows up in the interface, how it travels through templates, and why it keeps coming back.

It starts with discovery—learning how the site is put together and where risky flows live, like checkout or account pages. Then comes testing, both automated and human, to catch what scanners miss: poor focus order, ambiguous instructions, unlabeled controls, shaky widget behavior.

From there, you triage and translate findings into work your team can actually ship. You plan fixes, weigh impact and effort, and roll changes through your stack. Finally, you validate with real assistive tech—keyboard, screen readers, voice control—to confirm the fix is a fix for real people.

AI can sit beside you for parts of that journey. It can help reason through code or rephrase unclear labels. But it can’t feel when something “technically passes” yet still fails a user. That kind of judgment is learned, not generated—and it’s why web accessibility remediation stays a human-led process.

Where ChatGPT Earns Its Keep

Used by someone who understands accessibility, ChatGPT is genuinely helpful. It’s fast at rewriting small markup patterns. It can unpack a WCAG success criterion in plain language. It can draft alt text you’ll refine, or outline starter docs a team will own.

It’s also great for teaching moments: when a new dev asks, “Why ARIA here?” AI can frame the idea before a specialist steps in with specifics.

Think of it as an eager junior colleague—useful, quick, and worth having in the room. Just don’t hand it the keys.

The Problem of “No Opinion”

Here’s where AI hits the wall: it has no sense of context and no opinion of its own.

Accessibility isn’t a math problem. Two developers can solve the same issue differently—both valid on paper, one far more usable in practice. That judgment call is the job.

Because ChatGPT predicts what looks right, it can sound confident and still be wrong: adding a <label> but leaving a placeholder that confuses screen readers; copying a title into alt and causing duplicate announcements; “fixing” contrast by nudging color values without checking the full component state.

Some barriers simply require a human to decide. Take alt text, for example: ChatGPT can’t actually see what an image is, how it’s being used, or what role it plays in the design. It doesn’t understand whether that image conveys meaning or is purely decorative—and that context determines whether alt text is needed at all. Without that judgment, even the best AI guess risks being wrong for the user.

When you’re fixing accessibility, “almost right” is often still wrong. And when someone asks you to show due diligence, “we asked a chatbot” isn’t a defensible audit trail for web accessibility remediation.

The Hidden Cost of “Free”

Teams that lean too hard on AI learn fast that “free” isn’t free.

You spend hours double-checking output, rewriting prompts, and chasing new issues that didn’t exist before. Sometimes you even end up debugging phantom problems the model invented.

Meanwhile, the real barriers remain. Automated tools and AI together tend to catch only a slice of what actually affects users; the messy, contextual stuff slips through.

So the report looks cleaner, the error count drops, and real people still struggle. That’s not progress. That’s paperwork dressed up as progress—and it leaves risk on the table, which is the opposite of web accessibility remediation.

Even if AI manages to correct every automated scan error, it won’t protect you from real exposure. We’re now seeing a clear shift in ADA litigation: most new lawsuits aren’t built on automated findings anymore. They’re targeting manual issues—things uncovered by human testing and user experience barriers—because that’s where easy wins live for plaintiff firms. So even if AI covers one base, it leaves another wide open—and that’s the one most likely to cost you.

Why Human-Led Web Accessibility Remediation Still Matters

When you bring in a team that lives this work, you’re getting far more than bug fixes—you’re gaining traction. Instead of chasing one-off errors, you start to see the larger patterns behind what keeps breaking and why.

A strong remediation partner brings clarity to your roadmap by tying priorities to real user impact and legal risk. Their fixes hold up through redesigns because they focus on underlying causes rather than surface-level symptoms.

There’s also the advantage of human validation—review that’s defensible, thoughtful, and grounded in actual user experience. With the right process, accessibility becomes part of everyday development instead of something bolted on at the end.

That’s the real promise of web accessibility remediation: not perfection, but predictability you can trust as your site evolves.

How to Use AI the Right Way (With Guardrails)

AI belongs in the workflow. It just doesn’t belong in charge.

Use ChatGPT to speed up work you already understand, not to make calls you can’t verify. Let it draft checklists, summarize long audit exports, or propose markup for a pattern you’ve already chosen.

Then layer on what AI can’t do: manual testing, AT validation, and the human decision-making that turns “technically correct” into “genuinely usable.”

With that guardrail, AI becomes an accelerator for web accessibility remediation, not a shortcut that creates rework.

What You Actually Get from Professional Remediation

When you bring in a team that lives this work, you’re getting far more than bug fixes—you’re gaining traction. Instead of chasing one-off errors, you start to see the larger patterns behind what keeps breaking and why.

A good remediation partner helps you understand where to focus first by tying priorities to real user impact and legal risk. They deliver fixes that continue to hold up through redesigns because the underlying causes—not just the surface-level symptoms—are addressed.

You also gain something automated tools can’t offer: human validation that stands up to scrutiny. And with the right team, accessibility becomes part of how your site operates going forward, rather than something added after the fact.

That’s the real value of web accessibility remediation. It’s not about perfection—it’s about creating a level of predictability you can trust as your site evolves.

AI Doesn’t Make Judgment Calls—People Do

ChatGPT is a powerful tool. It can teach, inspire, and save time—but it can’t care. Accessibility is about care: for users, for quality, for inclusion.

AI can suggest the “how.” People understand the “why.” And perhaps most importantly, AI can’t shield you from the kinds of lawsuits that automation no longer catches.

If your team is experimenting with AI and you want to make sure it helps instead of hurts, start with a conversation. Schedule an ADA briefing with 216digital. We’ll show where AI fits safely, where human oversight is non-negotiable, and how to build a plan that keeps your site open to everyone.

That’s web accessibility remediation done right—fast where it can be, thoughtful where it must be.

Greg McNeil

November 10, 2025

Testing & Remediation

Accessibility Remediation, Accessibility testing, AI-driven accessibility, automated testing, Web Accessibility Remediation
Can Free Tools Handle Accessibility Monitoring?
You’ve finished remediation. The worst barriers are gone, and your team takes a well-earned victory lap. A few weeks later, though, a plugin gets updated, marketing adds a third-party widget, a dev ships a “harmless” CSS tweak—and suddenly a button loses its visible focus style, a modal traps keyboard users, and checkout errors stop announcing to screen readers.

That’s how the web works: a website is a living system. Content, components, dependencies, and integrations are always in motion. And it doesn’t take a major redesign to break something important—sometimes a “quick fix” is all it takes to undo months of good work.

That raises the question: Is it enough to lean on free browser tools for occasional spot checks, or is it time to invest in accessibility monitoring that gives you steady, ongoing confidence?

In this guide, we’ll compare both paths—cost, coverage, reliability, risk, and effort. We’ll also share a hybrid approach that many teams prefer and show how a11y.Radar (216digital’s monitoring solution) helps you protect the remediation you’ve already paid for while keeping team workload predictable.

Why Ongoing Accessibility Monitoring Matters (Even After You “Pass”)

Think of accessibility like security, uptime, or SEO: you don’t check once and call it done—you maintain it. After remediation, your site is in a good place. But change is constant, and those changes often show up in small, easy-to-miss ways, such as:
- A new banner, analytics script, or carousel has been added to a key template.
- A cookie-consent update that quietly alters focus management or timing.
- A styling tweak that shifts color contrast or live-region behavior.
Many issues don’t show up on the surface. They appear when people actually interact with your interface—opening a menu, submitting a form, tabbing through a dialog, or switching filters. The more ways people can move through your site, the more opportunities there are for something to break without anyone noticing right away.

Why You Can’t Rely on Users (Or Automation) Alone

As your site grows, so does the number of templates, content authors, and embeds. Every new piece is another opportunity for a regression. Relying on users to report problems means you’ll hear about them late, and often in a very public way. At the same time, you already know that meaningful issues in mature audits usually need human judgment; automation alone can’t replicate a real person moving through real flows.

Monitoring isn’t about chasing scores. It’s a way to catch small cracks early, before they turn into costly gaps that affect both user experience and your team’s time.

Free Browser Tools: What Are They and Where They Fall Short

You already know the classics, like Google Lighthouse in Chrome DevTools. They’re fast, free, and helpful, and they absolutely deserve a place in your process.

These tools shine in moments like:
- Running checks during development or PR review to catch obvious misses such as missing alt text, ARIA misuse, or color-contrast problems.
- Iterating on a single component or template where quick, page-level feedback keeps improvements moving.
In those contexts, it’s easy to run Lighthouse on a single page, surface immediate issues, and point engineers straight to the right fixes.

Where Free Web Accessibility Tools Fall Short

The challenge comes when you try to stretch these tools beyond what they were designed to do. Page-by-page checks don’t give you site-wide visibility, automated drift detection, or a sense of how issues are spreading across templates. Most free scans don’t simulate realistic user journeys—checkout, sign-up, multi-step forms—so serious interaction problems can stay hidden. You also don’t get alerts, historical trends, or reports to show what’s getting better or worse over time.

On top of that, the signal can be noisy. Some findings are low impact or turn out to be false positives, while other high-impact problems never surface at all without human testing. Free tools are fantastic tactical helpers, but they aren’t a complete plan for accessibility monitoring at scale.

The Hidden Costs of “Free”

“Free” starts to look expensive once you factor in the time your team spends and the risk your organization carries.

Manually scanning individual pages doesn’t scale well as your catalog, blog, or application grows. Over time, consistency slips, and gaps appear between what you intend to check and what actually gets checked. Without any alerting, a broken label or focus trap can sit unnoticed for weeks, frustrating users and quietly hurting conversions.

Risk and False Confidence

A green Lighthouse score can also create a false sense of security. It doesn’t cover complex interactions or conditional content, and it can’t guarantee that every critical flow is usable with assistive technology or only a keyboard. Meanwhile, if a barrier exists when a user needs to complete a task, “we thought we were compliant” won’t help much in a legal or reputational crisis.

The Retrofit Tax

There’s also the retrofit tax to consider. The longer a bug lives, the more it costs to fix—especially when it becomes part of a shared design system or depends on a third-party script. A helpful gut-check is this: if a critical flow broke tonight, how would you know—and how quickly could you respond?

What Paid Accessibility Monitoring Adds That Free Tools Can’t

A professional monitoring platform isn’t just “more scans.” It’s a system designed to help keep your site accessible over time, even as everything around it changes.

Instead of manually spot-checking individual URLs, automated site-wide crawls scan your core templates and priority pages on a schedule. When a regression appears—maybe a template shifts, a new blocker arrives, or a dependency change breaks a pattern—the platform can surface that change quickly with contextual checks and alerts, so the right people hear about it while the issue is still small.

Turning Findings Into Action

Dashboards and trend lines turn those scans into something you can act on: you see what’s improving, what’s slipping, and where to focus next, with numbers you can share in reports. Integrations with tools like Jira or GitHub let you turn findings into tickets, assign owners, and track SLAs just like any other quality work. At the same time, an audit trail and documentation give you a record of what was found, when, and how it was resolved—valuable for compliance, procurement, and legal conversations.

Scaling Without Burning Out Your Team

Most importantly, a paid accessibility monitoring approach scales with you. As content and complexity grow, the system keeps up without burning out your developers, turning panicked fire drills into a more predictable subscription and a steadier workflow.

A Practical Way to Decide: Budget, Scale, Confidence

You don’t have to choose between “only free” or “only paid.” Many teams blend both, matching their approach to their personal constraints.

If your site is small, built on a limited set of templates, and doesn’t change very often, you may find that free tools plus periodic professional audits are enough—especially if your legal exposure is relatively low and you can plan for a full review once or twice a year.

On the other hand, if you’re working with a medium or large site or application, have frequent releases and many contributors, or maintain complex flows like checkout, applications, or authenticated account areas, the calculus changes. Higher-risk environments—enterprise, healthcare, finance, public sector—often need more confidence, along with leadership-level reporting and accountability, and that’s where continuous accessibility monitoring becomes hard to ignore.

Why a Hybrid Strategy Often Wins

A hybrid strategy often gives the best of both worlds. Free tools stay in the development workflow to support dev speed: run Lighthouse and similar tools during builds and code reviews to catch obvious misses early. Accessibility monitoring then sits underneath as a safety net, catching drift, regressions, and wide-impact issues across the site. Because everyone—from product managers to executives—can see how things are trending, accessibility becomes a shared responsibility, not a side project.

Think of it like uptime: you still write resilient code, but you also run monitoring so you know when something fails.

a11y.Radar: Ongoing Accessibility Monitoring, Minus the Guesswork

After helping hundreds of organizations remediate, we built Accessibility Radar (a11y.Radar) at 216digital to address the problems that show up after the fixes are shipped and celebrated.

a11y.Radar runs recurring crawls aligned to WCAG 2.2 (and ready for future updates), so your coverage keeps pace with current standards instead of freezing at the moment your audit was completed. When something that used to pass starts to fail, regression alerts let your team know quickly, often before users ever notice an issue. An issue dashboard surfaces severity and trends, so you can prioritize the highest-impact work first instead of chasing every minor flag with the same urgency.

How a11y.Radar Works Day to Day

You can also focus directly on key user journeys—checkout, forms, account areas, and other revenue or mission-critical flows—so the scenarios that matter most to your business are watched closely. Workflow integrations mean that findings don’t live in yet another silo; they move into the tools your dev and QA teams already use, via tickets, email, or exports. Context-aware guidance then points teams toward actionable fixes instead of leaving them to interpret raw scanner output alone.

Human Expertise and Real-World Impact

Behind the data is practitioner expertise. You benefit from specialists who spend their days fixing accessibility barriers, not just reading reports. a11y.Radar is human-first by design: it supports the judgment calls automation can’t make and keeps people focused where they add the most value. The result is simple but powerful—you’ve already paid to remediate; now Radar helps you keep that investment working in the background, day after day.

For example, an e-commerce team wrapped up remediation in Q1. By Q2, a marketing embed introduced an off-screen focus trap on mobile filters. Lighthouse runs on individual pages, which looked fine because no one opened the filter drawer during checks. a11y.Radar flagged the regression within 24 hours as part of a scheduled crawl. The team patched the component that same week, preventing a dip in conversions and a wave of support tickets. Because monitoring caught it early, the fix took hours—not weeks.

How to Choose Your Monitoring Setup (and Whether You Need One)

Use this list to map your situation and make a confident choice:
1. Site size & complexity
  - How many unique templates and components?
  - Do you lean heavily on third-party scripts or embeds?
  - Are there complex flows such as checkout, onboarding, applications, or donations?
2. Update frequency
  - How often do you deploy?
  - How many non-dev authors can publish or update content (marketing, merchandising, HR, communications)?
3. Team capacity
  - Do you have in-house accessibility expertise?
  - Can dev and QA dedicate consistent time to triage and fixes?
4. Risk tolerance
  - What is the cost if a key task is inaccessible for a week?
  - Are you in a regulated or contract-sensitive space?
5. Budget philosophy
  - Do you prefer a predictable subscription, or are you comfortable with unpredictable “hot-fix” costs and potential legal exposure?
6. Evidence & accountability
  - Do stakeholders want monthly trends, audit trails, and measurable progress?
How to Interpret Your Answers

If most of your responses fall into the low-complexity, low-velocity, and low-risk range, you’ll probably do well with free tools supported by periodic audits. In that scenario, it may still be worth lightly monitoring your most important templates, but you probably do not need full-scale automation.

When you start to see a mix of medium and high scores—especially around risk, complexity, or how fast you release—continuous monitoring becomes far more valuable. It can help you catch issues earlier, reduce last-minute fire drills, and lower the chances of an expensive surprise.

If your answers land somewhere in the middle, a blended approach often works best: use free tools during development, then layer on a11y.Radar to watch the full site in the background and alert you when something slips.

FAQs: Common Questions About Accessibility Monitoring

If Lighthouse gives me a high score, am I good?

It’s a positive signal, but not a guarantee. Scores don’t validate complex interactions, dynamic states, or multi-step flows.

Can’t we just train employees better?

Training helps a lot, and you should invest in it—but embeds, plugin updates, and code changes still happen. Monitoring catches the issues that training can’t fully prevent.

WHow fast will monitoring pay for itself?

YOften, the first caught regression—such as a broken checkout label, a focus issue in a form, or a contrast change in a primary call-to-action—saves enough support time, lost conversions, or rework to cover months of the subscription.

Do we still need manual testing?

Yes. Complex interactions and edge cases still need human eyes. Monitoring reduces the overall manual volume and helps focus human effort where it matters most.

Remediation Makes You Compliant—Accessibility Monitoring Keeps You There

You’ve already done the hard part: remediation. Now it’s about protecting that work.

Free tools like Lighthouse belong in every developer’s toolbox and should be used often. But on a website that changes weekly—or daily—free spot checks alone won’t provide the continuous, site-wide assurance your users and your stakeholders truly need.

A thoughtful strategy anchored by a11y.Radar gives you that kind of assurance: automated crawls, actionable alerts, trends over time, and an audit trail that holds up under scrutiny. It lowers stress, preserves developer bandwidth, and—most importantly—keeps your experience welcoming and usable for everyone.

If you’d like help choosing the right mix for your site and want to see how a11y.Radar fits into your reality, let’s schedule an ADA briefing with 216digital. We’ll map your risks, walk through a practical setup, and build a plan that keeps accessibility strong and sustainable over the long term.

Greg McNeil

October 23, 2025

Web Accessibility Monitoring

Accessibility, Accessibility monitoring, Accessibility testing, web accessibility monitoring, Website Accessibility
Consultants or Automated Platforms: What’s Right for You?
Making a website accessible isn’t always a straight path. There are sleek platforms that can scan every page in minutes, and seasoned consultants who can spot problems no algorithm would catch. Each offers value—but in very different ways.

The challenge isn’t choosing which one is “better.” It’s knowing when to rely on quick automated checks and when your site needs the nuance only human expertise can provide. Getting that balance right can turn accessibility from a one-time project into a lasting part of how your site works.

What Automated Platforms Do Well

Automated accessibility platforms are essentially software tools that scan your site for compliance issues. Think of them as always-on monitors quietly running in the background. They can:
- Scan your site regularly to flag new problems as they appear
- Track your accessibility performance over time
- Send alerts when something changes
They’re fast, efficient, and cost-effective. Within minutes, they can show you where your site stands and give you a benchmark to measure progress. For many organizations, this kind of real-time insight is reassuring—especially after an initial round of accessibility improvements. Automated tools can help ensure new issues don’t creep in unnoticed.

But while they’re powerful, they’re not perfect. automated platforms can catch many surface-level problems, like missing alt text or low-contrast color pairings. What they can’t do is understand the human experience of using your site. They don’t know if your navigation makes sense to someone using a screen reader, or whether form instructions are clear enough to avoid confusion. For those nuanced judgment calls, human expertise is essential.

The Role of Accessibility Consultants

Accessibility consultants offer something no machine can: experience, context, and human perspective. They don’t just tell you what’s broken—they explain why it matters and how to fix it in a way that fits your real-world workflows.

A good consultant will:
- Conduct thorough audits that go far beyond automated scans
- Identify root causes, not just symptoms
- Guide your team through remediation with practical, achievable steps
- Provide training so you can build accessibility into your process in the future
Consultants also bring critical legal and standards knowledge to the table. They stay on top of evolving regulations and know how guidelines like WCAG apply to your specific industry or audience. That insight can help you minimize legal risk while also creating a more welcoming experience for users with disabilities.

In other words, they look at the big picture—something an automated tool can’t do.

Why Consultant-Led Remediation Should Come First

One of the most common missteps organizations make is starting with an automated platform before any human-led remediation. On paper, it seems logical: run a scan, see what’s wrong, and start fixing. But in practice, this often backfires.

Automated scans can return long lists of issues—some legitimate, some false positives, and many without clear instructions for resolution. Without expert guidance, it’s easy to spend hours chasing the wrong problems or applying “fixes” that don’t actually help real users.

Consultant-led remediation flips this process around for better results. Instead of reacting to a flood of automated alerts, you get a clear, prioritized plan from someone who understands both the technical and human aspects of accessibility. They focus on foundational issues first, ensuring the fixes are meaningful and sustainable.

Once that groundwork is in place, automated platforms become incredibly useful. They act like a safety net, helping you maintain the progress you’ve made.

Think of it like building a house: you wouldn’t install a security system before the walls are up. The system is valuable—but only once the structure is solid.

When Automated Platforms Make Sense

After you’ve remediated your site with the help of a consultant, automated platforms can become a valuable part of your ongoing strategy. Websites are living, changing systems. Every content update, plugin installation, or design tweak carries the potential to introduce new accessibility barriers.

An automated platform helps you stay ahead of those problems by catching them early. They’re instrumental when:
- You publish new content frequently
- You’re rolling out design changes or new features
- You want to show good-faith efforts with regular monitoring reports
- You need an affordable way to keep watch between consultant reviews
Used this way, automated tools act as a maintenance system. They can’t replace human testing, but they can help keep your site healthier between more in-depth reviews.

How to Decide What’s Right for You

Choosing between consultants and automated platforms becomes much easier once you know where you are in the accessibility journey.

Starting from scratch? Bring in a consultant first. Their guidance will help you build a solid foundation and avoid the guesswork that leads to costly mistakes.

Working through remediation? Stay the course with consultant-led support. Automated scans can muddy the waters here, flagging noise instead of what really matters.

Site already in good shape? That’s the moment to add an automated platform. Let it keep an eye on new changes while consultants check in periodically for deeper reviews.

For many organizations, the most effective approach is a blend of both—just in the correct order. Human expertise lays the groundwork. automated platforms help you maintain it.

The Long-Term Payoff

Web accessibility isn’t a box you check off once—it’s a long-term commitment. But it’s one that pays off in measurable ways: stronger legal compliance, broader audience reach, improved usability, and greater trust from customers and clients.

Consultants give you the strategy, expertise, and training to start on solid ground. automated platforms give you the ongoing monitoring to protect that investment.

When used together, they create a sustainable system. You get the precision of expert audits and the efficiency of automated monitoring. This balance reduces risk, improves user experience, and keeps you aligned with evolving standards as they change over time.

Human First, Automation Second

Choosing between consultants and automated platforms isn’t really about picking one over the other—it’s about knowing how they fit together. Automated tools can keep watch over the details, but it takes human expertise to build the kind of foundation that lasts.

Start by getting that solid groundwork in place with a consultant-led audit and remediation. Once your site is truly accessible, an automated platform can help you keep it that way—quietly catching issues before they become problems.

If you’re ready to map out what that first step should look like, schedule an ADA briefing with 216digital. It’s a chance to talk through where your site stands, what’s needed to meet compliance, and how to build a long-term plan that keeps accessibility on track.
Greg McNeil

September 17, 2025

Testing & Remediation

Accessibility, Accessibility Remediation, Accessibility testing, automated scans, automated testing, consultants, Web Accessibility, Web Accessibility Remediation, Website Accessibility
What Is a VPAT and Why It Matters
Accessibility in technology is about making sure everyone can use digital products, including people with disabilities. It is not only the right thing to do but also a legal requirement for many organizations. When companies create websites, software, or online tools, they need a clear way to show how accessible those products are.

One common tool for this is called a VPAT, or Voluntary Product Accessibility Template. A VPAT is not a stamp of approval. It does not mean a product is perfect or fully compliant. Instead, it is a clear report that explains how a product meets accessibility rules. In this guide, you will learn what a VPAT is, who needs one, and how to fill it out so others can understand your product’s accessibility.

What Is a VPAT?

The Voluntary Product Accessibility Template is a standard form used to explain how accessible a digital product is. It was first created in 2001 by the Information Technology Industry Council to help vendors follow Section 508 of the Rehabilitation Act. Section 508 is a U.S. law that says technology used by federal agencies must be accessible to people with disabilities.

Since then, the VPAT has grown to cover more rules. Today, it is used to report on Section 508, the Web Content Accessibility Guidelines (WCAG), and the European accessibility standard called EN 301 549. The latest version is VPAT 2.4, with VPAT 2.5 beginning to be used as well.

When a VPAT is filled out, it becomes what is called an Accessibility Conformance Report (ACR). This report is a guide for buyers and procurement teams. It is important to remember that a VPAT is not a certificate. It is simply a trusted format for sharing accessibility information in a way that can be compared, reviewed, and acted on.

Who Needs a VPAT?

VPATs are most often needed by companies that sell to the federal government. Under Section 508, all technology purchased by federal agencies must be accessible. Contractors, vendors, and SaaS providers working with these agencies are expected to provide a VPAT.

But VPATs are not just for federal buyers. State and local governments, universities, and organizations that receive federal funding may also require them. Increasingly, private companies are asking for VPATs before making a purchase.

For vendors, creating a VPAT shows more than compliance. It proves they value inclusivity and transparency. In competitive markets, that can make a difference. Buyers want to work with partners they can trust, and a clear VPAT signals that accessibility is part of your process—not an afterthought.

Which VPAT Version Should You Use?

There are several versions of the VPAT. The right one depends on who will read it.
- Section 508 version: Used in the United States for federal customers.
- EU version: Designed for the European market.
- WCAG version: Focused only on WCAG guidelines.
- INT version: Includes all three standards and is best for global companies.
Most U.S. vendors working with federal agencies use the Section 508 version. Companies with international customers often choose the INT version because it covers multiple standards at once, helping them meet different buyers’ needs with a single report.

Core Elements of a VPAT

A VPAT or ACR has a few main sections:
- Basic Product Details: Name, version, description, date of evaluation, and contact information for the person or team who did the review.
- Accessibility Standards: The rules used in the evaluation, such as WCAG 2.1 or Section 508.
- Testing Methods: How the product was tested, whether through manual checks, automated tools, or by using assistive technology like screen readers.
- Conformance Table: The most important part of the VPAT. Each entry lists the accessibility requirement, shows the level of support, and provides remarks or explanations.
The conformance levels include:
- Supports: The product meets the requirement.
- Partially Supports: The product meets it in some areas but not all.
- Does Not Support: The product fails to meet the requirement.
- Not Applicable: The requirement does not apply to the product.
The remarks section explains the details, such as what works well, what does not, and whether improvements are planned.

Tips for Filling Out a VPAT

When filling out a VPAT, accuracy matters. Accessibility is rarely a simple yes or no. If a product only partly meets a requirement, that should be explained. Avoid vague answers like “supports with exceptions” without details.

The report should be based on real testing. Use manual reviews, automated scans, and assistive technology to see how the product performs. In the remarks, point to real examples, such as how a screen reader reads an image or how easy it is to navigate with a keyboard.

It is also important to make the VPAT itself accessible. Use headings, clear tables, and proper formatting so people who use assistive technology can read it.

The VPAT should be updated often. Products change with new features and fixes, and the VPAT needs to reflect those changes. Always include the date and product version so readers know the information is current.

Finally, be honest. If something does not meet the requirement, say so and explain what you are doing to fix it. Buyers will respect openness more than silence.

Why VPATs Matter Beyond Legal Compliance

VPATs are not just about following the law. They also provide real benefits. Buyers can compare different products more easily. Vendors show they care about accessibility and all their users. Organizations reduce risk by having a clear record of their accessibility work.

In the end, VPATs help build trust. They show that accessibility is a real part of product design and not just an afterthought.

Closing Thoughts

A VPAT turns accessibility testing into a structured report that is easy to understand. It is not a certification and does not claim a product is perfect. Instead, it shows accountability and provides buyers with useful information.

Any organization that offers digital products should see a VPAT as part of an ongoing journey toward accessibility. It is not just about winning contracts but about building products that work for everyone.

If you want help creating a VPAT, understanding the standards, or making sure your documentation is accurate, 216digital can guide you through the process. We are ready to help with clear, practical advice so you can move forward with confidence.
Greg McNeil

August 19, 2025

Testing & Remediation

Accessibility Audit, Accessibility testing, custom accessibility audits, manual audit, Manual Testing, VPAT
How to Fit Accessibility Testing Into Your Sprint
Agile development thrives on fast, iterative progress—and that can make accessibility feel like a hurdle rather than a habit. But accessibility testing doesn’t have to slow you down. In fact, when baked into your sprint process from the outset, accessibility becomes a natural part of your workflow—reducing rework, enhancing code quality, and safeguarding your organization from legal risk.

This guide walks through how to integrate accessibility testing into your Agile sprints without sacrificing speed or innovation. With the right approach, inclusive design becomes a team-wide mindset—and a competitive advantage.

Why Accessibility Testing Belongs in the Sprint

Accessibility testing helps ensure your website or app can be used by people of all abilities, including those who rely on screen readers, keyboard navigation, voice recognition, and other assistive technologies.

Leaving accessibility checks until the end of a project—or worse, after launch—often leads to expensive remediation and a poor user experience. Worse, you could face lawsuits for failing to meet standards such as the Web Content Accessibility Guidelines (WCAG) or U.S. laws, including the ADA and Section 508.

Agile teams are already built for continuous improvement. By incorporating accessibility testing into your sprints, you:
- Catch issues earlier when they’re cheaper to fix
- Avoid bottlenecks during QA
- Improve design clarity and usability for everyone
- Demonstrate a commitment to inclusivity and compliance
Let’s break down exactly how to make this work in practice.

Shift Accessibility Left: Early Planning Wins

To integrate accessibility testing into a sprint, it needs to begin before the sprint starts.

1. Include Accessibility in User Stories

Start by writing user stories with accessibility in mind. Instead of:

As a user, I want to submit a form so I can sign up for updates.

Add accessibility context:

As a screen reader user, I want to submit a clearly labeled, keyboard-navigable form so I can sign up for updates.

This keeps accessibility visible to the entire team and sets the tone for inclusive features from day one.

2. Define Acceptance Criteria

Each user story should include accessibility-related acceptance criteria, such as:
- All buttons must be focusable via keyboard.
- Form fields must include visible and programmatically associated labels.
- Error messages must be conveyed visually and via ARIA alerts.
These criteria guide both developers and testers—and reduce ambiguity when it’s time to validate.

Build Accessibility into Design

Accessibility testing is often easier when designs are inclusive from the start.

3. Collaborate with Designers

Designers should use accessible color contrast, readable font sizes, logical tab order, and meaningful icon labels. Review early wireframes and prototypes against WCAG standards—ideally with tools like Stark or Figma plugins for accessibility.

4. Run Design Reviews

Hold accessibility-focused design reviews during planning or refinement. Spotting issues before development starts saves everyone time. Flag problems like insufficient contrast, unclear buttons, or missing focus indicators.

Develop With Accessibility in Mind

Your dev team is the frontline for accessibility. Setting clear expectations and tools helps them move fast without sacrificing inclusion.

5. Use Accessible Components

Encourage developers to use pre-tested accessible components or frameworks. For example, use accessible modal libraries that manage focus trapping and ARIA attributes out of the box.

6. Lint for Accessibility

Incorporate linters like eslint-plugin-jsx-a11y to catch common accessibility mistakes in code. This provides near-instant feedback—right inside the developer’s editor.

7. Write Semantic HTML

Encourage the use of native HTML elements like <button>, <label>, and <nav> over custom divs and spans. These elements carry built-in accessibility benefits and reduce the need for ARIA workarounds.

Make Testing Part of the Flow

Testing for accessibility isn’t a separate track—it’s part of sprint validation, just like functional testing.

8. Automated Accessibility Tests

Automate what you can using tools like WAVE or Lighthouse. These tools catch issues like missing alt text, ARIA misuse, or low contrast—before code merges.

Run them as part of your CI pipeline, so broken accessibility fails the build just like broken code.

Important Note: Automated tests only catch ~30% of WCAG issues. Manual testing is still essential.

9. Manual Testing in Sprint

Manual checks don’t need to wait for final QA. During development or code review:
- Test keyboard-only navigation
- Use a screen reader (like NVDA or VoiceOver) to verify flows
- Check page headings and tab order for clarity
Spread these tasks across the team so it’s not all on QA or accessibility specialists.

Retrospectives: Keep Improving

Agile is all about continuous learning. Use retrospectives to talk about what worked—and what didn’t—with accessibility during the sprint.

Questions to consider:
- Did we include accessibility in all relevant stories?
- Were any accessibility bugs pushed to a future sprint?
- Are our automated tools giving useful results?
Use this feedback to tweak your workflow, tooling, or documentation.

Tips for Getting Started (or Leveling Up)

If you’re new to accessibility testing in sprints, keep it simple and scale up over time. Here’s a roadmap to get started:
1. Pick one or two automated tools to run in dev and CI.
2. Train your team on basic WCAG principles—especially designers and frontend devs.
3. Set clear accessibility goals in your Definition of Done (e.g., no critical issues, passes keyboard navigation).
4. Assign shared responsibility—accessibility isn’t just the QA team’s job.
5. Start tracking accessibility debt just like tech debt. Tackle it bit by bit.
For teams already doing accessibility work, the next step might be:
- Formalizing a test plan
- Adding assistive tech testing
- Bringing in real users with disabilities for feedback
Don’t Bolt It On—Build It In

Too often, accessibility is treated as an afterthought—an item saved for the backlog or a separate “phase.” But that’s a recipe for stress, rework, and risk.

When you incorporate accessibility testing into your sprint cycle, it becomes routine—not reactive. You don’t have to choose between speed and inclusion. You get both.

And the benefits go beyond compliance. You build better products, open your brand to more users, and reduce friction for everyone.

Need Help Fitting Accessibility Into Your Workflow?

At 216digital, we specialize in helping Agile teams bake accessibility into every phase of the sprint cycle. From audits and remediation to training and ongoing support, our team ensures your products are not only compliant—but more usable and inclusive by design.

Ready to build accessibility into your sprint?

Let’s talk. Schedule a consultation today.
Greg McNeil

July 23, 2025

Testing & Remediation

Accessibility, Accessibility Audit, Accessibility Remediation, Accessibility testing, automated testing, Web Accessibility Remediation, Website Accessibility
When Should Agencies Talk to Clients About Web Accessibility Solutions?
If you’re running a small to mid-size digital agency, you’re used to juggling a lot. Creative direction, project management, client communications, SEO strategy, user experience—the list goes on. And somewhere in that mix, web accessibility often gets lost in the shuffle.

Not because it isn’t important. But because it’s not always obvious where it fits. Should you bring it up during the proposal phase? Wait until design reviews? Or tackle it after launch if an issue comes up?

Here’s the thing: the best time to introduce agency accessibility solutions isn’t “someday.” It’s early. Really early. And the earlier you bring it into the conversation, the easier it becomes to integrate—not just for your client, but for your team, too.

Let’s walk through how accessibility fits naturally into each phase of your process—and how to talk about it in a way that builds trust and positions your agency as a smart, forward-thinking partner.

Start the Conversation About Agency Accessibility Solutions

Accessibility belongs in the earliest conversations you’re having with a client—ideally, during discovery or project planning. When you’re already talking about audience personas, site goals, and technical scope, you’re laying the groundwork for how the entire site will function. This is the perfect opportunity to ask questions like:
- “Do any of your users rely on assistive technology like screen readers or voice navigation?”
- “Are there any compliance requirements or accessibility goals we should be aware of?”
- “Have you ever received feedback from users about accessibility challenges?”
These questions show your client that you’re thinking holistically about their audience. More importantly, you’re helping them see accessibility as a core part of usability and performance—not just a legal concern.

Pro move: include accessibility as a dedicated line item in your proposals. Whether it’s a basic audit, foundational best practices, or a plan for ongoing improvements, showing it in writing reinforces that it’s not optional or extra—it’s essential.

Revisit It During Design Reviews

Design is often where accessibility either starts strong—or goes sideways.

Color palettes, typography, button sizes, spacing—all of these choices affect users with low vision, motor impairments, or cognitive conditions. If you wait until development to flag issues like poor contrast or illegible fonts, you’ll either eat the cost of rework or risk pushing an inaccessible product live.

Instead, build in design checkpoints where agency accessibility solutions are part of the feedback loop. Help clients understand how design decisions translate to real-world usability. For example:
- A gorgeous but pale color scheme might look sleek on a high-end display, but disappear for users with low vision.
- Overly custom cursors or animations may cause issues for people with cognitive sensitivities or motion triggers.
- Fonts without clear letterforms can reduce readability for users with dyslexia or processing disorders.
You’re not just protecting the project from costly changes later—you’re showing the client that good design and accessible design aren’t mutually exclusive. They’re one and the same.

Simple framing tip: “When we design with more users in mind, we increase engagement and reduce support friction. It’s a win for everyone.”

Build Accessibility into Development (Not After)

By the time you hit development, things are moving fast—templates are being coded, features implemented, content loaded. This is where your accessibility groundwork either holds or starts to crack.

Make sure your dev team is on board with basic accessibility practices: semantic HTML, proper heading structure, image alt text, and keyboard-friendly components. These aren’t just nice to have—they’re baseline standards.

And keep your client in the loop, even if you’re not getting deep into technical details. It builds confidence to say:

“We’re coding with accessibility in mind—clean structure, screen reader compatibility, and keyboard navigation all included. If we run into any areas that need custom attention, we’ll flag them and talk through next steps.”

This is also a good time to set expectations around scope. Interactive elements, third-party plugins, or advanced UI components might require extra time to test or fix. It’s better to raise those flags now than scramble after launch.

And yes, it’s still a great place to talk about your agency accessibility solutions and how they support long-term site performance and compliance.

Post-Launch Is Just the Beginning

A successful launch doesn’t mean your work is done—and when it comes to accessibility, it often signals the start of new conversations.

This is when real users interact with the site. It’s also when clients might hear from a frustrated customer, an internal stakeholder with a disability, or worse—receive a demand letter related to ADA compliance.

If you’ve already laid the foundation, your client is more likely to come back to you, not panic-Google another vendor.

Stay proactive. Offer optional post-launch agency accessibility solutions like:
- Quarterly accessibility reviews
- Ongoing monitoring
- Manual and automated testing
- Remediation support and training for content editors
Even light support here builds long-term trust and positions your agency as a reliable, growth-minded partner.

Key message to share: “Accessibility isn’t a one-and-done task. As your site evolves, we’re here to make sure it continues to work for everyone.”

When Legal Risk Enters the Chat

Sometimes, accessibility becomes a priority only after a client gets a legal scare. It’s not ideal—but it’s increasingly common.

In the U.S., accessibility lawsuits have surged in recent years, many of them targeting small and mid-size businesses. And many of those cases are driven by law firms looking for fast settlements, not actual user advocacy.

If a client comes to you in a panic, your role is to stay calm and solutions-oriented. Let them know:
- You’ve handled situations like this before.
- You can help them assess the site’s current status with a thorough audit.
- You’ll work with them to document a remediation roadmap.
- You have trusted partners (or in-house experts) who can assist if the legal stakes escalate.
Your ability to guide them through this process—not with fear, but with structured, proven agency accessibility solutions—can turn a stressful moment into a stronger long-term relationship.

Helpful tone: “You’re not the first to face this, and you’re not on your own. Let’s take smart steps together.”

Make Agency Accessibility Solutions the Default

Ultimately, accessibility should be a standard part of how your agency delivers quality websites—not a surprise line item or reactive fix.

By talking about agency accessibility solutions early and revisiting them often, you’re helping clients:
- Avoid costly legal issues
- Reach broader audiences
- Improve overall usability and performance
- Build reputations as inclusive, thoughtful brands
You don’t have to be an accessibility expert on day one. But you do need to know when—and how—to start the conversation.

Because accessibility isn’t just good practice. It’s good business. And it shows that your agency isn’t just building websites—you’re building experiences that work for everyone.

Ready to Make Accessibility Part of Your Process?

At 216digital, we help agencies like yours turn accessibility into a strategic advantage. From audits to remediation, monitoring to team training, we offer flexible solutions that scale with your projects and support your client relationships.

Schedule an ADA briefing with 216digital, and let’s make every build a little more inclusive—together.
Greg McNeil

June 27, 2025

Testing & Remediation

Accessibility, Accessibility Audit, Accessibility testing, agency accessibility solutions, digital agency, Website Accessibility
Build Accessibility In, Don’t Bolt It On
A brand-new website can feel polished and future-proof—right up until someone with a screen reader runs into a dead-end menu or a keyboard user can’t tab past the hero banner. Suddenly the “finished” project is back on the operating table, costing hours (and budget) you’d already spent elsewhere.

When accessibility planning is woven into the first brainstorm—alongside color palettes, user flows, and content themes—those last-minute scrambles disappear. Decisions get crisper, code stays cleaner, and every visitor, regardless of ability, enjoys the same smooth path through your pages.

Think of accessibility less as decorative trim and more as the blueprint that holds the whole structure together. Start with it, build on it, and you’ll launch faster, spend less, and welcome more people from day one.

What Does “Bolting It On” Look Like?

Many organizations treat accessibility like a retrofit. The site is already built, the design is approved, and the content is live. Only then does someone say, “Wait—what about screen reader support? What about color contrast? What if this form can’t be used with a keyboard?”

Now you’re in damage control. Fixing accessibility issues post-launch can require rewriting code, redesigning components, and delaying updates. Even worse, you may be stuck with baked-in barriers that are difficult or costly to correct. For example:
- Rebuilding menus that were designed without keyboard navigation in mind
- Rewriting interactive components that don’t support screen readers
- Replacing an entire color palette because contrast ratios fail WCAG
Accessibility planning means thinking about inclusion as you sketch wireframes, select a CMS, or build your first component. It means your developers write semantic HTML, your designers test color contrast before finalizing a palette, and your content creators write with clarity and structure.

When accessibility planning is part of the DNA of your project, you get better results—faster and with fewer surprises.

Accessibility Planning = Smart, Strategic Design

Now imagine the opposite scenario: your team is starting a new project or redesign. Right at the beginning, you ask:
- Who are our users, and what diverse needs do they have?
- Are we designing this interface to be usable without a mouse?
- Can our color and font choices work for users with low vision or dyslexia?
- Are we writing alt text for images, and using descriptive link text?
- Is this form easy to complete using assistive technology?
These questions don’t slow you down. They guide your decisions from the ground up.

Accessibility planning means thinking about inclusion as you sketch wireframes, select a CMS, or build your first component. It means your developers write semantic HTML, your designers test color contrast before finalizing a palette, and your content creators write with clarity and structure.

When accessibility is part of the DNA of your project, you get better results—faster and with fewer surprises.

6 Stages Where Accessibility Belongs

Here’s how to build accessibility into your process, stage by stage:

1. Discovery and Strategy

Before any code or design work begins, include accessibility planning as a strategic priority. Define your target users, including those with disabilities. Document accessibility goals and requirements as part of your project scope.

Make accessibility a deliverable—not an afterthought.

2. UX and Visual Design

Design with inclusivity in mind. That means:
- High contrast color palettes
- Clear visual hierarchy
- Large, legible typography
- Components that look good and function well with assistive tech
- Clear focus indicators and logical navigation
Don’t assume visual design is just aesthetics—it impacts usability for everyone.

3. Content Creation

Content creators play a major role in accessibility planning. They should:
- Use descriptive headings and meaningful subheadings
- Write clear, concise link text (“Download the annual report” instead of “Click here”)
- Provide transcripts or captions for audio and video
- Write meaningful alt text for important images
Training your content team on accessibility saves hours of rewriting down the road.

4. Front-End Development

This is where accessibility really comes alive. Developers should use:
- Semantic HTML (correct use of <nav>, <button>, <label>, etc.)
- ARIA labels only when needed—not as a shortcut for poor structure
- Keyboard operability for all interactive elements
- Logical tab order and skip navigation links
Accessibility-friendly code isn’t just better for screen readers—it’s more resilient, scalable, and SEO-friendly too.

5. Testing and QA

Accessibility testing isn’t just automated. While tools like Lighthouse, or WAVE help flag obvious issues, real users and manual testing are critical.
- Test with screen readers like NVDA or VoiceOver
- Navigate your site using only a keyboard
- Check forms for proper labels and error handling
- Test responsiveness and zoom up to 200%
Bring in users with disabilities if possible. Their feedback is irreplaceable.

6. Launch and Maintenance

Accessibility doesn’t stop at launch. It’s an ongoing effort. As you add new features or content, revisit your accessibility standards. Schedule regular audits. Monitor legal developments. Consider automated tools like a11y.Radar for early issue detection.

The Human Side of Accessibility

It’s easy to talk about accessibility in technical terms, but at its core, it’s about people.

Think about someone using a screen reader to access your site. Or someone with motor limitations who can’t use a mouse. Or someone dealing with temporary impairments—a broken wrist, eye strain, or even just a noisy environment where audio isn’t practical.

Building accessibility in from the start isn’t about compliance for its own sake. It’s about treating all users with dignity. It’s about believing that digital spaces should work for everyone, regardless of ability.

Common Pitfalls to Avoid

Even with good intentions, teams can fall into these traps:
- Assuming accessibility is only the developer’s job: Accessibility is a shared responsibility across design, content, and engineering.
- Waiting until the QA phase: Accessibility can’t be “tested in” at the end. It must be designed and developed.
- Relying too much on overlays or plugins: Widgets don’t fix inaccessible code. In some cases, they create more problems than they solve.
- Failing to document decisions: Keep a living accessibility checklist. It helps ensure continuity across teams and updates.
Why It Pays Off

Here’s what you gain when you build accessibility in from day one:
- Faster development: Fewer reworks, cleaner code
- Lower costs: Avoid costly redesigns and retrofits
- Happier users: Better usability for everyone, not just people with disabilities
- Improved SEO: Accessibility often overlaps with search best practices
- Reduced legal risk: Stay ahead of ADA and state-level laws like Colorado HB 21-1110
- Stronger brand reputation: Inclusion signals leadership and care
Most importantly, you build a digital presence that welcomes, respects, and serves more people exactly like the web was meant to work.

No Ifs, Ands, or Bugs—Just Accessibility Plans

Accessibility doesn’t belong on a post-launch checklist or in a future phase that never quite gets prioritized. It belongs at the table from day one—when you’re mapping out user journeys, designing components, and writing your very first lines of code.

By making accessibility planning a core part of your workflow, you avoid costly rework, improve overall quality, and create digital experiences that serve more people, more effectively. It’s not about adding more to your plate—it’s about building smarter from the start.

If you’re ready to move from fixing to future-proofing, 216digital can help. Our phased accessibility services are designed to meet you where you are, guide your team, and strengthen your site’s foundation for the long haul. Let’s make accessibility part of how you build—every time.
Greg McNeil

June 20, 2025

Testing & Remediation

Accessibility, Accessibility Remediation, Accessibility testing, Web Accessibility, Web Accessibility Remediation, web development
Custom Accessibility Audits: Tailored for Your Website
Most websites aren’t trying to be inaccessible—it just kind of happens. A few plugins here, a third-party widget there, and before you know it, people using screen readers or keyboard navigation are hitting roadblocks you didn’t even know were there.

If you’ve ever felt unsure about where your site stands or thought, “We added a tool—so we’re probably fine,” you’re not alone. But the truth is, real accessibility takes more than a one-click solution. It takes intention, testing, and a plan. And with digital accessibility lawsuits on the rise, ignoring the gaps is more of a liability than ever.

If staying ADA-compliant is your goal, you need more than a quick fix. You need custom accessibility audits, meaningful remediation, and a partner who can help you maintain compliance long-term.

The Real Limitations of Automation Tools

Automated accessibility tools are everywhere, and it’s easy to see the appeal. They promise a quick scan and some instant fixes—like adding alt text, adjusting colors, or offering a text-size toggle. It feels like progress. But these tools can only go so far.

They often miss what really matters: how someone with a disability actually uses your site. Screen readers, keyboard navigation, and cognitive-friendly layouts aren’t things most automation can truly understand or evaluate.

What They Miss (And Why It Matters)

Here are a few areas where automation usually falls short:
- Screen reader experiences: Automated tools won’t tell you if your navigation makes sense when read aloud.
- Keyboard usability: They don’t catch when menus or popups trap users who don’t use a mouse.
- Structural clarity: Bad heading structures or mislabeled buttons often go unnoticed.
- Interactive elements: Modals, forms, and sliders might work visually but break down when tested for accessibility.
Even more concerning? Courts are increasingly ruling that automation alone doesn’t meet ADA requirements. In some cases, relying on overlays without fixing underlying issues can actually increase your legal risk—especially for busy sites that handle transactions. This is why custom accessibility audits remain the gold standard for identifying real, user-impacting issues.

Why Real Testing Still Matters

You can’t fix what you don’t experience—and that’s the heart of manual testing. It’s not just about running a tool and checking boxes. It’s about walking through your site the way someone with a disability might.

That means:
- Navigating with a keyboard and nothing else.
- Using a screen reader to browse your content.
- Testing user flows like logging in, searching, or checking out—without assuming the user can see or use a mouse.
The Kind of Issues Manual Testing Uncovers

This type of testing uncovers issues that automation never will:
- Dropdowns that don’t announce themselves
- Buttons that lack clear, descriptive labels
- Interactive sections that lose focus or confuse navigation
- Forms that look fine visually but are hard to use with assistive tech
At 216digital, we don’t just skim the surface. During custom accessibility audits, we follow real user journeys—from homepage to checkout—so we can see how the experience actually holds up. It’s not about passing a test. It’s about making sure everyone can use your site smoothly.

What Custom Accessibility Audits Really Looks Like

Once you know what’s broken, fixing it takes more than flipping a switch. True remediation means tailoring fixes to your site’s layout, content, and functionality—not applying a generic patch.

That’s why we focus on changes that make a measurable difference for real users. Things like:
- Making sure users can see where their keyboard focus is at all times
- Adding ARIA roles and labels so screen readers can understand what’s on the page
- Improving contrast without compromising your brand’s look
Examples of Targeted Fixes

We also fix the kinds of problems that create the most user friction:
- Popups and modals that trap keyboard or screen reader users
- Sliders or videos that move too quickly without user control
There’s no one-size-fits-all approach. Each website is different. Each problem needs a thoughtful, code-aware fix. That’s where custom remediation stands apart—it solves the right problem in the right way.

Keeping Accessibility on Track with a11y.Radar

Accessibility isn’t something you do once and forget about. Websites change—new content, new plugins, new designs—and with those changes come new risks.

That’s where our ongoing monitoring tool, a11y.Radar, makes the difference.

It acts like a digital safety net by:
- Running regular scans to check for new or recurring issues
- Prioritizing problems based on what’s most important to fix first
- Providing clear reports that your team can actually understand and act on
- Using the same scanning methods many law firms rely on before filing lawsuits
Stay Ahead, Don’t Fall Behind

Think of it like maintenance for your website’s health. You wouldn’t skip oil changes for your car—and keeping your site accessible works the same way. a11y.Radar helps you stay proactive so small issues don’t turn into bigger problems later. And when paired with custom accessibility audits, you gain a complete strategy for long-term digital compliance.

Why Visibility Increases Your Risk

The more visible your business becomes, the more pressure there is to get accessibility right.

In just May alone, 445 new digital accessibility lawsuits were filed in the U.S.—many aimed at online retailers, especially those using Shopify or WooCommerce. These platforms offer convenience, but often rely on templates or plugins that haven’t been fully tested for accessibility.

The Real-World Consequences

It’s not personal—these lawsuits are often triggered by bots scanning the web for compliance issues. If your site trips a red flag, it could end up on a law firm’s radar.

The risks are real:
- Expensive legal battles or settlement costs
- Strained customer trust
- Hits to your brand reputation
- Increased insurance premiums
The upside? When you invest in custom accessibility audits and monitoring, you dramatically lower your risk—and build a better experience for every user.

Beyond Legal Advice: Why You Need Technical Support

A good legal team can help you understand where you’re exposed. But they won’t fix your navigation, rewrite your forms, or troubleshoot your ARIA labels.

That’s where a hands-on partner makes the difference.

What a Technical Accessibility Partner Does

At 216digital, we’ve supported hundreds of websites—small shops and enterprise platforms alike. Our approach is practical, technical, and built around real-life use cases. We don’t just tell you what’s wrong—we fix it, explain it, and set you up to manage accessibility long-term.

Here’s what we bring to the table:
- Clear developer guidance tailored to your platform
- Integrated testing and remediation that fits into your current workflow
- Ongoing support and monitoring after the fixes are live
It’s not about being perfect—it’s about building lasting accessibility habits. And having a partner who helps you stay on track.

Accessibility Isn’t Obligation—It’s Opportunity

It’s your chance to build a brand that’s genuinely inclusive, appealing to a wider audience and avoiding costly legal pitfalls. Automation tools alone won’t get you there, but custom accessibility audits, hands-on remediation, and proactive monitoring will.

If you’re done guessing and ready to confidently say your site is accessible, reach out to us at 216digital. We’ll clearly show you where your site stands, guide you through practical improvements, and keep accessibility effortless and ongoing. Because ultimately, making your website accessible isn’t just smart—it’s the kind of thoughtful action your customers will notice and appreciate.
Greg McNeil

June 17, 2025

Testing & Remediation

Accessibility, Accessibility Remediation, Accessibility testing, automated testing, custom accessibility audits, Manual Testing, Web Accessibility, Web Accessibility Remediation, Website Accessibility
How to Conduct Accessibility User Testing
You can pass every automated test and still fail your users. That’s the uncomfortable truth behind many accessibility initiatives. True accessibility goes far beyond technical compliance—it’s about how people actually experience your product. Accessibility user testing isn’t a last-minute box to check; it’s a powerful way to build digital experiences that work for everyone.

In this article, we’ll walk you through how to conduct accessibility user testing in a way that’s respectful, strategic, and truly impactful. Whether you’re a UX professional, web developer, or product manager, you’ll leave with clear, practical guidance to take your testing process from good intentions to real results.

What Automated and Manual Testing Miss

Accessibility tools like Google Lighthouse and WAVE are fantastic for catching code-level issues—missing alt text, low contrast, missing labels. But that’s just the surface. These tools don’t understand user intent. They can’t tell if your focus order makes sense, or if a screen reader user can actually make sense of your modal flow.

Manual testing helps fill some of those gaps. Keyboard-only navigation, zoom testing, and screen reader simulations can uncover a lot—especially when done by experienced testers. But even this falls short of the lived experience.

Take a modal dialog as an example. You might trap focus correctly, label everything with ARIA, and pass every automated check. But in practice? A screen reader user may still struggle because the modal doesn’t announce in the expected order or re-focus correctly on close. That’s the kind of thing only accessibility user testing with real people can reveal.

Why User Testing with People with Disabilities Is the Game-Changer

No simulation can match the perspective of someone who uses assistive tech every day. People who rely on screen readers, switch devices, or voice navigation uncover friction and failure points that even seasoned accessibility professionals can overlook.

Here’s the shift: stop thinking of users with disabilities as edge cases. They’re not. They’re part of your audience—your customers, students, patients, or users. Designing for them improves your product for everyone.

Accessibility user testing isn’t just about catching bugs. It’s a critical feedback loop that improves usability, product-market fit, and even innovation. When you integrate it early and often, you don’t just “fix accessibility”—you build better experiences from the ground up.

Planning Your Accessibility User Testing Program

Define Clear Objectives

Start with real-world tasks. Instead of running a general audit, design your tests around meaningful user journeys:
- Is it possible for a blind user to complete a purchase from start to finish?
- Someone with low dexterity—can they successfully submit your job application form?
- And what about users with cognitive differences—can they easily locate your support content?
Clear, task-based goals help you focus your sessions and gather actionable insights.

Build a Representative Participant Pool

Many teams fall into the trap of testing only with blind screen reader users. That’s important—but not enough.

To make your testing inclusive:
- Include participants with motor impairments, cognitive disabilities, low vision, and voice input users.
- Recruit from diverse sources and advocacy organizations.
- Pay your testers. Always. Accessibility user testing is specialized work and should never rely on free labor. Follow ethical compensation practices and provide flexible scheduling and support.
Pre-Test Logistics and Respectful Setup

Before the session, send a tech-check checklist to participants. This might include browser compatibility, assistive tech setup, and ensuring a quiet space.

Also, ask about accommodations in advance:
- Do they prefer screen sharing or phone interviews?
- Do they need additional time?
- Would they like the questions in advance?
Offering flexible formats—remote, hybrid, or in-person—ensures participants can engage comfortably. Respect starts with planning.

Running Meaningful and Inclusive Testing Sessions

Session Structure That Works

Start with a warm-up task or small talk to ease anxiety and build trust. Remember, this isn’t a test of the participant—it’s a test with them.

Structure your session around a few focused tasks. Example:
- “Please use the site to find and register for a webinar.”
- “Try to contact customer support using your preferred method.”
Observe closely—but don’t interrupt unless necessary. Let participants narrate their thought process if they’re comfortable. This gives you insight into confusion points, workaround strategies, and breakdowns in usability.

Accessibility user testing is about listening. Often, the most valuable insights come not from what users can or can’t do, but from the effort it takes them to do it.

Ask Thoughtful, Open-Ended Questions

Instead of “Did that work for you?” try:
- “How did that process feel?”
- “What was easy or hard about that task?”
- “Was there anything that surprised or confused you?”
Create space for honest feedback, and resist the urge to jump in with fixes. Your goal is to understand, not defend.

From Feedback to Action

Once your accessibility user testing sessions are complete, consolidate your notes into themes. What barriers kept coming up? Were there recurring moments of friction?

Tag issues by severity and impact. Some will be quick fixes—labeling buttons, adjusting tab order. Others may require bigger design shifts. Either way, track them in your product backlog and prioritize them alongside other critical bugs.

Also, share findings with your team. Make video clips or quotes part of your sprint reviews or design critiques. Seeing real users struggle—or succeed—can be a powerful motivator for accessibility buy-in across your organization.

Make It Part of Your Process

Accessibility user testing isn’t a one-off effort. Integrate it into every major phase of development:
- Early design prototypes
- Beta versions before release
- Major feature updates
The earlier you involve users, the more you catch—and the less expensive it is to fix. Consider building an accessibility testing panel you can tap into regularly. Make it part of your QA cycle, not just a compliance afterthought.

User-Tested, People-Approved

Automated tools and manual audits are important—but they only take you so far. To build truly inclusive experiences, you need to go deeper. Accessibility user testing gives you something no tool ever will: real human insight.

By listening to and designing with people with disabilities, you move from compliance to compassion. From checking boxes to opening doors. From good enough to genuinely excellent. And that’s not just better accessibility—it’s better UX, period.

If you’re ready to elevate your accessibility strategy with meaningful user feedback, 216digital can help. Schedule an ADA briefing with our accessibility team to discuss how user testing fits into a comprehensive, long-term solution. Together, we’ll help you build experiences that work for everyone—starting now.
Greg McNeil

June 13, 2025

Testing & Remediation, Uncategorized

Accessibility testing, Manual Testing, User Experience, user testing, Users experience, Web Accessibility Remediation
Law Firms Aren’t Built for Accessibility Remediation Services
When a demand letter lands in your inbox, or an ADA-related lawsuit hits your desk, your first thought might be to call a lawyer. That’s a natural reaction—after all, legal issues usually call for legal help.

But here’s where things get a little more complicated: if the problem is your website’s accessibility, then legal advice alone won’t fix it. And that’s where many businesses take a wrong turn. Legal teams can guide you through the paperwork, but they’re rarely the ones who dig into your code, address the real barriers, or help you prevent the next lawsuit.

This article walks you through why relying on a law firm to handle accessibility remediation services might not be the best move—and what a smarter, more effective approach looks like.

The Problem: Law Firms Handle Lawsuits—Not Code

Let’s be clear—attorneys have an important role. If you’ve received a demand letter or lawsuit, they can help you respond, negotiate, or represent you in court. But legal involvement doesn’t make the accessibility problem go away. The root issue—your website not working for people with disabilities—still remains. And it’s that issue that continues to carry legal and reputational risk.

Most law firms don’t have in-house technical teams. No developers, no certified accessibility experts, no usability testers. So what happens? They either outsource the actual accessibility remediation services to third-party vendors (often charging a premium along the way) or provide high-level reports filled with checklists that leave your dev team guessing at what to do next.

That means you’re still on the hook for the real work—and possibly paying more for it.

Hidden Risk #1: You’ll Pay More for Less

Law firms typically charge by the hour, which makes sense for legal tasks like reviewing contracts or negotiating settlements. But when they apply those same rates to accessibility-related work—such as interpreting WCAG guidelines, coordinating with vendors, or reviewing audit summaries—it turns into a costly game of telephone.

You end up paying for layers of administrative overhead that slow down progress and don’t actually improve your website.

Worse, you might not even realize where the money is going. Legal fees can pile up quickly without producing the tangible results your business actually needs: a compliant, accessible, functional website. For small to mid-size organizations trying to manage both compliance and budget, this model is hard to justify.

Hidden Risk #2: The Fixes May Not Be Complete

Fixing accessibility isn’t about running a quick scan and addressing a handful of errors. Real remediation requires technical precision, contextual judgment, and manual testing—especially with screen readers and keyboard navigation. It involves understanding how accessibility issues present in code and how they affect the user experience for people with different disabilities.

Many law firms don’t have the tools—or the trained personnel—to go that deep. And their vendor partners often lean heavily on automated tools that only catch surface-level issues.

Here’s what that kind of partial remediation can miss:
- Form fields without accessible labels
- Improper heading structures that confuse screen readers
- Modal windows that can’t be closed without a mouse
- Buttons or links that don’t receive keyboard focus
- Dynamic content changes that don’t alert assistive technologies
These aren’t fringe cases—they’re exactly the kinds of issues that trigger lawsuits. Unfortunately, teams often overlook them when legal experts, rather than technical specialists, lead accessibility remediation efforts.

Hidden Risk #3: No Plan for the Long Term

Even if your legal team manages to patch things up for now, accessibility isn’t a one-and-done situation. Websites evolve. New content is added. Platforms update. If you don’t have an ongoing plan, you risk falling out of compliance all over again—and landing back in legal trouble.

Law firms are built for casework, not for long-term technical oversight. Most won’t offer monitoring services, provide training for your content team, or stay engaged as your digital properties change over time. Without a partner who understands how to maintain accessibility remediation services, you’re left exposed.

That’s why sustainable compliance calls for a proactive strategy—one that goes beyond legal checkboxes and focuses on real-world usability, continuous improvement, and future-proofing your site.

What Proper Accessibility Remediation Services Look Like

To address ADA compliance issues the right way, you need more than legal advice—you need a full-service accessibility team that knows how to diagnose, prioritize, and implement lasting solutions.

Here’s what effective accessibility remediation services typically involve:

1. In-Depth Accessibility Audit

Experienced accessibility professionals start by reviewing your site against WCAG 2.1 A/AA standards using both automated and manual testing. This ensures nothing gets missed. A proper audit covers the following:
- Screen reader testing using tools like NVDA, JAWS, or VoiceOver
- Keyboard-only navigation analysis
- Color contrast checks
- Semantic HTML review
- ARIA role validation for dynamic content
It’s this level of testing that uncovers real usability barriers.

2. A Clear, Actionable Roadmap

Instead of a vague checklist, a solid remediation team will provide a prioritized list of issues, each translated into plain language with clear technical recommendations. The goal is to make it easy for developers to understand what needs to be fixed—and how.

3. Code-Level Fixes

This is the heart of remediation. A professional team doesn’t just point out problems—they roll up their sleeves and solve them. That includes adjusting templates, improving focus states, rewriting inaccessible components, and ensuring your code structure supports screen readers and keyboard navigation.

It’s hands-on work—and it requires skilled front-end developers who understand both accessibility and UX.

4. Real-World Usability Testing

After you make changes, your work isn’t done. Test the updated site again—this time in real-world scenarios using assistive technologies. This step confirms that your remediation efforts actually work for the people they’re designed to support.

5. Documentation & Legal Support

While not a substitute for a legal team, many remediation partners provide helpful documentation—such as accessibility statements, conformance reports (like VPATs), and audit results—that demonstrate your organization’s commitment to accessibility. These materials can also support your response if you’re facing legal scrutiny.

6. Ongoing Monitoring

Even after remediation, your site should be monitored regularly. A good partner will offer scanning tools like a11y.Radar for testing and alerts to catch issues early—before they turn into compliance risks.

Why Accessibility Professionals Are the Better Fit

Accessibility specialists solve the actual problem: they make websites usable for people with disabilities. They work closely with your development, design, and content teams to create solutions that align with your brand, support your UX goals, and meet compliance requirements.

Unlike law firms, accessibility pros don’t just help you react—they help you prepare. Their job is to prevent problems, not just manage them after the fact.

They bring technical knowledge, lived user experience insights, and a collaborative mindset to the table. That’s how you get lasting results—not just legal coverage, but a stronger, more inclusive digital presence.

Conclusion: The Smart Path to Lasting Compliance

If you’re navigating legal pressure because of an inaccessible website, it’s important to act quickly—but also wisely. Legal teams play a role, yes, but true ADA compliance requires more than legal documents and advice. It takes technical expertise, accessibility remediation services, and a long-term plan that goes beyond checking boxes.

The right partner doesn’t just help you respond to a lawsuit—they help you prevent the next one by making your website genuinely usable for everyone. That means fewer legal risks, stronger user trust, and a better experience across the board.

At 216digital, we specialize in real solutions—not just legal responses. From WCAG audits and code-level fixes to usability testing and ongoing monitoring, we help you build and maintain a site that works for everyone.

Schedule an ADA briefing with our accessibility team today to get clear, honest guidance on what your site needs, what’s at risk, and how to move forward confidently. Let’s make your compliance efforts count—for your users and your business.
Greg McNeil

June 4, 2025

Legal Compliance

Accessibility, Accessibility Remediation, Accessibility testing, ADA Compliance, WCAG, Web Accessibility, Web Accessibility Remediation, Website Accessibility

What Remediation Really Looks Like

Where ChatGPT Earns Its Keep

The Problem of “No Opinion”

The Hidden Cost of “Free”

Why Human-Led Web Accessibility Remediation Still Matters

How to Use AI the Right Way (With Guardrails)

What You Actually Get from Professional Remediation

AI Doesn’t Make Judgment Calls—People Do

Why Ongoing Accessibility Monitoring Matters (Even After You “Pass”)

Why You Can’t Rely on Users (Or Automation) Alone

Free Browser Tools: What Are They and Where They Fall Short

Where Free Web Accessibility Tools Fall Short

The Hidden Costs of “Free”

Risk and False Confidence

The Retrofit Tax

What Paid Accessibility Monitoring Adds That Free Tools Can’t

Turning Findings Into Action

Scaling Without Burning Out Your Team

A Practical Way to Decide: Budget, Scale, Confidence

Why a Hybrid Strategy Often Wins

a11y.Radar: Ongoing Accessibility Monitoring, Minus the Guesswork

How a11y.Radar Works Day to Day

Human Expertise and Real-World Impact

How to Choose Your Monitoring Setup (and Whether You Need One)

How to Interpret Your Answers

FAQs: Common Questions About Accessibility Monitoring

Remediation Makes You Compliant—Accessibility Monitoring Keeps You There

What Automated Platforms Do Well

The Role of Accessibility Consultants

Why Consultant-Led Remediation Should Come First

When Automated Platforms Make Sense

How to Decide What’s Right for You

The Long-Term Payoff

Human First, Automation Second

What Is a VPAT?

Who Needs a VPAT?

Which VPAT Version Should You Use?

Core Elements of a VPAT

Tips for Filling Out a VPAT

Why VPATs Matter Beyond Legal Compliance

Closing Thoughts

Why Accessibility Testing Belongs in the Sprint

Shift Accessibility Left: Early Planning Wins

1. Include Accessibility in User Stories

2. Define Acceptance Criteria

Build Accessibility into Design

3. Collaborate with Designers

4. Run Design Reviews

Develop With Accessibility in Mind

5. Use Accessible Components

6. Lint for Accessibility

7. Write Semantic HTML

Make Testing Part of the Flow

8. Automated Accessibility Tests

9. Manual Testing in Sprint

Retrospectives: Keep Improving

Tips for Getting Started (or Leveling Up)

Don’t Bolt It On—Build It In

Need Help Fitting Accessibility Into Your Workflow?

Start the Conversation About Agency Accessibility Solutions

Revisit It During Design Reviews

Build Accessibility into Development (Not After)

Post-Launch Is Just the Beginning

When Legal Risk Enters the Chat

Make Agency Accessibility Solutions the Default

Ready to Make Accessibility Part of Your Process?

What Does “Bolting It On” Look Like?

Accessibility Planning = Smart, Strategic Design

6 Stages Where Accessibility Belongs

1. Discovery and Strategy

2. UX and Visual Design

3. Content Creation

4. Front-End Development

5. Testing and QA

6. Launch and Maintenance

The Human Side of Accessibility

Common Pitfalls to Avoid

Why It Pays Off

No Ifs, Ands, or Bugs—Just Accessibility Plans

The Real Limitations of Automation Tools