216digital.
Web Accessibility

ADA Risk Mitigation
Prevent and Respond to ADA Lawsuits

WCAG & Section 508
Conform with Local and International Requirements

a11y.Radar
Ongoing Monitoring and Maintenance

Consultation & Training

Is Your Website Vulnerable to Frivolous Lawsuits?
Get a Free Web Accessibility Audit to Learn Where You Stand
Find Out Today!

Web Design & Development

Marketing

PPC Management
Google & Social Media Ads

Professional SEO
Increase Organic Search Strength

Interested in Marketing?
Speak to an Expert about marketing opportunities for your brand to cultivate support and growth online.
Contact Us

About

Blog

Contact Us

  • Escape the Accessibility Audit Shopping Loop

    You probably know the pattern.

    A demand letter arrives, or leadership decides it is time to “do something” about accessibility. Your team sends out a few RFPs, collects quotes, and picks a vendor to run an accessibility audit. A long report lands in your inbox. There is a burst of activity… and then daily work takes over again.

    Months later, a redesign launches, a new feature goes live, or a new legal threat appears—and you are right back where you started. New quotes. New confusion. New pressure.

    That’s the accessibility audit shopping loop: chasing one-off audits that feel busy and expensive, but don’t actually create lasting accessibility or meaningful legal protection. It is not a sign that you are doing anything wrong. It’s a sign that the way our industry sells accessibility nudges you toward short-term reports rather than long-term results. You can absolutely break this pattern—but it requires rethinking what an “audit” is for, how you evaluate proposals, and how accessibility fits into your long-term digital strategy.

    Why a One-Off Accessibility Audit Falls Short

    An audit can be useful. It can show you where some of your biggest barriers are and help you start a serious conversation inside your organization. But when an accessibility audit is treated as a one-time project, it rarely delivers what people think they are buying.

    1. A Snapshot In a Moving World

    Your site isn’t still. New campaigns launch. Content changes. Forms get updated. Third-party tools are added. A report finished in March may be out of date by June.

    If your whole plan is “we will fix this report, and then we are done,” you are treating accessibility like a static task. In reality, it behaves more like security or performance. It needs regular attention.

    2. Reports Without a Real Path Forward

    Many teams receive thick PDFs packed with screenshots and WCAG citations. On paper, it looks impressive. In practice, it can be hard to use.

    Without clear priorities and practical examples, teams are left asking what to fix first, how long it will take, and who owns which changes. When those questions go unanswered, work pauses. Other projects win. Leadership starts to think accessibility is “too big” or “too costly,” when the real issue is that the report never turned into a plan.

    3. Gaps In Scope That Leave Risk Behind

    Some audits only look at a small set of pages. Others skip key journeys like checkout, registration, password reset, or account management. Some focus on desktop and treat mobile as optional. Many rely heavily on automated tools.

    On the surface, it may seem like you “covered the site.” But important user journeys and assistive technology use can remain untested. That means real people can still run into serious barriers, even while you hold a report that says you made progress.

    4. Little Connections To Real Users

    When the work is driven only by checklists, it is easy to miss how people with disabilities actually move through your site.

    A tool might say “Form field is labeled,” yet a screen reader user may still hear a confusing sequence of instructions. Keyboard users might tab through a page in a way that makes no sense. An audit that does not consider real user journeys and assistive technologies can help you pass more checks, but still leave key tasks painful or impossible.

    How to Read an Accessibility Audit Proposal

    Breaking the loop starts before you sign anything. The way you read proposals shapes what happens next. When a vendor sends a proposal for an accessibility audit, you should be able to see what they will look at, how they will test, and how your team will use the results.

    1. Look For a Clear, Meaningful Scope

    A strong proposal spells out which sites or apps are in scope, which user journeys will be tested from start to finish, which assistive technologies and browsers are included, and which standards they map findings to, such as WCAG 2.1 AA.

    If all you see is “X pages” or “Y templates,” ask how they chose them and whether those paths match your highest-risk flows, like sign-up, checkout, or account settings.

    2. Ask For Transparent Testing Methods

    You do not need to be an expert to ask good questions. How do you combine automated tools with manual testing? Do you test with real assistive technologies, such as screen readers and magnifiers? How do you check keyboard access, focus order, and error handling? Do you ever test with people who use assistive technology every day?

    You’re looking for a process that feels like real use, not just a tool report with a logo on top.

    3. Focus On What An Accessibility Audit Actually Delivers

    Do not stop at “You will receive a PDF.” Ask to see a sample. Look for a prioritized list of issues with clear severity levels, along with code or design examples that illustrate the problem and a better pattern. A simple remediation roadmap that points out where to begin—and options for retesting or spot-checks after fixes are in place—will help your team actually move from findings to fixes.

    If the deliverables section is vague, your team may struggle to turn findings into action later.

    4. Confirm Real, Relevant Expertise

    Ask who will do the work and what experience they have. Helpful signs include familiarity with your tech stack or platform, experience in your industry or with similar products, and a mix of skills: auditing, engineering, design, and lived experience with disability.

    You are choosing the judgment of people, not just the name on the proposal.

    Using Each Audit on Purpose

    The goal is not to stop buying audits. It is to stop buying them on autopilot.

    Pressure to “get an audit” usually shows up for a reason: legal wants evidence of progress, leadership wants to reduce risk, or product teams need clearer direction. Those are all valid needs—but they do not all require the same kind of work.

    Treat every new accessibility audit as a tool with a specific job. For example, you might use an audit to:

    • Validate a major redesign before or just after launch.
    • Take a focused look at a critical journey, like checkout or application submission.
    • Test how well your design system or component library holds up in real use.
    • Measure progress after a concentrated round of fixes.

    When you frame an audit around a clear question—“What do we need to know right now?”—it becomes one step in a longer accessibility journey instead of the entire plan. It also makes it easier to set expectations: an audit can confirm risks, reveal patterns, and guide priorities, but it cannot, by itself, keep a changing product accessible over time.

    Beyond the Accessibility Audit: Building Accessibility Into Everyday Work

    To truly escape the loop, audits have to sit inside a larger approach, not stand alone.

    1. Give Accessibility a Clear Home

    Start with ownership. Someone needs clear responsibility for coordinating accessibility efforts, even if the hands-on work is shared. That anchor role keeps priorities from getting lost when other projects get loud.

    2. Thread Accessibility Through Your Workflow

    Accessibility should show up at predictable points in your lifecycle, not just at the end:

    • Design and discovery: Bring in accessible patterns, color contrast, and interaction models early so you are not “fixing” basics right before launch.
    • Development and QA: Add simple accessibility checks to your definition of done and test plans, so issues are caught while code is still fresh.
    • Content and marketing: Give writers and editors straightforward guidance on headings, links, media, and documents so everyday updates stay aligned.

    Reusable, vetted components and patterns make this easier. When your design system embeds strong semantics, keyboard behavior, and clear focus states, every new feature starts on a stronger footing.

    3. Watch for Regressions Before Users Do

    Light monitoring—through tools like a11y.Radar, spot checks, or both—helps you catch problems between deeper reviews. Instead of waiting for complaints or legal notices to reveal a broken flow, you get early signals and can respond on your own terms.

    Over time, this turns accessibility from an emergency project into part of how you build and ship. The payoff is steady progress, fewer surprises, and better experiences for everyone who depends on your site.

    Stepping Off the Accessibility Audit Treadmill

    An audit still has a place in a healthy accessibility program. But it should not be the only move you make every time pressure rises.

    When you choose vendors based on clear methods and useful deliverables, question the idea that a single report will “make you compliant,” and build accessibility into daily work, you move from a cycle of panic and paper to a steady, durable program.

    At 216digital, we’re ready to help you transition from one-off accessibility audits to an ongoing, effective accessibility program. If you want to move beyond endless audit cycles and build accessibility into your digital products for good, contact us today to start your journey with expert support.

    Greg McNeil

    December 8, 2025
    Testing & Remediation
    Accessibility Audit, Accessibility testing, automated testing, manual audit, Web Accessibility, Website Accessibility

  • The When, Where & Why of Your Web Accessibility Audit

    When your team discusses accessibility, the same questions come up: When should we audit? Where should we focus? Why prioritize accessibility amid so many competing demands?

    Inside most organizations, it is not a lack of concern that slows things down. Designers, developers, product, and marketing all care about getting this right—but between deadlines, releases, and stakeholder requests, accessibility work often feels like something you will “get to” once things calm down. A web accessibility audit can either feel like one more demand on already stretched teams or like the moment things finally get some structure and direction.

    The difference is how you approach it.

    Used well, an audit is less about producing a thick report and more about answering a few practical questions: What should we look at first? Which issues really matter for real users and real risk? How do we apply what we learn to make better decisions release after release, rather than only reacting when something goes wrong?

    What a Web Accessibility Audit Really Looks Like in Practice

    At its simplest, an accessibility audit is a close look at your site, app, or digital product to identify barriers that prevent people with disabilities from using it. Most audits measure your experience against the Web Content Accessibility Guidelines—currently WCAG 2.2—at Levels A and AA. That gives everyone a shared frame of reference, from designers and engineers to legal and procurement.

    But the most useful audits don’t feel like abstract standards exercises. They feel grounded in real use.

    There is usually an automated pass to quickly identify common surface problems—missing alt text, color contrast issues, broken heading structures. Those tools are helpful, but they only see what they’re built to detect.

    Deeper value comes from manual testing—a person navigates your experience with a keyboard only, uses a screen reader, and checks whether form errors, focus order, dialog behavior, and dynamic content make sense.

    Sampling Your Product, Not Every Page

    Because modern sites are big and complex, most teams don’t audit every URL. Instead, they focus on a representative sample:

    • Core templates like homepage, category, product, content, and forms
    • Reusable components like navigation, modals, accordions, and filters
    • High-value journeys like sign-up, checkout, donation, or account management

    What comes out the other side is not just a list of failures. A strong web accessibility audit gives you a clear view of what’s getting in the way, who it affects, and how to fix it in terms your team can actually act on. Ideally, it also gives product owners something they can realistically schedule—not just react to.

    Why Web Accessibility Audits Are Taking Center Stage

    Legal Pressure Meets Day-to-Day Reality

    Even teams that have cared about accessibility for years are feeling the pressure sharpen. Expectations are rising—sometimes through regulation, sometimes through procurement language, and sometimes simply through customer awareness.

    Public-sector organizations now have firm WCAG-based timelines attached to their digital properties. In Europe, the European Accessibility Act is putting real dates on the calendar for accessible products and services. And even private companies not directly covered by those laws are seeing accessibility questions appear more frequently in RFPs, vendor questionnaires, and contract negotiations.

    A web accessibility audit changes those conversations. Instead of answering with intent and aspiration, you can answer with evidence: what has been tested, what has been found, and what is actively being improved.

    The Upside: UX, SEO, and Trust

    There is also a quieter upside that often matters just as much. Most accessibility improvements make experiences smoother for everyone. Cleaner structure, clearer labels, stronger focus behavior—these things reduce friction across the board. And the same semantic foundations that help screen readers also help search engines understand your content.

    For leadership teams, that combination—risk awareness, better experience, and brand credibility—is hard to ignore.

    Deciding Where to Look First

    One of the most overlooked parts of an audit is simply deciding where to begin. Not every surface deserves the same level of scrutiny on day one.

    Most teams start with the places where users and business meet:

    • Public marketing and product sites
    • Support centers and documentation
    • Logged-in dashboards and portals used by customers or employees

    Don’t Forget Documents, Media, and Third Parties

    From there, the scope often widens.

    Documents—PDFs, slide decks, forms, contracts—frequently play a bigger role in user journeys than teams expect. Video and audio content bring their own requirements around captions, transcripts, and controls. Embedded third-party tools like chat widgets, schedulers, and payment forms can introduce barriers your users will still associate with you, regardless of who built the tool.

    For organizations with design systems or shared component libraries, testing those patterns directly can be highly efficient. Fixing one modal or form pattern can improve accessibility across many screens.

    A thoughtful web accessibility audit is less about testing “everything” and more about testing the right things with intention.

    Getting the Timing Right

    The most effective audits tend to feel planned, not reactive.

    In an ideal world, audits happen before something big goes live: a new site, a redesign, a platform migration, a rebrand. When treated like performance or security testing, accessibility becomes part of the launch checklist rather than a post-launch surprise.

    In reality, many audits happen shortly after launch. And that can still be a strong move. While the project context is fresh and momentum is high, teams can identify hot spots, prioritize fixes, and show clear forward motion.

    For organizations with continuous release cycles, smaller-scoped audits tied to major features often work better than one giant annual review. For more traditional release schedules, annual or biannual audits create a steady rhythm—much like a regular security review.

    Moments That Should Trigger a Fresh Look

    There are also moments that naturally raise the stakes: an accessibility complaint, a new market with stricter rules, a framework upgrade, the rollout of a new third-party tool that touches checkout or login. Those moments often turn a “someday” audit into a “now” conversation.

    The difference between scrambling and steering, in many cases, is whether your web accessibility audit was already part of the plan.

    What Teams Experience During a Web Accessibility Audit

    For teams that haven’t gone through one before, audits can feel intimidating. In reality, the strongest ones feel collaborative.

    The audit process usually starts with discovery and scoping. Teams first discuss goals, constraints, timelines, typical traffic patterns, and the most important user experiences. Next, the team selects a representative sample based on this input. This sample guides automated and manual testing, ensuring the work is rooted in actual user scenarios.

    Once the sample is chosen, automated testing surfaces patterns and repetition, highlighting common accessibility problems. Manual evaluation follows: evaluators review how keyboard navigation, screen readers, error handling, and dynamic updates perform on the selected samples. This approach grounds the audit in real user interaction.

    From Findings to a Shared Roadmap

    The real shift happens during triage and prioritization. Instead of a flat list of issues, findings are grouped by severity, frequency, and risk. Teams start to see not just what’s broken, but where the biggest leverage lives.

    By the time reporting and handoff arrive, the best audits have already sparked shared understanding. The audit becomes not just a document, but a reference point for smarter decision-making.

    Who Should Lead the Work

    Many organizations choose an external partner for their first full audit. That outside perspective helps avoid blind spots, reduces the learning curve around WCAG and assistive technologies, and carries added weight in legal and procurement settings.

    At the same time, internal teams remain central. Designers, developers, content authors, and QA are the ones who turn findings into reality—into backlog items, component updates, and content standards that actually stick.

    Over time, the healthiest model is a blend: external audits for baseline and validation, internal ownership for day-to-day integration. Accessibility stops living in a report and starts living in the workflow.

    From One Audit to an Ongoing Practice

    A single web accessibility audit is not the destination; it is the baseline.

    You can use that baseline to:

    • Spot systemic issues (navigation patterns, color systems, form models)
    • Prioritize foundational fixes that unlock better experiences across the board.
    • Update your design system, component library, and content standards so improvements stick.

    From there, you connect audits to training and process change. Short, focused training sessions built around your actual findings land better than generic guidelines. Lightweight monitoring—linters, CI checks, and targeted automated scans—helps catch regressions early.

    The long-term shift is simple but powerful: instead of asking, “Are we accessible yet?” you begin asking, “How are we improving accessibility in this release?”

    Progress, not perfection, becomes the measure.

    Turning When, Where, and Why Into a Real Next Step

    For many teams, accessibility feels important but amorphous. An audit turns it into something concrete:

    • When it becomes tied to real releases and change moments
    • Where becomes focused on the experiences that matter most
    • Why becomes grounded in user trust, product quality, and organizational risk—not just compliance

    And this is exactly where teams often ask for support. Not because they lack commitment—but because they want help shaping the work to fit real constraints.

    At 216digital, we work with organizations every day to right-size their web accessibility audit strategy—scoping what matters most, timing it with roadmaps, and connecting findings to sustainable improvements rather than one-off fixes.

    If you want a low-pressure way to start that conversation, scheduling an ADA briefing with 216digital is often the easiest first step. It gives you space to talk through upcoming launches, regulatory exposure, team capacity, and what kind of audit approach actually makes sense right now.

    Accessibility is a long game. You do not have to untangle the “when, where, and why” on your own.

    Greg McNeil

    November 26, 2025
    Testing & Remediation
    Accessibility Audit, custom accessibility audits, manual audit, WCAG, Web Accessibility, Website Accessibility
  • Skip the Rework Headache with a11y.Radar

    Skip the Rework Headache with a11y.Radar

    Your website is accessible. You’re done now, right? Not quite.

    While remediation is a crucial first step, it’s really just the beginning. Accessibility isn’t something you finish once—it’s something you maintain. Websites are always changing. Content gets updated, plugins refresh, new features roll out—and with each shift, there’s a chance that accessibility issues reappear.

    According to WebAIM’s 2024 report, over 96% of homepages had detectable WCAG errors. Many of those errors weren’t new—they crept back in after earlier fixes. Without a way to keep accessibility in check, even small changes can undo progress and put organizations right back at risk.

    That’s why ongoing monitoring is so important. And that’s where a11y.Radar comes in.

    Why “One and Done” Doesn’t Work

    It’s natural to feel like accessibility work is complete after an audit. But the truth is, compliance is a moving target. Sites evolve every day, and standards continue to shift. WCAG guidelines are updated, ADA enforcement grows, and states add their own rules. What passes now might not pass six months from now.

    Even small oversights can add up. A missing ALT tag, a mislabeled form, or a CMS update that disrupts your site structure—any of these can affect usability for people with disabilities. Over time, those unnoticed changes also increase the risk of legal action.

    And that risk is real. In 2024, 4,000 accessibility lawsuits were filed in U.S. courts. Many weren’t first-time cases. In fact, 41% of all federal lawsuits in 2024 were filed against companies that had already faced a digital accessibility lawsuit. Once a business appears on the radar, it often becomes a repeat target—sometimes from a new plaintiff, sometimes aimed at a sister brand or parent company, and sometimes even circling back to the same website.

    The Cost of Letting Issues Linger

    Accessibility problems don’t just affect users—they affect your team too. When issues surface after launch, they’re far harder to fix. Developers have to step away from active work, QA has to retest, and releases get delayed. That cycle costs time and energy, and it chips away at morale.

    It also costs more. Studies have shown that post-launch accessibility fixes can be up to ten times more expensive than addressing them earlier. Add the risk of legal complaints or demand letters, and the impact multiplies quickly.

    For many teams, it isn’t a lack of commitment that causes setbacks—it’s the lack of ongoing visibility.

    How a11y.Radar Helps You Keep Watch

    This is where a11y.Radar proves valuable. Built from years of remediation work, it was designed to answer a common question: how do we stay compliant after the fixes are done?

    The platform runs recurring ADA and WCAG audits, scanning for the same kinds of issues law firms often use when targeting businesses. But instead of being surprised by those results, you get to see them first. Dashboards show your current compliance health, alerts highlight new problems quickly, and reports track issues over time so patterns become easier to spot.

    Rather than treating accessibility like an occasional project, a11y.Radar makes it a steady part of how your site is maintained.

    A Practical Difference for Teams

    The benefits of ongoing monitoring show up in day-to-day work. Developers can push new features without worrying that a small change will break compliance unnoticed. Managers and stakeholders have clear visibility into accessibility status without extra meetings or reports. And when questions arise, monitoring logs provide a record of diligence and care.

    Clients who use a11y.Radar often notice fewer disruptions to their sprint cycles and lower long-term remediation costs. But the real gain is stability. Teams move forward with confidence instead of being pulled back into cycles of rework.

    Why a11y.Radar Isn’t an Overlay or Widget

    It’s easy to confuse accessibility monitoring tools with overlays or plug-in widgets, but they couldn’t be more different. Overlays are marketed as quick fixes—drop in a snippet of code and, supposedly, your site is “compliant.” In reality, they don’t correct the underlying barriers. The same issues remain in the code, which means automated scans—and the law firms that rely on them—still find them.

    Overlays also bring their own problems. They often interfere with assistive technologies like screen readers, creating new frustrations for the very users they claim to help. That’s why accessibility experts consistently caution against relying on them.

    a11y.Radar works differently. It doesn’t attempt to “fix” anything on the surface. Instead, it monitors your site continuously, showing you where real issues exist so they can be corrected properly. Its role is transparency—alerting you to problems early, tracking them over time, and giving your team the information needed to address them at the source.

    This approach doesn’t create the illusion of accessibility. It gives you the clarity to maintain it.

    Automation and Human Judgment Together

    Automation does a lot of the heavy lifting, but it isn’t the whole answer. Scans can confirm whether an ALT attribute exists, but they can’t judge whether the description is meaningful. They can flag a contrast error but can’t measure how usable the design feels in practice.

    That’s why a11y.Radar also supports manual testing. Accessibility specialists step through your site with the same tools and perspectives users rely on, catching nuances that automation alone might miss. Together, automated scans and expert reviews create a more complete picture—one that protects both compliance and user experience.

    Building Accessibility That Lasts

    Accessibility work doesn’t stop after the first round of fixes. Websites and applications will continue to change, and with change comes the possibility of new barriers. The difference between falling behind and staying ahead often comes down to whether you’re monitoring consistently.

    With a11y.Radar, teams gain a clear view of their compliance status, the ability to catch problems early, and the reassurance that progress won’t slip away. It helps reduce unnecessary rework, lowers legal risk, and gives developers and decision-makers more confidence in every release.

    Accessibility is ongoing by nature. The more it becomes part of routine maintenance, the less it feels like a burden—and the more it supports a reliable, inclusive experience for everyone who uses your site.

    Schedule a complimentary ADA Strategy Briefing to speak with one of our accessibility experts about a11y.Radar ADA Monitoring.

    Greg McNeil

    September 22, 2025
    Web Accessibility Monitoring
    a11y.Radar, Accessibility Audit, Accessibility monitoring, accessibility radar, web accessibility monitoring
  • Do You Need a Web Accessibility Audit or a VPAT?

    Do You Need a Web Accessibility Audit or a VPAT?

    Digital compliance isn’t one-size-fits-all. Depending on your organization’s goals, you may need an accessibility audit, a Voluntary Product Accessibility Template (VPAT®), or both. The real challenge is matching the deliverable to the job in front of you. If you’re navigating ADA, Section 508, WCAG, EN 301 549, or enterprise procurement requirements, understanding how audits and VPATs differ—and how they work together—can save time, reduce risk, and strengthen your position in competitive markets.

    This guide explains what accessibility audits and VPATs are, how they differ, when to use each, and how they can complement one another.

    What Is an Accessibility Audit?

    An accessibility audit is a deep, hands-on evaluation of your digital product—website, web app, mobile app, software, or document—against recognized standards such as WCAG 2.1/2.2 Level AA and, when applicable, Section 508. Although automation has a role, a credible audit centers on expert manual testing and real-world use.

    A typical audit blends three modes of evaluation that build on one another:

    • Automated triage to surface easy-to-spot patterns (e.g., missing alt text, color contrast flags, form input associations) and help size the work.
    • Expert manual review of templates, components, and user flows against WCAG success criteria, including focus management, semantics/landmarks, ARIA usage, error handling, and dynamic states.
    • Assistive technology and keyboard testing to validate actual usability—screen readers (e.g., NVDA/JAWS/VoiceOver), zoom and reflow, high-contrast modes, and full keyboard operation.

    Strong audits don’t stop at a list of defects. They provide actionable guidance: prioritized findings, severity and user impact, code-level recommendations, component-level patterns, and a retest plan. Many organizations also incorporate user testing with people with disabilities to capture lived-experience insights that technical checks alone can miss. The result is a roadmap your team can execute—not just a scorecard.

    What Is a VPAT?

    A VPAT® is a standardized disclosure that becomes your Accessibility Conformance Report (ACR). It doesn’t test; it reports what testing found. Each criterion is mapped to a status—Supports, Partially Supports, or Does Not Support—with remarks that define versions, platforms, assistive-technology pairings, and known limits. Choose the correct edition (WCAG, Revised Section 508, EN 301 549, International), date-stamp the ACR, and clearly state the product and environment scope. A defensible VPAT is evidence-backed—ideally by a recent audit plus targeted verification on the declared platforms.

    In short: an audit discovers and validates; a VPAT declares and documents.

    Accessibility Audit vs VPAT: Key Differences

    AspectAccessibility AuditVPAT (ACR)
    Primary purposeIdentify issues; deliver remediation guidance; validate usabilityCommunicate conformance status to buyers and regulators
    AudienceInternal teams: product, engineering, design, complianceExternal stakeholders: procurement, clients, regulators
    FormatNarrative report with prioritized findings and fixesStandardized template leading to an ACR with criterion-by-criterion statements
    EvidenceManual/AT testing, sometimes user testing with people with disabilities, plus automationSummaries of conformance based on testing evidence
    TimingBest before launch/redesign, after significant releases, or upon risk eventsBest during RFPs, renewals, market entry, or when a contract requires it
    OutcomeImproved accessibility and user experienceProcurement-ready disclosure and contractual clarity
    Update cadenceWith each major release or accessibility milestoneWhenever scope, features, or conformance materially change

    With the differences in view, here’s how to use each deliverable at the right moment.

    When to Have an Accessibility Audit

    An audit should come before you make broad claims of compliance. It is the groundwork that ensures your product meets the standards you plan to cite.

    Consider commissioning an audit when you are:

    • Preparing for launch or a major redesign. Early findings are cheaper to fix and easier to standardize into reusable components.
    • Responding to risk. If you’ve received a complaint, demand letter, or internal escalation, an audit clarifies actual exposure and prioritizes remediation.
    • Improving product quality. Teams aiming to raise UX quality for everyone—faster task completion, fewer errors, better forms—use audits to remove barriers that frustrate all users, not only those with disabilities.
    • Planning a VPAT. If a VPAT is on the horizon, a current audit supplies the evidence and remarks you’ll need to make defensible statements.

    Without an audit, a VPAT can drift into guesswork—an avoidable liability in regulated procurement.

    When to Have a VPAT Prepared

    A VPAT becomes essential when you need formal proof of accessibility for sales, purchasing, or funding.

    Typical triggers include:

    • RFPs and vendor onboarding in government, higher education, healthcare, and large enterprise.
    • Contract renewals or marketplace listings where accessibility is non-negotiable.
    • International expansion that introduces EN 301 549 or other jurisdictional requirements.

    Treat the VPAT/ACR as a living document. Update it after major releases, platform additions, or meaningful improvements so procurement teams see a current and accurate picture.


    Decision rule: If an external party will evaluate your conformance (RFP, renewal, marketplace, grant), you’ll need an ACR (VPAT) grounded in a current audit; otherwise start with the audit alone.

    Do You Need Both?

    In regulated or enterprise procurement, the default answer is yes. If you are selling to government, higher education, healthcare, or large enterprises—or you intend to make public conformance claims—you need both an audit and a VPAT (ACR). The audit establishes factual evidence of how the product performs against WCAG/Section 508 in real use. The VPAT communicates that evidence in the standardized format buyers expect.

    As a rule of thumb: use an audit to know; use a VPAT to show. When disclosure is part of sales, renewals, or public listings, sequence your work as audit, remediate, then prepare the VPAT so statements are current, precise, and defensible.

    Once you know when to use each, it helps to see how they reinforce one another.

    How They Reduce Risk Together

    Audits and VPATs mitigate different classes of risk that often compound if handled in isolation. The audit reduces product and legal risk by finding and prioritizing barriers before they become complaints or claims and by providing implementable fixes. It also creates a repeatable testing pattern—templates, flows, and assistive-technology pairings—that your team can reuse release after release.

    The VPAT reduces commercial and contractual risk. It removes friction in procurement, sets accurate expectations about platforms and known limits, and documents the scope under which conformance was verified. Procurement teams look for alignment between your ACR remarks and the audit artifacts. When those line up—versions, dates, and assistive 

    technologies—friction drops and credibility increases. Working together, the audit improves the thing; the VPAT aligns the promise. That alignment closes the gap between user reality and contractual language—the place most disputes arise.

    Practical Scenarios

    Federal RFP: You need both. Commission an audit covering the exact scope in the RFP (versions, browsers, AT). Remediate high-impact issues, verify fixes, then publish a VPAT/ACR that cites that evidence with precise remarks.

    Small e-commerce: Prioritize the audit. Focus on core purchase flows and forms, implement fixes, and establish a light retest cadence. Skip the VPAT until an enterprise buyer or marketplace explicitly requests one.

    University adoption: The buyer will require a VPAT from the vendor. A responsible vendor conducts an audit first, then produces a VPAT grounded in that evidence.

    Monthly SaaS cadence: Establish a rhythm: periodic audits on shared components and critical journeys; targeted verification after impactful changes; VPAT updates tied to material shifts in scope or before major renewals. Keep the VPAT’s scope and dates synchronized with your latest audit window.

    Final Thoughts

    Accessibility audits and VPATs aren’t interchangeable; they serve different, complementary purposes. The audit digs into how your product actually behaves and shows you how to fix issues. The VPAT communicates that conformance in a format procurement teams trust. Organizations that treat the VPAT as living, evidence-based disclosure—and audits as an ongoing quality practice—build trust, reduce risk, and win more consistently.

    Ready to move from claims to confidence? Schedule an ADA briefing with 216digital—we’ll review your product context, prioritize a first sprint, and outline a clear path from audit and remediation to a defensible, procurement-ready ACR.

    Greg McNeil

    September 10, 2025
    Testing & Remediation, Uncategorized
    Accessibility, Accessibility Audit, ADA, custom accessibility audits, VPAT, WCAG, Web Accessibility, Website Accessibility
  • What Is a VPAT and Why It Matters

    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

  • How Often Should You Audit Your Website for Accessibility?

    You’ve already put in the effort to make your website accessible—and that’s no small thing. But accessibility isn’t something you fix once and forget. As your site evolves, even small changes can introduce new issues. That’s where regular check-ins come in. A web accessibility audit helps you catch problems early, stay aligned with current standards, and keep your site working for everyone.

    So how often should you audit your site to maintain that progress? The answer depends on what’s changing—and when. In this article, we’ll break down the key moments when an audit makes sense, the risks of letting things slide, and how ongoing monitoring can help you stay ahead.

    Why Web Accessibility Audits Are Critical

    A web accessibility audit reviews your website’s design, code, and content to identify barriers that could make it hard—or even impossible—for people with disabilities to use your site. These audits typically test against the Web Content Accessibility Guidelines (WCAG) standards, the ADA (Americans with Disabilities Act), and other regulations.

    The risks of not auditing regularly are real for small to midsize businesses. Over the past few years, digital accessibility lawsuits have skyrocketed. In 2024 alone, more than 4,000 web accessibility lawsuits were filed under the ADA—and many of those targeted businesses that were unaware they had an issue.

    The cost of defending even a small ADA lawsuit can easily reach tens of thousands of dollars, not to mention the damage to your brand’s reputation. Proactive audits help you spot and fix issues early, keeping your business protected and your customers happy.

    When Should You Audit Your Website for Accessibility?

    While accessibility should be baked into your website maintenance plan, certain milestones require a full web accessibility audit.

    1. After a Website Redesign or Major Update

    If you’ve recently rebranded, relaunched, or significantly redesigned your site, it’s critical to schedule a full accessibility audit. Even small navigation, layout, or feature changes can unintentionally introduce new barriers. Testing right after major updates ensures you catch and fix issues before customers encounter them—and before a potential lawsuit arises.

    2. Before Launching New Features or Products

    Rolling out a new e-commerce section? Adding a chatbot? Introducing video content or online booking? Before new features go live, a web accessibility audit should be part of your quality assurance checklist.

    New code, third-party integrations, and interactive tools can create accessibility gaps. Testing pre-launch helps ensure all users can interact with the new elements, no matter what device or assistive technology they’re using.

    3. Annually (at Minimum)

    Even if your site hasn’t changed much, accessibility standards, best practices, and legal expectations evolve over time. Conducting a comprehensive web accessibility audit at least once a year ensures your site complies with current WCAG standards (currently WCAG 2.1 and moving toward 2.2) and applicable regulations.

    Think of it like an annual checkup for your digital presence: it’s much easier and cheaper to maintain accessibility than to fix major problems down the road.

    4. After User Feedback or Complaints

    If a customer or visitor flags an accessibility issue, that’s a signal to audit right away—not just the problem area but the entire site. User feedback is invaluable because it often reveals real-world issues automated scans might miss. Addressing concerns quickly shows that your business takes accessibility seriously and is committed to serving all users.

    5. When Laws or Guidelines Change

    New accessibility laws, updates to WCAG standards, or changes in court interpretations can raise the bar for compliance. For instance, the Department of Justice recently released new guidance for web accessibility under Title II of the ADA. When legal standards shift, a fresh audit can make sure you’re aligned with the latest requirements.

    Why Ongoing Monitoring Matters

    While annual or event-based audits are critical, they’re not enough. Websites are dynamic—they grow, change, and update constantly. New products, marketing campaigns, and blog posts can all introduce accessibility problems over time.

    That’s where ongoing accessibility monitoring comes in.

    At 216digital, we developed a11y.Radar, a proactive monitoring service that continuously scans your site for accessibility issues. a11y.Radar doesn’t replace manual audits (human expertise is still key!), but it acts as an early warning system—catching errors before they snowball into bigger problems.

    With a11y.Radar, you can:

    • Receive real-time alerts about accessibility regressions
    • Track ongoing improvements
    • Maintain continuous WCAG compliance
    • Reduce your risk of surprise lawsuits

    This approach helps you move from a reactive stance (“fix it after a lawsuit”) to a proactive one (“prevent lawsuits by staying accessible”).

    The Cost of Skipping Regular Web Accessibility Audits

    Many small to midsize businesses skip regular accessibility audits because of perceived costs or time commitments. But the truth is, not auditing can cost far more.

    Ignoring accessibility can lead to:

    • ADA lawsuits and expensive legal settlements
    • Court-ordered website remediation under tight (and expensive) deadlines
    • Loss of customers who can’t use your site
    • Negative publicity and damage to your brand’s reputation
    • Higher remediation costs later, compared to maintaining accessibility from the start

    Investing in regular audits and monitoring is like insurance for your website—and your business future.

    How 216digital Can Help You Stay Compliant

    At 216digital, we specialize in helping businesses of all sizes navigate the world of web accessibility with confidence. Our phased approach includes:

    • Risk Mitigation Audits: A focused first-pass audit to quickly catch and fix high-risk issues.
    • Real World Accessibility Audits: Deep manual testing with screen readers, keyboard-only navigation, and assistive technologies to find real-world barriers.
    • Ongoing Monitoring with a11y.Radar: Continuous scanning and reporting to help you maintain compliance and stay ahead of risks.

    We believe accessibility isn’t a one-time project—it’s an ongoing commitment. That’s why our services are designed to be flexible, scalable, and tailored to your business needs.

    Whether starting from scratch, redesigning your website, or needing help managing compliance over time, 216digital can help you build and maintain a site that works for everyone—and protects your business simultaneously.

    Keep Progress on Track with Confidence

     Accessibility is never truly finished—but that’s a good thing. It means you have an opportunity to keep improving, keep welcoming, and keep your business open to everyone. Staying compliant isn’t about chasing checklists—it’s about maintaining the trust you’ve already worked hard to earn.If you’re wondering whether now is the right time for your next audit, it probably is. A quick conversation can help clarify where you stand and what steps make sense next. Schedule a free ADA accessibility briefing with 216digital, and let’s keep your site moving forward—securely, inclusively, and confidently.

    Greg McNeil

    April 28, 2025
    Testing & Remediation
    Accessibility, Accessibility Audit, Accessibility testing, automated testing, manual audit, Manual Testing, Website Accessibility

  • What to Expect from an Accessibility Audit

    Running a business is no small feat. Between managing daily operations, keeping customers happy, and staying on top of your digital presence, it’s easy to overlook something like web accessibility. But in today’s world, where more users rely on assistive technology to browse online, accessibility is no longer optional—it’s essential.

    That’s where an accessibility audit comes in. It’s a smart, proactive step that helps you understand how well your website works for people with disabilities and where improvements are needed. It’s not just about avoiding legal trouble—it’s about creating a better experience for all your visitors.

    Let’s break it down so you know exactly what to expect.

    Why Accessibility Matters

    Reaching Every Visitor

    Web accessibility is about making sure everyone can use your website—no matter their ability. That includes people who rely on screen readers, keyboard navigation, or voice control, as well as those with visual, hearing, or cognitive challenges.

    A more accessible site leads to:

    • Better user experience
    • Improved search engine visibility
    • Increased customer trust

    It’s a win for your users and your business.

    Reducing Legal Risk

    ADA-related lawsuits over inaccessible websites are on the rise, and many target small to mid-sized businesses. In fact over 67% of lawsuits  in 2024 were targeting businesses with an annual revenue under $25 million or less. 

    These cases can be stressful and expensive—even if the issues weren’t intentional.

    A professional accessibility audit helps you spot and fix issues early, protecting your business while showing your commitment to inclusion.

    What Is an Accessibility Audit?

    An accessibility audit is a full review of your website to find any barriers that might stop people with disabilities from using it. These barriers could be anything from missing image descriptions to forms that don’t work with a screen reader.

    The audit is based on the Web Content Accessibility Guidelines (WCAG), which provide a clear set of standards for accessible web design. Following WCAG helps ensure your site meets legal requirements—and, more importantly, that it works for everyone.

    The Accessibility Audit Process: Step-by-Step

    Here’s what typically happens during a full accessibility audit:

    Initial Consultation & Scope Definition

    The process starts with a conversation. You and your audit team will review your website’s goals, user flows, and top-priority pages—like your homepage, checkout process, or contact form. This helps focus the audit on what matters most.

    Automated Testing

    Automated tools run quick scans to catch common issues like:

    • Missing alt text
    • Low color contrast
    • Improper heading order

    This is a great first step, but automated testing only catches part of the picture. That’s why manual checks are so important.

    Manual Evaluation

    Accessibility specialists then take a deeper look at your site. They’ll test things like:

    • Can users navigate with just a keyboard?
    • Are screen readers reading content in the correct order?
    • Do buttons and links have clear, accessible labels?

    Manual testing finds the issues that machines often miss—and ensures your site works for real people in real situations.

    User Testing with Assistive Technology

    In some cases, the team may bring in people who use assistive tools daily—like screen readers or alternative input devices—to test your site. Their feedback offers invaluable real-world insight that helps uncover problems no tool or developer could spot alone.

    Documentation of Findings

    Once testing is done, you’ll receive a report that includes:

    • A list of all issues
    • Where each problem exists
    • The specific WCAG criteria it violates
    • Visual examples and code references for clarity

    This report serves as your roadmap to fixing issues efficiently.

    Prioritization of Issues

    Not all issues are created equal. The audit team will help you prioritize based on the following:

    • How severe the issue is
    • How many users it might impact
    • Whether it poses a legal risk

    This lets you address the biggest barriers first and build a smart action plan moving forward.

    Remediation Recommendations

    Finally, you’ll receive clear, actionable guidance for fixing each issue. These recommendations will be tailored to your site’s platform, content, and team capacity. Some fixes might be quick, while others may take more planning—but you’ll know exactly what to do and where to start.

    What Happens After the Audit?

    Implementing Fixes

    After the accessibility audit, it’s time to put the findings to work. Your team—or a trusted partner like 216digital—can help implement those changes, making sure they align with best practices while preserving your brand’s design and functionality.

    Team Training

    To keep your site accessible over time, it helps to train the people who update it. That could mean a short session on how to use alt text or a checklist for adding new content. A little knowledge goes a long way in preventing future issues.

    Ongoing Monitoring

    Accessibility isn’t something you check off once and forget about. Websites are living things—they change, grow, and update over time. That means new accessibility issues can pop up without warning, especially as content is added or platforms evolve.

    That’s why regular monitoring is key. Running periodic scans, reviewing key pages, and staying alert to new barriers helps you maintain accessibility long after the initial audit. Tools like a11y.Radar, 216digital’s ongoing monitoring service, are designed to make this easier. It quietly keeps tabs on your site, flags issues early, and helps ensure your site stays in line with accessibility best practices—without the need for constant manual checks.

    Your Website’s Future Just Got Brighter

    A professional accessibility audit gives you more than just a report—it gives you peace of mind. It’s a smart, future-focused way to protect your business, improve your site, and welcome every visitor who comes your way.

    At 216digital, we specialize in helping small to mid-sized businesses make sense of accessibility. Our expert-led audits, clear documentation, and hands-on remediation support make the process easy to follow and effective to implement. We help you go beyond compliance—to a website that’s truly inclusive.

    If you’re ready to create a better experience for everyone and reduce your legal risk, let’s talk. A more accessible site isn’t just better for users—it’s better for business.

    Greg McNeil

    April 15, 2025
    Testing & Remediation
    Accessibility, Accessibility Audit, Accessibility testing, automated testing, manual audit, Web Accessibility, Website Accessibility

  • How Automated Scans Help (and Fail) Accessibility

    Have you ever clicked on a website and immediately gotten lost because nothing seemed to work the way you expected? Maybe you couldn’t find the right button, or the page layout was all over the place. Now imagine facing those same frustrations but with the added challenge of a visual, auditory, or motor disability. Navigating the web shouldn’t feel like an obstacle course—it should be intuitive and inclusive for everyone.

    If you’re a website owner or business owner in the United States, you might already know that accessibility is becoming more than just a nice-to-have. It’s a key part of good customer service, protects you from legal risks, and, quite simply, it’s the right thing to do. But where do you start?

    One of the first steps many people take is running automated scans.

    These scans promise a quick way to spot accessibility issues on your site. Yet, while they can be extremely helpful, they’re far from perfect. In this article, we’ll explore the ups and downs of automated scans—what they can do, where they fail, and how to blend them into a solid strategy that also includes manual testing and expert help.

    What Are Automated Accessibility Scans?

    Automated scans are software tools that crawl through your website’s code, looking for red flags based on standards like the Web Content Accessibility Guidelines (WCAG)). Think of these tools like the spellcheck in your word processor: they can spot a lot of mistakes, but they can’t always tell you if you’re using the right words in the right context.

    What Do Automated Scans Detect?

    Plenty of free and paid tools exist. Some are browser extensions (like WAVE or Google’s Lighthouse), while others are built-in services that run regular checks on your website. They’re great at picking up on common coding issues such as:

    • Missing or poorly written alternative text on images
    • Low color contrast between text and background
    • Improper heading levels (skipping from an H1 to an H3 without an H2, for example)
    • Misapplied ARIA attributes
    • Certain missing form labels

    If your site has glaring accessibility mistakes, automated scans can flag those quickly. They’ll often give you a handy list of what’s wrong, along with references to WCAG guidelines or best practices on how to fix each issue. That’s a huge benefit if you’re new to accessibility and need a push in the right direction.

    How Automated Scans Can Help You

    Let’s look at some of the biggest advantages of automated scans—and how they fit into your overall web development workflow.

    Speed and Efficiency

    Manual reviews take time, especially for large websites. An automated tool, on the other hand, can process hundreds or even thousands of pages in a shorter timeframe. This is especially handy if you regularly add or change content.

    Spotting the “No-Brainers”

    Many accessibility issues are straightforward coding mistakes—like forgetting to add “alt” text to images. Automated scanners are perfect for picking up on these. They’re quick, consistent, and thorough in locating these common errors.

    Routine Monitoring

    Some automated scan tools offer scheduled checks, which is terrific for ongoing maintenance. You can set them to run weekly or monthly scans and then get alerts if something new pops up, letting you address problems before they spiral.

    Raising Awareness

    For those brand-new to digital accessibility, automated tools can serve as a mini crash course. They highlight rules like ensuring sufficient color contrast or labeling form fields properly, helping you learn accessibility basics as you go.

    Ease of Use

    Many automated scanners come with user-friendly dashboards or plugins. You don’t have to be a coding genius to interpret most of the results. Often, the tool itself provides guidance on how to fix whatever it finds.

    The Real-World Limitations of Automated Scans

    As powerful as they are, automated scans also have notable blind spots (no pun intended). If you rely solely on these tools, you could end up with a site that technically passes certain checks but still feels like a maze for users with disabilities.

    Lack of Context

    A scanner can confirm if there’s alt text on an image, but it can’t determine if that text is accurate or helpful. An automated report might be happy to see you labeled your button as “Button,” but that label doesn’t tell a user what the button actually does.

    Missing Nuances

    Some accessibility aspects aren’t purely code-based; they’re about user experience and clarity. For example, is your site’s language too complicated for people with cognitive disabilities? Or is the layout tricky for those navigating with a screen reader? Automated tools struggle with these questions because they can’t judge user-friendliness the same way a person can.

    False Flags

    It’s common to get false positives (where the tool flags a problem that might not actually be a problem) or false negatives (where the tool fails to spot a genuine issue). This can lead you down the wrong path or lull you into thinking your site is perfectly fine when it’s not.

    Limited Scenarios

    Accessibility is more than code. What happens when someone uses only a keyboard to navigate your site? Or how does your site work for someone who relies on voice commands or a screen reader? Automated scans can’t replicate all these scenarios.

    Overconfidence and the Need for Manual Testing

    Automated tools can create a false sense of security. Just because a scanner says you’re 90% accessible doesn’t mean your site is truly welcoming for all. This is where manual testing comes in.

    Beyond the Scan: Why Manual Testing Still Rules

    Manual testing is where you or a tester interacts with your site in a more human way. Yes, it’s more time-intensive, but it’s also where you’ll uncover issues an automated tool can’t detect.

    Keyboard-Only Navigation

    One of the most fundamental manual tests is trying to tab through your site without using a mouse. If you can’t reach a menu item or submit a form using only the keyboard, that’s a major red flag.

    Screen Reader Assessments

    Automated scans might say you have alt text in all the right places, but only a real screen reader test will tell you if that text makes sense in context. Does it describe important images properly? Does the reading order make sense, or does it jump around the page?

    Real Users, Real Feedback

    Inviting people with various disabilities to use your site can reveal issues you never even knew existed. Maybe certain wording is confusing, or a CAPTCHA system is impossible to complete using assistive technology. Nothing beats firsthand feedback.

    Manual testing fills the gaps that scanners leave behind, ensuring your site isn’t just “passing a test” but actually creating a positive experience. While it can require more resources (time and possibly hiring outside help), the results are worth it.

    Keeping Accessibility an Ongoing Priority

    Accessibility isn’t something you do once and forget about. Think of your website as a living, breathing entity: you add content, tweak layouts, and launch new features over time. Each change could introduce fresh accessibility challenges.

    So, how exactly do automated scans fit into a more complete approach to accessibility?

    Putting It All Together: A Holistic Accessibility Game Plan

    1. Start with an Automated Scan – Run a scan and fix low-hanging fruit, such as missing alt text and color contrast problems.
    2. Add Manual Checks – Navigate your site using only a keyboard and a screen reader. Identify areas that feel confusing or broken.
    3. Get Professional Input – If your site is critical to your business, hire an accessibility specialist for a thorough audit.
    4. Keep It Going – Schedule periodic scans, manual audits, and staff training. Accessibility should be part of your workflow.
    5. Stay Informed – Follow updates to WCAG and relevant U.S. laws, and continue learning from accessibility experts.

    The Best of Both Worlds: Automated and Manual Testing

    Achieving true web accessibility requires more than just running a quick scan—it demands a balanced approach that combines the speed of automation with the insight of manual testing. Automated tools can help identify glaring issues, but only real human interaction can ensure a seamless experience for all users. By integrating both strategies, you’re not just checking a compliance box—you’re creating a more inclusive, user-friendly web presence that benefits everyone.

    Start your journey toward full web accessibility today—reach out to 216digital using the form below! Our team of accessibility experts is ready to assess your site and provide tailored solutions to ensure that all visitors can easily access your content. Don’t let accessibility remain an afterthought—take the first step towards a more inclusive online presence now.

    Greg McNeil

    February 13, 2025
    Testing & Remediation
    Accessibility Audit, Accessibility testing, automated testing, manual audit, Manual Testing, Web Accessibility
1 2
Next Page
216digital Scanning Tool

Audit Your Website for Free

Find Out if Your Website is WCAG & ADA Compliant













    216digital Logo

    Our team is full of expert professionals in Web Accessibility Remediation, eCommerce Design & Development, and Marketing – ready to help you reach your goals and thrive in a competitive marketplace. 

    216 Digital, Inc. BBB Business Review

    Get in Touch

    2208 E Enterprise Pkwy
    Twinsburg, OH 44087
    216.505.4400
    info@216digital.com

    Support

    Support Desk
    Acceptable Use Policy
    Accessibility Policy
    Privacy Policy

    Web Accessibility

    Settlement & Risk Mitigation
    WCAG 2.1/2.2 AA Compliance
    Monitoring Service by a11y.Radar

    Development & Marketing

    eCommerce Development
    PPC Marketing
    Professional SEO

    About

    About Us
    Contact

    Copyright 2024 216digital. All Rights Reserved.