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
  • VPAT vs ACR: What’s the Difference and Why It Matters

    VPAT vs ACR: What’s the Difference and Why It Matters

    If you’ve ever been asked for a VPAT or an ACR and felt your stomach drop, you’re not alone. These acronyms often appear in RFPs, procurement conversations, and compliance checklists—and can leave even experienced teams scrambling to figure out what’s actually being requested. Understanding the difference between a VPAT and an ACR isn’t just technical trivia. It can mean the difference between winning a contract, avoiding legal risk, and showing that your organization takes accessibility seriously.

    This guide breaks it all down: what a VPAT is, what an ACR is, how they differ, and how to create them with confidence.

    Absolutely — here’s that section updated with the requested subheader formatting:

    What Is a VPAT?

    A VPAT—short for Voluntary Product Accessibility Template—is a standardized document created by the Information Technology Industry Council (ITI) to report how well a digital product meets accessibility standards like WCAG, Section 508, and EN 301 549.

    Think of the VPAT as a structured questionnaire. It asks you to evaluate your product feature by feature and indicate whether each requirement is supported, partially supported, or not supported, along with explanations. The most recent version is VPAT 2.5, which comes in multiple editions to meet different regulatory needs: WCAG, 508 (for U.S. federal agencies), EU (for European procurement), and INT (for global organizations).

    A Typical VPAT Includes

    • Product name, version, and date of evaluation
    • Standards referenced (WCAG 2.1, Section 508, EN 301 549)
    • Testing methods used
    • Tables showing conformance levels for each criterion
    • Brief remarks or explanations where needed

    It’s important to note that the VPAT itself is voluntary—there’s no federal law requiring you to complete one unless it’s part of a procurement process or client request. And because VPATs are self-reported, their quality depends on your honesty and expertise. A VPAT is an essential starting point but doesn’t guarantee real-world usability for people with disabilities. Usability testing and independent audits remain critical for a complete accessibility picture.

    What Is an ACR?

    An ACR, or Accessibility Conformance Report, is the completed version of a VPAT. If the VPAT is the blank template, the ACR is the filled-in, actionable report. It’s a snapshot of your product’s accessibility at a given point in time, often after thorough testing.

    Where the VPAT provides structure, the ACR provides substance. It includes:

    • Specific findings for each standard
    • Narrative explanations for partial or non-support
    • Workarounds or mitigation strategies
    • Planned remediation timelines

    How Testing Builds Trust

    The strongest ACRs are grounded in a variety of testing methods, not just automated scans. Manual code reviews can catch nuanced issues that tools miss. Testing with assistive technologies like screen readers, magnifiers, or voice input tools reveals how real users navigate your product. Including results from usability sessions with people who have disabilities can also add powerful credibility. Documenting these methods in your ACR shows buyers and procurement teams that your results are thorough, reliable, and rooted in real-world experience.

    Comparing VPAT vs. ACR: Core Differences

    Although the terms are sometimes used interchangeably, VPATs and ACRs play different roles:

    • Template vs. Report: The VPAT is the empty template; the ACR is the completed, shareable report.
    • Level of Detail: A VPAT lists conformance levels, but an ACR goes deeper with context, user impact notes, and remediation plans.
    • Who Creates Them: VPATs are often drafted internally by product or compliance teams. ACRs may be internally created or validated by third-party auditors to add credibility.
    • Audience: VPATs are useful for internal planning and tracking. ACRs are intended for procurement officers, enterprise buyers, and compliance teams who need assurance that accessibility has been tested and documented thoroughly.

    This distinction is crucial—submitting only a VPAT when an RFP requests an ACR could disqualify you from consideration.

    Best Practices for Creating VPATs and ACRs

    Getting these documents right takes more than filling out a form. Follow these practices to create credible and effective reports:

    • Use the Latest Template: Work from VPAT 2.5 or later to align with current standards like WCAG 2.1 or 2.2.
    • Be Transparent About Gaps: Overstating conformance can hurt credibility. Clearly indicate “Partially Supports” or “Does Not Support” when needed, and explain why.
    • Add Detailed Remarks: Go beyond a yes/no answer. Include context on who is impacted, how severe the issue is, and whether a fix is planned.
    • Document Testing Methods: Specify whether testing involved automated tools, manual reviews, assistive technology testing, or user testing. This adds weight to your ACR findings.
    • Update Regularly: Accessibility isn’t one-and-done. Refresh your VPAT and ACR with each major release or remediation cycle so they reflect the current state of your product.

    Procurement-ready Checklist

    • Product name, version, and date are clearly listed
    • Standards cited (WCAG, 508, EN 301 549) match buyer requirements
    • Conformance ratings are accurate and supported with evidence
    • Testing methods and tools are documented in plain language
    • Known issues, workarounds, and fix timelines are included
    • Jargon is avoided—language is clear for non-technical readers
    • Document is reviewed and refreshed with each major product update

    Conclusion: Building Confidence Through Transparency

    The VPAT gives you the structure, but the ACR brings it to life. Together, they are essential for demonstrating conformance, preparing for procurement, and showing that you take inclusion seriously.

    At 216digital, we view accessibility documentation not as a burden, but as a pathway to trust and opportunity. A well-crafted ACR helps you thrive in competitive markets by proving your commitment to accessibility and inclusion.

    If you’d like guidance on creating either document—or aligning both with the latest standards—schedule an ADA briefing with 216digital. Our team will walk you through every step, from drafting a VPAT to publishing a credible ACR, helping you move from paperwork to real-world accessibility.

    Greg McNeil

    September 11, 2025
    Legal Compliance, Testing & Remediation
    Accessibility, ACR, ADA Compliance, Legal compliance, Section 508, VPAT, WCAG, Web Accessibility, Website Accessibility
  • 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
  • Shift Happens—But Not On Focus

    Shift Happens—But Not On Focus

    You press Tab into the first field of a form, and suddenly the page submits. Or you click into a dropdown and, without warning, a new window pops up. Frustrating, right? Now imagine how much more disruptive that is for someone who relies on a screen reader or uses only a keyboard. Sudden shifts don’t just annoy—they break concentration, cause errors, and force users to start over.

    That’s the purpose of WCAG’s Success Criterion 3.2.1 On Focus. It makes sure that receiving focus doesn’t trigger unexpected changes. In short: don’t move the user, reload a page, or submit a form just because something got focus. Users should always stay in control.

    In this article, we’ll unpack SC 3.2.1, look at common pitfalls, explore best practices, and share testing strategies so your site feels consistent, trustworthy, and usable.

    Understanding Success Criterion 3.2.1 – On Focus

    The official wording says: When any user interface component receives focus, it does not initiate a change of context.

    What this really means is that putting focus on an element—whether by tabbing, shift-tabbing, or clicking—should not be treated as an automatic “go” button.

    A change of context includes things like:

    • Submitting a form when a field receives focus
    • Opening a modal or new window on focus
    • Navigating to a new page when a menu item gains focus
    • Programmatically moving focus somewhere else the moment you land on an element

    This rule is designed to stop those surprises. Changes should only happen when users take action—pressing Enter, clicking a button, or making a choice—not just by landing on something.

     Why On Focus Matters

    Predictable focus builds trust. Users know where they are, what’s happening, and how to move forward without being thrown off track.

    For users with cognitive or visual disabilities, avoiding sudden shifts prevents confusion. For those navigating with a keyboard, a smooth and logical tab order makes it possible to move efficiently through content. Screen readers also benefit from a stable focus path, since consistency allows the technology to announce content clearly. And people with motor impairments are spared the frustration of accidentally triggering submissions or navigations they didn’t intend.

    But accessibility isn’t just about a specific group. Predictability benefits everyone. Consistent behavior builds trust and lowers friction, making your site feel polished and respectful of users’ time and effort.

    Common Pitfalls (and Why They Break On Focus)

    Despite the clear intent of SC 3.2.1, developers often run into familiar traps. A few of the most common include:

    • Auto actions on focus: Submitting a form, opening a modal, or swapping pages the instant an input or link gets focus.
    • Focus jumps: Using scripts that automatically call element.focus() on load or on focus, dragging the user to an unexpected spot.
    • Navigation on focus: Menus that redirect as soon as an item is focused, rather than waiting for activation.
    • Broken tab order: Overuse of tabindex—especially with values greater than 0—can create confusing and illogical navigation paths.
    • Inconsistent patterns: Mixing models, where some elements act on focus while others require activation, leads to unnecessary confusion.

    All of these problems do the same thing: they break user flow, create confusion, and increase errors.

    How to Achieve Compliance (and Design a Better Experience)

    Preventing these issues comes down to designing focus behavior intentionally and sticking to a few reliable practices.

    From there, keep a few best practices in mind:

    • Be thoughtful with focus management. If you use element.focus(), do it to genuinely help the user (for example, moving focus into an opened dialog) and respect lifecycle rules.
    • Preserve the natural tab order whenever possible. Use tabindex="0" only when necessary to include custom controls, and avoid positive values.
    • Be cautious with ARIA. Roles like menu, menuitem, tab, and dialog come with built-in interaction expectations. If you implement them, follow the complete pattern—or stick with native controls.
    • Keep patterns consistent. Buttons should submit, links should navigate, and tabs should switch panels only when activated. Uniformity across components builds confidence.

    Small details make a big difference. For example, always include a “Skip to main content” link that becomes visible on focus, and ensure it works correctly by pointing to a landmark or an element with tabindex="-1". Likewise, don’t rely on hover or color changes alone to signal interactivity; provide clear focus styles that work for both keyboard and touch users.

    Testing Strategies for On Focus

    Testing is where theory meets practice. A few methods will quickly reveal whether your site is compliant:

    Manual testing

    • Tab through every interactive element. Nothing should submit, navigate, or open on focus alone.
    • Shift+Tab backward to confirm the reverse path is just as stable.
    • Use Enter or Space to activate controls—only then should real actions occur.
    • In DevTools, run document.querySelector('#el').focus() and verify that no context change happens.

    Assistive Technology Testing

    Screen readers like NVDA (Windows) and VoiceOver (macOS/iOS) are essential. Navigate with Tab, rotor, and quick keys to check that focus remains predictable. On mobile, connect an external keyboard and confirm the behavior is consistent with desktop experiences.

    Automated Checks

    Tools such as Google Lighthouse or WAVE can flag tabindex issues, missing roles, or poor focus order. Automation won’t catch the “surprise factor.” Always back it up with manual and assistive tech testing.

    Bad vs. Good: Concrete Examples

    Bad: Form Submits on Focus

    <form action="/submit" method="post">
      <label for="name">Name:</label>
      <input id="name" type="text" onfocus="this.form.submit()">
    </form>

    Issue: The form submits as soon as the field gains focus—a clear violation.

    Good: Form Submits Only on Activation

    <form action="/submit" method="post">
      <label for="name">Name:</label>
      <input id="name" type="text">
      <button type="submit">Submit</button>
    </form>

    Fix: The form submits only when the user explicitly activates the button.


    Bad: Navigation on Focus

    <nav>
      <a href="/pricing" onfocus="window.location=this.href">Pricing</a>
    </nav>

    Good: Navigation Only on Activation

    <nav>
      <a href="/pricing">Pricing</a>
    </nav>

    Tip: It’s fine to expand a menu on focus for discoverability, but don’t redirect until activation.


    Good Example: Custom Control with Predictable Focus

    <button aria-expanded="false" aria-controls="filters" id="filterToggle">
      Filters
    </button>
    <div id="filters" hidden>
      <!-- filter options -->
    </div>

    This pattern ensures that nothing happens on focus. Activation (click, Enter, or Space) toggles the state, while ARIA reflects the change.

    Frequently Asked Questions

    What’s the primary goal of SC 3.2.1 On Focus?
    To make sure that receiving focus doesn’t cause unexpected context changes. Users, not scripts, decide when to act.

    Is onfocus always forbidden?
    Not necessarily. You can use it for subtle cues like highlighting an element. Just don’t trigger navigation, submissions, or new windows.

    Can focus ever be moved programmatically?
    Yes—if it matches user expectations. For example, moving focus into a modal when it opens, or pointing to an inline error message after a failed form submission, are acceptable.

    How should I handle dynamic components like tabs or accordions?
    Stick to activation-based behavior. Use arrow keys to move between tabs, but only switch panels when a tab is activated, following WAI-ARIA Authoring Practices.

    Build Predictable Experiences (and Trust)

    At its core, SC 3.2.1 is about respect. Focus should never feel like a trap door. By preventing context changes on focus, you protect users from confusion, reduce errors, and make your interface feel stable and reliable.

    Accessible design isn’t just about checking a box—it builds trust. Predictable interactions show users that their time and attention are valued, whether they’re navigating with a screen reader, a keyboard, or a mouse. And when people can move through your site without fear of surprises, they’re more likely to stay, engage, and return.

    If you’re unsure whether your site meets this success criterion—or you’d like expert guidance on weaving accessibility into everyday development—schedule an ADA briefing with 216digital. We’ll review your patterns, coach your team, and help you create consistent, user-friendly experiences that people can rely on.

    Greg McNeil

    September 8, 2025
    How-to Guides, Testing & Remediation
    Accessibility, digital accessibility, How-to, keyboard accessibility, On Focus, Web Accessibility, web developers, web development, 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
  • Web Accessibility: More Than Screen Readers

    Web Accessibility: More Than Screen Readers

    Most teams begin their accessibility work with screen readers. It’s a sensible place to start, and it teaches good habits—clear headings, useful labels, predictable focus. But if you watch how people actually move through the web, the story quickly widens. Someone turns on captions in a quiet office. Another tabs through every link because the mouse hurts their wrist. A shopper zooms text to 200% on a small screen. Others flip on “reduce motion” or prefer calmer layouts that don’t flicker or jump.

    Accessibility is shaped by all of those moments. Screen readers matter, but they’re only one piece of a much larger puzzle. When you consider the full range of human needs—and how different kinds of assistive technology come into play—you end up with digital spaces that feel open, intuitive, and usable for far more people.

    Screen Readers Matter—Just Not Alone

    JAWS, NVDA, and VoiceOver transform what’s on the screen into speech or braille. If your site ignores them, people with vision disabilities get pushed out. Many developers learn a lot by testing with a screen reader: headings need to make sense, labels need to be clear, and focus has to move in a logical path.

    Still, a site can sound fine and feel wrong. Someone who magnifies text might meet a broken layout. A keyboard user might fall into a modal they can’t escape. That gap is the real problem to solve.

    A Wider View of Assistive Technology

    Disability is common, not rare. The World Health Organization estimates that about 1.3 billion people—roughly 16% of the world—live with a significant disability. Only a small slice are blind (about 0.5%), and around 3.7% have moderate-to-severe vision loss. Vision matters, absolutely. But the web serves far more needs than vision alone.

    Auditory Access

    Deaf and hard-of-hearing people need accurate captions and transcripts for video and audio. As more sites publish reels, demos, and webinars, captions move from “nice to have” to “basic courtesy.”

    Motor Access

    Precise mouse movement is tough for many users, and sometimes impossible. Keyboard support is the baseline. Some people navigate by voice or eye-tracking. Real buttons and links—rather than clickable <div>s—make those tools work as expected.

    Cognitive and neurological access. Dense walls of text, busy layouts, surprise pop-ups, and flashing animation raise the mental load. Clear headings, steady patterns, and plain language help people focus and finish tasks.

    Speech Access

    Some users rely on text-based or symbol-based communication. Well-labeled forms, predictable flows, and forgiving error messages make participation possible.

    And here’s a useful twist: not everyone who uses a screen reader identifies as disabled. WebAIM’s 2024 survey found about one in ten regular users said they didn’t use it due to a disability. Preference and context matter, too.

    When a “Pass” Still Leaves People Out

    You can pass a quick check and still miss real-world barriers. Text that won’t resize to 200% without breaking the layout shuts out people with low vision. A menu that can’t be reached—or dismissed—by keyboard blocks shoppers who never touch a mouse. Color-only cues hide errors from users with color-vision differences. Dense, academic language can drain energy from anyone with memory or attention challenges.

    A familiar story: a developer confirms that a form “reads fine,” then a teammate tries it with only Tab and Shift+Tab and can’t reach the submit button. The fix isn’t complicated. The habit is. Test with and without assistive technology, and try the settings your customers actually use.

    Build For Real Use, Not Just Audits

    Automated tools catch a lot, but they cannot tell you if the interaction makes sense. People need to know where they are, what just changed, and what to do next. If something looks like a button, it should behave like one. If an error appears, it should be specific, announced to the right place, and easy to fix. That’s usability and accessibility working together, not two separate tracks.

    Practical Steps That Respect Assistive Technology

    Start with semantic HTML. Headings in order. Real lists. Labels tied to inputs. Landmarks that map the page.

    Make the keyboard a first-class path. Every interactive element should accept focus, show a visible focus style, and respond to expected keys like Enter, Space, and Escape.

    Keep visuals readable. Meet contrast guidelines. Let text scale to at least 200% without hiding content or controls. Never rely on color alone to convey meaning; pair it with text or an icon.

    Use everyday language. Short sentences help. Active voice helps. Concrete verbs help. Jargon is fine when you must use it—just define it once and move on.

    Invite real users into the loop. Include people who rely on assistive technology for sign-in, search, checkout, and support flows. A one-hour session with three users can reveal more truth than a week of back-and-forth about edge cases.

    Baking these habits into design reviews, code reviews, and QA lowers risk and stress. Teams ship calmer products when inclusion isn’t a last-minute scramble.

    Good Usability Helps Everybody

    Design choices aimed at one group often lift all boats. Captions help Deaf users and anyone watching a video on mute. High contrast helps people with low vision and anyone standing in bright sun. Keyboard access helps users with motor disabilities and power users who never take their hands off the keys. The same is true for people using assistive technology on small screens, old laptops, or slow connections—clear structure and predictable behavior make sites feel fast even when networks aren’t.

    Tools That Talk, Design That Listens

    Screen readers changed the web for millions, but they are one part of a broader story. If your site also supports magnification, keyboard navigation, clear language, steady layouts, and strong contrast—while playing well with a variety of assistive technology—you open the door to far more people and far fewer surprises.

    If you’re ready to go beyond the basics, 216digital offers ADA briefings tailored to web teams. These sessions give you space to ask questions, identify gaps, and build an action plan with experts who understand accessibility from both a human and business perspective.

    Greg McNeil

    August 8, 2025
    Testing & Remediation, The Benefits of Web Accessibility
    assistive technology, keyboard accessibility, screen readers
  • 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
1 2 3 … 5
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.