Web Accessibility Archives - Page 2 of 15/Tag

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

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

What Automated Platforms Do Well

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

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

The Role of Accessibility Consultants

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

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

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

Why Consultant-Led Remediation Should Come First

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

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

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

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

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

When Automated Platforms Make Sense

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

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

How to Decide What’s Right for You

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

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

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

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

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

The Long-Term Payoff

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

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

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

Human First, Automation Second

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

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

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

September 17, 2025

Testing & Remediation

Accessibility, Accessibility Remediation, Accessibility testing, automated scans, automated testing, consultants, Web Accessibility, Web Accessibility Remediation, Website Accessibility
Buttons vs Links: Who Gets the Last Click?
You’ve got a component to wire up and a design that looks like… a rectangle with text in it. Classic. Do you reach for <button> or <a>? For a mouse user, either might “work.” For a keyboard user or someone on a screen reader, the wrong choice is a booby trap. Picture a user pressing Space on something that looks like a button and nothing happens, or hearing “Link” and suddenly a file gets deleted. That gap between what an element promises and what it does is where trust dies. By the time you ship this, you should be able to look at any interactive element and decide between buttons vs links without second-guessing.

The Rule Behind Buttons vs Links

There’s one rule worth tattooing on your coding hand:

Links go places. Buttons do things.

If an interaction navigates to a new location (a different route, an external page, a same-page anchor, or a file), it’s a link. If it performs an action on the current page (submits, toggles, opens, closes, mutates UI, updates data), it’s a button. Keep that mental model tight and the rest—semantics, keyboard behavior, screen reader expectations—snaps into alignment.

Let’s make that concrete. Screen readers announce name and role. “Link” tells the user to expect navigation; “Button” says “an action is about to happen.” Keyboard support follows suit: links activate with Enter; buttons activate with Enter and Space. That difference isn’t trivia—it’s the platform contract.

Why This Tiny Decision Matters More Than It Looks

First, semantics affects product quality. When the role and behavior match, users trust your interface—especially users who navigate by role (“jump me to the next button”). Second, robustness. A real link with a real href will still navigate if JavaScript takes a day off. A real button with type="submit" will submit the form without your custom event handlers. Getting buttons vs links right means your UI remains reliable under bad Wi-Fi, flaky extensions, or partial loads.

And yes, standards. Mislabeling roles or breaking keyboard activation is how you wander into WCAG failures like 2.1.1 (Keyboard) or 4.1.2 (Name, Role, Value). It’s not about box-ticking; it’s about delivering predictable, testable behavior.

When It Should Be a Button

If the thing does something on this page, start with <button>. That covers submitting a form, opening a modal, toggling a menu, expanding an accordion, saving a record, deleting an item, starting a fetch, pausing media—anything that changes state without changing URL.

Here’s what not to do:
```

<a href="#" onclick="submitForm()">Submit</a>
```
This announces as “link,” ignores the Space key unless you recreate that yourself, and fails if JavaScript is blocked. Use the element that already does the job:
```

<button type="submit">Submit</button>
```
Toggles are another frequent offender. If you’re opening and closing a menu, use a button and reflect state:
```
<button
  type="button"
  aria-expanded="false"
  aria-controls="mainmenu"
  id="menubutton">
  Menu
</button>

<nav id="mainmenu" hidden>…</nav>
```
When you flip the menu, flip aria-expanded and manage the hidden attribute. Users get the correct announcement, and you get keyboard support for free.

A quick style note while we’re here: don’t remove the focus outline unless you replace it with something obvious. Minimalism is lovely; invisible focus isn’t.
```
button:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 3px;
}
```
When It Should Be a Link

If the action navigates—new page, external site, file download, or a jump within the same page—reach for <a> with a real href. That gives you built-in affordances like “open in new tab,” a visible status bar URL, and the user’s browser history doing its thing.

Bad pattern:
```

<button onclick="location='/about'">Learn more</button>
```
Fix it:
```

<a href="/about">Learn more</a>
```
A few patterns that absolutely belong to links:
- Skip links: let keyboard users bypass repeating navigation.
```
 <a href="#main" class="skip-link">Skip to main content</a>
<main id="main">…</main>
```
- Downloads: if you can link it, link it.
```
 <a href="/report.pdf" download>Download report (PDF)</a>
```
- Breadcrumbs and primary nav: always links. Users expect middle-clicks and new tabs to work.
Give the link text meaning. “Click here” ages badly outside its paragraph. “Download Q3 report (PDF)” holds up wherever a user encounters it—like a screen reader’s Links List.

Styling Without Lying: Buttons vs Links in Disguise

Design will ask you to make links look like buttons or vice-versa. That’s fine visually, as long as the semantics don’t lie. If it navigates, keep it an <a>—then style it like a button. If it acts, keep it a <button>—then style it to match your theme. Users might not see the markup, but assistive tech will, and so will your QA.

A few constraints worth honoring while you polish:
- Don’t rely on color alone to signal “this is a link.” Underlines or a small icon are your friends.
- Keep contrast sane (think 4.5:1 for normal text). Your future self, reading in sunlight, says thanks.
- Targets should be comfortably tappable—around 44×44 CSS pixels is a good baseline.
- Maintain a visible focus style. If you nuke it, put a better one back.
Testing the Decision: Buttons vs Links Under Real Inputs

Automated tools are a fast smoke test—Lighthouse or WAVE will happily rat out missing names, broken contrast, or off-screen focus. Treat them as lint for accessibility. They won’t catch intent.

Intent is a manual game:
- Screen reader pass: with VoiceOver (macOS/iOS), NVDA or JAWS (Windows), confirm elements announce the correct role and name: “Button, Submit,” not “Link, Submit.”
- Keyboard pass: tab through. Links should activate with Enter; buttons with Enter and Space. Watch focus—no disappearing acts.
- Voice control: say “Click Submit” or “Go to Pricing,” and make sure the right control responds by name.
If any of those feel off, they are off. Fix the semantics first; the bugs usually evaporate.

Real-World Fixes That Come Up in Code Reviews

Most bugs we see with buttons vs links boil down to “we styled the wrong element” or “we tried to be clever with roles.” Two quick refactors cover a lot of ground:

Submitting with an anchor:
```

<a href="#" onclick="submit()">Submit</a>


<button type="submit">Submit</button>
```
Menu toggles built on anchors:
```

<a href="#" onclick="openMenu()">Menu</a>


<button type="button" aria-expanded="false" aria-controls="mainmenu">Menu</button>
```
If you truly, absolutely must build a custom control—and you’ve checked that <button> won’t cut it—own the keyboard and state explicitly:
```

<div role="button" tabindex="0" aria-pressed="false" id="play">Play</div>
<script>
const el = document.getElementById('play');
el.addEventListener('keydown', (e) => {
  if (e.key === ' ' || e.key === 'Enter') { e.preventDefault(); el.click(); }
});
el.addEventListener('click', () => {
  const next = el.getAttribute('aria-pressed') !== 'true';
  el.setAttribute('aria-pressed', String(next));
});
</script>
```
That’s a lot of ceremony to re-implement what <button> just… does. Treat this as a last resort.

A Short Checklist (Pin It Next to Your Linter)
- Navigation? <a href="…">. Action? <button>.
- Make the accessible name obvious: visible text or a clear aria-label.
- Preserve expected keyboard behavior (Enter vs Enter+Space).
- Keep focus visible and movement logical.
- Prefer native elements; avoid role-swapping unless there’s no alternative.
Wrapping It Up

Interfaces are a web of tiny decisions, and this is one of the tiniest. But consistent, honest semantics make everything else easier: testing, maintenance, onboarding new devs, and—most importantly—using the thing. Treat buttons vs links as a contract. Say what the element is, and make sure it behaves that way across mouse, keyboard, screen readers, and voice.

If you want a quick heuristic while you code: would a middle-click make sense here? If yes, it’s probably a link. Would “Click Submit” make sense to a voice user? If yes, it’s probably a button. Keep those instincts sharp and your UI will feel clean, resilient, and respectful by default.

If your team wants a second set of eyes on patterns like these—or you need help pressure-testing components before they scale—216digital is happy to jump in. Schedule an ADA briefing and we’ll help you turn the “tiny” choices into durable, inclusive defaults.
Greg McNeil

September 16, 2025

How-to Guides

Accessibility, Accessible Buttons, Links, Web Accessibility, Web Accessible Links, web developers, web development, Website Accessibility
ADA Title II Compliance: Your 2026 Countdown Begins
April 2026 is fast approaching, and it marks a pivotal shift in how government and educational institutions must deliver their digital services. In April 2024, the U.S. Department of Justice (DOJ) finalized new rules under Title II of the Americans with Disabilities Act, requiring that public entities make their websites and mobile apps conform to WCAG 2.1 Level AA standards.

This update creates a clear and enforceable standard for digital accessibility—and a fixed timeline. Large entities serving 50,000 or more people must achieve ADA Title II compliance by April 24, 2026. Smaller entities, including towns, special districts, and small school systems, must follow by April 26, 2027.

This isn’t just about meeting regulations. It’s about ensuring that everyone—including people with disabilities—can use essential public services online, from paying utility bills to registering for classes or receiving emergency alerts.

Understanding the Scope of ADA Title II Compliance

The rule applies to nearly all state and local government organizations, including:
- Cities, counties, and municipalities
- Public universities and school districts
- State agencies and special districts such as transit, water, or fire authorities
It also indirectly includes any private vendors that design, build, or maintain digital platforms for these organizations. Even if a vendor creates or operates your digital platform, responsibility for accessibility—and legal liability—remains with the public entity.

This broad scope means development, design, content, and procurement teams must work in sync. Accessibility is no longer a “nice to have” feature or a patchwork afterthought. It must be an intentional part of the lifecycle of digital services.

The New Baseline: WCAG 2.1 Level AA

For years, WCAG has served as the de facto best practice for digital accessibility. Now, it’s the legal benchmark. ADA Title II compliance requires conformance to WCAG 2.1 Level AA across websites and mobile apps.

The WCAG framework is built on four key principles:
- Perceivable: Information must be presented in ways users can recognize and process—through sight, sound, or touch.
- Operable: All functionality must be usable via a range of input methods, such as keyboards or voice controls.
- Understandable: Content and interfaces should be clear, consistent, and predictable.
- Robust: Code must follow accepted standards to work reliably with assistive technologies.
For developers, this translates into semantic HTML, accessible form structures, proper use of ARIA where needed, support for keyboard navigation, sufficient color contrast, captions and transcripts for media, and responsive design that works across devices.

Key Deadlines and Limited Exceptions

The DOJ’s final rule establishes staggered deadlines to account for the varying resources of different entities:
- April 24, 2026: Large public entities (50,000+ population) and major school districts must comply.
- April 26, 2027: Smaller municipalities, rural counties, special districts, and small school systems must comply.
Some content is exempt: archived web materials, third-party content not posted by the entity, individualized password-protected content (like a specific utility bill), preexisting social media posts, and older electronic documents not currently in active use. These exceptions are narrow and shouldn’t be treated as a loophole—most public-facing content still must be accessible.

Why This Deadline Signals a Shift

This rule does more than set a date. It establishes a uniform digital standard across public services—and that’s transformative.

By naming WCAG 2.1 Level AA as the clear benchmark, it ends ambiguity. Public trust is strengthened as people with disabilities gain guaranteed equal access. Legal risk drops as the gray areas that once fueled costly lawsuits and settlements disappear. At the same time, accessibility is pushed to the forefront of digital strategy instead of being treated as an optional side task.

Accessibility now sits at the center of how public organizations plan, design, build, and maintain their digital platforms.

A Phased Roadmap Toward ADA Title II Compliance

Because comprehensive remediation can take months—or longer for complex ecosystems—waiting until late 2025 risks running out of time. A phased approach helps build steady momentum.

Phase 1: Assess and Organize (Now through Mid-2025)

Begin by identifying who will lead accessibility efforts. Take inventory of every public-facing digital property, including web apps, mobile apps, forms, and documents. Then schedule a thorough accessibility audit, prioritizing the most used or most critical services like billing systems, course registration, or emergency alerts.

Phase 2: Plan and Prioritize (Mid-2025 through End-2025)

Use your audit findings to map out a remediation plan tied to your budgeting cycles. Secure executive buy-in early. Accessibility should be positioned as a matter of governance and public trust, not just a technical task assigned to IT.

Phase 3: Remediate and Test (Early 2026)

Implement code-level fixes, update design patterns, and correct content barriers. Use both automated and manual testing, and incorporate usability testing with people who use assistive technologies. Their insights will surface barriers that automated tools often miss.

Phase 4: Embed in Procurement and Governance (Ongoing)

Update procurement language to require WCAG 2.1 AA conformance for all vendors. Include accessibility testing, documentation, and verification milestones in contracts. Establish internal policies for accessible design and development practices going forward.

Phase 5 : Maintain Accessibility Long-Term (Post-Deadline)

Schedule recurring audits, provide continuous staff training, and build accessibility checks into your development and content workflows. Establish a feedback channel for users to report barriers and ensure those reports trigger timely remediation.

Common Pitfalls That Derail Progress

Even well-intentioned teams can lose ground as deadlines approach. These are common issues to avoid:
- Stopping at the audit: An audit reveals issues; it doesn’t fix them. Plan for remediation, re-testing, and validation.
- Over-relying on automation: Automated tools catch only a fraction of WCAG criteria. Manual reviews are essential.
- Leaving vendors unchecked: Accessibility obligations don’t end at the contract signature. Require proof of ADA Title II compliance.
- Relying on overlays or widgets: These often fail to solve root issues and can introduce new barriers.
Beyond April 2026: Sustaining ADA Title II Compliance

ADA Title II compliance is not a project that ends on launch day—it’s an ongoing obligation. Accessibility should become a standing component of your governance model.

Include accessibility reviews in your CI/CD pipelines to catch regressions early. Track and adopt updates to WCAG—2.2 has already arrived, and 3.0 is in development. Maintain documentation of policies, testing protocols, and training records to demonstrate due diligence if audited or challenged.

And don’t overlook communication. Sharing progress with your community shows accountability and reinforces public trust. Transparency builds confidence, both internally and externally.

Getting Started Now

You don’t need to overhaul everything at once. Early, visible progress helps build support and momentum. Start by:
- Conducting a comprehensive audit to establish a baseline
- Fixing accessibility barriers on high-traffic pages and applications
- Training staff who create or maintain digital content
- Updating vendor contracts and procurement templates with WCAG 2.1 AA language
- Implementing ongoing monitoring to prevent regressions
Even these first steps will make your platforms more usable while laying the foundation for full compliance.

Turning Deadlines Into Opportunity

The 2026 and 2027 deadlines for ADA Title II compliance are closer than they seem, but they’re absolutely achievable. With a deliberate plan, you can meet the requirements without last-minute scrambles—and create more inclusive digital services in the process.

This is more than a legal mandate. It’s a chance to improve the experience for everyone who relies on your digital platforms. Starting now allows you to spread out the workload, secure the resources you need, and avoid costly last-minute vendor rushes.

If you need support, 216digital partners with public entities to conduct audits, provide remediation, train teams, and implement ongoing monitoring.

Now is the moment to prepare. Schedule an ADA briefing and set your roadmap in motion—on time, on mission, and built to last.
Greg McNeil

September 15, 2025

Legal Compliance

Accessibility, ADA, ADA Title II, ADA Website Compliance, Title II, Web Accessibility, Website Accessibility
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?

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

Aspect	Accessibility Audit	VPAT (ACR)
Primary purpose	Identify issues; deliver remediation guidance; validate usability	Communicate conformance status to buyers and regulators
Audience	Internal teams: product, engineering, design, compliance	External stakeholders: procurement, clients, regulators
Format	Narrative report with prioritized findings and fixes	Standardized template leading to an ACR with criterion-by-criterion statements
Evidence	Manual/AT testing, sometimes user testing with people with disabilities, plus automation	Summaries of conformance based on testing evidence
Timing	Best before launch/redesign, after significant releases, or upon risk events	Best during RFPs, renewals, market entry, or when a contract requires it
Outcome	Improved accessibility and user experience	Procurement-ready disclosure and contractual clarity
Update cadence	With each major release or accessibility milestone	Whenever 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

Class Is in Session for Digital Accessibility
In the first week of school, a parent tried to submit a health form from her phone. The fields weren’t labeled, the keyboard focus jumped, and the “Submit” button never announced itself to her screen reader. Ten minutes later, she gave up—and the nurse never received the update. Small details in the interface had big, human consequences. This is why digital accessibility belongs on the same list as notebooks, logins, and bell schedules.

Accessibility on campus isn’t only ramps and elevators. The real campus now includes the learning management system, the student information system, online forms, classroom apps, digital textbooks, videos, and PDFs uploaded by teachers. When these touchpoints aren’t designed for everyone, the barriers are invisible but very real. Students miss assignments. Parents miss announcements. Teachers spend late nights wrestling with tools instead of teaching. Administrators field complaints they didn’t anticipate.

When School Technology Leaves Learners Behind

For ninth-grader using a screen reader doesn’t just see an untagged PDF as a small annoyance—it’s a wall. When a teacher is posting materials after hours, clear headings and alt text can be the difference between “done” and another late night reformatting. And for families juggling multiple jobs, captions and plain language turn school updates into something everyone can follow on the first read.

Digital accessibility gives every learner a fair start and lets ability—not the interface—decide the outcome. When a student can tab through an assignment form, a parent can complete it by voice on a phone, and a teacher’s resources read cleanly in NVDA or VoiceOver, learning gets easier for everyone.

What Digital Accessibility Looks Like in a School Context

Good accessibility is concrete and testable in the tools schools use every day:
- Structure and navigation. Pages use semantic headings, lists, and landmarks so assistive tech can move through the outline—not just the visuals. Menus are reachable with a keyboard and the focus is always visible.
- Forms that behave. Labels are programmatically tied to inputs, errors are described in plain language, and status messages are announced to screen readers.
- Accessible media. Videos include accurate captions; long recordings offer transcripts. Audio descriptions are available for essential visuals.
- Documents that travel well. PDFs are tagged with a correct reading order, real headings (not just bigger fonts), and alt text for images; exported DOCX/Slides preserve structure.
- Consistent components. Buttons act the same across the district site and the LMS; modals trap focus appropriately; alerts are announced.
- Language that teaches. Instructions avoid jargon, and content is written so a student or caregiver can follow it without specialized knowledge.
These are the details that turn “a student can technically reach the page” into “a student can actually complete the task.”

The Power of Accessibility Audits for Schools

If you want the honest state of your district site or campus platforms, start with an accessibility audit. A strong school-focused audit runs three complementary passes:
1. Automated scans to surface quick signals—contrast issues, unlabeled buttons, missing form labels, heading misuse.
2. Expert reviews with real assistive tech (e.g., NVDA/JAWS on Windows, VoiceOver on iOS and macOS) and keyboard-only navigation, mirroring how students and parents actually use the tools.
3. Task-based flows tied to school outcomes: enroll a student, submit a health form, find an IEP meeting notice, complete a quiz, download a worksheet and read it in a screen reader.
Automated tools catch a subset of problems; many of the blockers we see in schools—focus traps in portals, ambiguous link text like “Click here,” modals that don’t announce, inaccessible math or charts—require human judgment. The output of a good audit is practical: a ranked list of fixes tied to user impact, so IT and curriculum teams know what to tackle first, what can wait, and how to validate before the next release.

VPATs and ACRs: What Procurement Really Needs

After you address material issues, you’ll often need to document where your product or campus tool stands. That’s the role of a Voluntary Product Accessibility Template (VPAT®) and the resulting Accessibility Conformance Report (ACR)—structured reports that map conformance to standards such as WCAG 2.1 and, where applicable, Section 508.

For districts and universities, this is a procurement gate. Many will not move forward with an ed-tech vendor unless a current VPAT/ACR is provided and reviewed. A useful report is specific about what conforms and candid about gaps, with timelines and workarounds for instruction. That transparency earns more trust than vague “compliant” claims and helps committees compare solutions on equal footing.

Treat the audit as the truth-finding step and the VPAT/ACR as the communication layer. One improves the product students touch; the other explains to procurement and digital accessibility coordinators where it stands today.

Why Audits and VPATs Are Stronger Together (in Education)

Sequence matters:
1. Audit first. Identify barriers through expert and task-based testing aligned to real school workflows.
2. Remediate and retest. Fix code, refine content, update components, re-export documents correctly, and verify behavior with assistive tech.
3. Document with a VPAT/ACR. Communicate conformance clearly, including known gaps and planned remediation.
Reversing that order tempts over-promising and erodes credibility with accessibility coordinators, legal counsel, and curriculum leaders. Done in sequence, you earn trust and set a cadence your team can sustain throughout the year.

Build Digital Accessibility Into the School Year (Without Adding Endless Meetings)

Lasting progress comes from folding accessibility into normal practice:

1) Start With High-impact Fixes

Address keyboard navigation, focus order, alternative text, captions, contrast, and form labels across the district site and LMS. These unblock core tasks quickly.

2) Equip Every Role.
- Teachers: short checklists for posting accessible materials (headings, alt text, captioning options, accessible templates).
- Content specialists: guidance for writing in plain language and structuring documents for export.
- Developers/IT: patterns in your design system for buttons, modals, alerts, and form components with accessible defaults.
- Administrators: a simple rubric to evaluate ed-tech tools before adoption.
3) Bake Testing Into Releases

Before shipping portal updates or new templates, run a brief keyboard pass, a screen reader pass on key pages, and a contrast check on new UI. Keep it lightweight and repeatable—fifteen minutes can prevent weeks of support tickets.

4) Treat PDFs and Slides as Instructions, Not Attachments

Tag reading order, add bookmarks, write alt text, ensure exported files preserve structure, and prefer HTML or native formats when possible. If a document matters for learning, its accessibility matters.

5) Monitor and Iterate

School tech evolves constantly. Schedule periodic audits (e.g., pre-semester and mid-year), track accessibility issues like any other quality defect, and update your VPAT/ACR when material changes land.

Why This Matters for Teaching and Learning

Accessible technology doesn’t only prevent complaints—it improves learning:
- A captioned science video helps a deaf student follow along and helps a tired parent review content after a late shift.
- Clear headings in a history reading help a student with ADHD navigate and return to key sections.
- A well-labeled quiz with announced status messages reduces anxiety for students using screen readers.
- Plain-language instructions in the LMS lower the cognitive load for everyone, including multilingual families.
When digital accessibility is present, students get through important moments without roadblocks, teachers spend more time on pedagogy than troubleshooting, and families feel genuinely included in school life.

A Long-Term Strategy for Inclusive Schools

Digital accessibility is strategic infrastructure for education. Districts and campuses that invest in it reach more learners, reduce friction for families, and build trust across classrooms, offices, and board rooms. New terms begin all the time—new semesters, new platforms, new cohorts. Build them to include the people you intend to serve.

Ready for a concrete plan tailored to your school or district? Schedule an ADA briefing with 216digital. We’ll review your tech stack, content workflow, and procurement goals, then leave you with a prioritized roadmap and clear next steps your team can ship this term.
Greg McNeil

September 9, 2025

Legal Compliance

Accessibility, How-to, VPAT, WCAG, Web Accessibility, Website Accessibility
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>
  
</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
How to Create a Strong Web Accessibility Policy
A web accessibility policy is more than a document—it’s a framework that defines how your organization approaches inclusivity, compliance, and digital responsibility. Without one, accessibility efforts can become inconsistent, reactive, or misunderstood. With one, your team gains a roadmap that builds accountability, supports compliance with laws like the ADA and Section 508, and demonstrates a commitment to all users.

Think of your policy as both a shield and a compass. It protects your organization by showing good-faith effort to regulators, but it also guides your team toward continuous improvement.

Why Your Organization Needs a Policy

Accessibility policies matter for more than just legal defense. Internally, they bring clarity across departments—from IT to marketing to compliance—so everyone understands which standards to follow. They ensure accessibility isn’t dependent on one person’s expertise or limited to a single project cycle.

Externally, a policy builds trust. Customers, investors, and partners see that accessibility is part of your values, not an afterthought. And strategically, accessibility opens doors: people with disabilities and seniors represent nearly half a trillion dollars in disposable income. A policy is a first step toward serving that audience well.

Core Elements of a Strong Web Accessibility Policy

Purpose and Commitment

Begin with a statement of intent. This should be more than a generic declaration; it should connect accessibility to your organization’s mission. For example:

“Our organization is committed to ensuring digital accessibility for all users, including people with disabilities and seniors. We strive to meet or exceed recognized accessibility standards and continuously improve the user experience.”

This opening sets the tone by making accessibility a matter of principle, not just compliance.

Scope

A good web accessibility policy makes it clear what’s covered. Websites are obvious, but often overlooked are mobile apps, intranet systems, PDFs and digital documents, and even third-party platforms like payment processors or video players. By spelling out the scope, you avoid leaving accessibility responsibility in a gray area between departments.

Standards and Guidelines

Policies must be tied to recognized standards. Most organizations point to WCAG 2.1 or 2.2 at Level AA, which is the global baseline. In some cases, ATAG (Authoring Tool Accessibility Guidelines) and UAAG (User Agent Accessibility Guidelines) may also apply, especially if your team develops content management systems or provides custom controls. Referencing these standards prevents vague promises and gives your teams concrete goals.

Accountability

Accessibility only works when responsibilities are clear. Your web accessibility policy should describe who does what—leaders allocate resources, designers and developers build accessible systems, content creators ensure their materials are accessible, and quality assurance checks for compliance. Including procurement teams is especially important, since third-party vendors often introduce accessibility risks.

Testing and Monitoring

Accessibility is not something you achieve once and then check off the list. Your web accessibility policy should outline how accessibility will be tested and monitored over time. Automated scans are helpful but limited; manual testing with screen readers, keyboard navigation, and zooming provides a more accurate picture. Involving people with disabilities in testing is the gold standard. Regular audits—quarterly or annual—should be part of the plan, along with ongoing monitoring through services like a11y.Radar.

Training and Culture

Accessibility knowledge fades without reinforcement. A strong policy requires training for new employees during onboarding, refresher sessions for existing staff, and resources to keep accessibility visible in everyday work. This shifts accessibility from being the job of a few specialists to a shared organizational culture.

Feedback and Grievance Process

Your users need a way to tell you when something isn’t working. Policies should establish a clear feedback mechanism, such as a dedicated email or form, along with expected response times and escalation steps. Done well, this process builds credibility and helps you identify issues before they turn into legal complaints.

Review and Updates

Accessibility standards evolve, and your policy must evolve with them. Commit to reviewing it on a set schedule—at least once a year—and name the role or department responsible for updates. That way, your policy doesn’t quietly drift into irrelevance.

Internal Policy vs. Public Accessibility Statement

One point that’s often misunderstood is the difference between a web accessibility policy and an accessibility statement.

A policy is usually internal, designed to align your staff around roles, standards, and processes. A statement, on the other hand, is public-facing. It communicates your organization’s accessibility efforts, acknowledges areas that may not yet meet standards, and tells users how to get help.

Both are necessary. The internal policy keeps your team aligned, while the public statement demonstrates accountability and transparency to your users. The World Wide Web Consortium (W3C) recommends keeping the internal policy more detailed and technical, while making the statement concise, approachable, and easy to find on your website—often linked in the footer near your Privacy Policy.

Common Pitfalls

Many organizations stumble by making their policies too vague (“we aim to be accessible”) or too ambitious (“we guarantee full compliance at all times”). Others fail to address vendors or neglect to include a way for users to provide feedback. A strong policy balances realism with accountability and leaves no room for ambiguity.

Moving from Policy to Practice

A policy isn’t a box to check—it’s the start of an ongoing process. To put it into practice:
- Integrate accessibility into procurement so third-party tools don’t create barriers.
- Build accessibility into project lifecycles rather than tacking it on at the end.
- Track progress with measurable outcomes, such as reduced accessibility errors in audits.
- Share updates internally and externally to demonstrate that accessibility is a living priority.
Drafted. Signed. Now, Let’s Do This.

A web accessibility policy is more than paperwork. Done well, it declares your commitment, defines your scope, sets standards, assigns responsibility, and ensures accountability through testing, training, and review. By avoiding vague promises and grounding your policy in specific, actionable steps, you give your organization the confidence to serve all users fairly and consistently.

If you’re ready to move from intention to implementation—whether you’re just starting, mid-remediation, or refining a mature program—schedule an ADA briefing with 216digital. In one focused session, our experts will meet you where you are, assess your current posture, and outline a practical, prioritized path toward sustainable web accessibility.

Looking for a place to begin drafting your own policy?

Download our Sample Web Accessibility Policy Template to jumpstart your efforts and adapt it to your organization’s needs.
Greg McNeil

August 27, 2025

How-to Guides

accessibility policy, How-to, Web Accessibility, Website Accessibility
AI-powered Checks for Accessible PDF: Are They Enough?
Your team ships PDFs every week—policies, forms, reports. They look polished. But if a screen reader hits the footer before the body, the file isn’t usable. That’s the gap an accessible PDF is meant to close. Laws like Section 508 and WCAG don’t treat PDFs as special exceptions; if a document lives on your site, people should be able to move through it as easily as a web page. AI helps with the basics and saves time. The real question: how far can you trust it on its own?

Before we dig into tools, here’s how the standards actually fit together.

What An Accessible PDF is—And Why the Law Cares

Two complementary standards govern PDF accessibility. PDF/UA (ISO 14289) defines how a PDF’s internals must be constructed so assistive technologies can reliably parse and convey the content. The Web Content Accessibility Guidelines (WCAG) governs outcomes when that PDF is published on the web—what users must be able to perceive, operate, understand, and rely on.

PDF/UA (ISO 14289): Technical Conformance

PDF/UA requires a correct structure tree with semantically appropriate tags (headings, lists, tables, figures), accurate role mapping, and a logical reading order. It expects:
- Properly associated table headers and scopes.
- Descriptions for non-text content; decorative material marked as artifacts.
- Form fields (AcroForms) with programmatically associated labels, names, and instructions.
- Declared document language and consistent language shifts where needed.
- Links, bookmarks, and metadata that reflect actual structure.
- The goal is consistent exposure of semantics to accessibility APIs so screen readers announce content as intended.
WCAG for PDFs: Publication Context and User Outcomes

When a PDF is part of web content, WCAG success criteria apply (e.g., 1.3.1 Info and Relationships, 1.3.2 Meaningful Sequence, 2.4.6 Headings and Labels, 3.1.1 Language of Page). WCAG focuses on the experience: users must navigate by headings, traverse content in a meaningful sequence, operate everything via keyboard, and understand relationships in tables, lists, forms, and links.

How They Fit Together

Think of PDF/UA as the engineering spec (how the file is built) and WCAG as the published experience (what users can actually do). Meeting one without the other leaves gaps—either structurally sound but unusable in context, or polished in presentation but unreliable under the hood.

Operational Definition of “Compliant”

In practice, compliance means a screen-reader user can:
- Move by headings in a sensible hierarchy;
- Traverse content in sequence;
- Complete forms with announced labels and instructions;
- Understand tables with correctly exposed headers;
- Access links and landmarks without detours.
With the standards context set, let’s look at why many PDFs still miss—and where automation helps versus where expert review remains essential.

Why PDFs Are So Often Non-compliant

Most teams don’t author in PDF first; they export—and that’s where trouble starts. Typical failures include missing or incorrect tags, reading orders that jump around, scanned pages without OCR, and forms or tables whose structure isn’t exposed to assistive tech. A quick snapshot:
- No tags or the wrong tags → a screen reader announces “graphic, graphic, graphic” through a one-page flyer.
- Reading order off → Footnotes should be read before the body copy.
- Scanned pages with no OCR → 12 images, zero searchable text.
- Mis-structured forms/tables → required fields can’t be reached; headers don’t announce.
At scale—monthly statements, board packets, downloadable reports—small mistakes multiply. The volume is exactly why many teams turn to automation to keep pace and to move each file closer to an accessible PDF without starting from scratch.

What AI-powered Accessibility Tools Do Well (Today)

Give an AI checker a clean annual report and it can often spot headings, set a reasonable reading order, and propose alt text you can refine. That alone can cut remediation time significantly. Modern tools handle a few tasks particularly well:
- Recognizing layout blocks (headings, paragraphs, lists)
- Running OCR on scanned content to restore real text
- Drafting tags for simpler figures (e.g., charts vs. logos)
- Flagging obvious misses (untagged images, empty titles, missing language metadata)
They’re fast, consistent, and tireless. Most importantly, they reduce the grunt work so specialists can spend time where judgment matters. What they can’t do is confirm that structure equals meaning—or guarantee that the end result behaves like an accessible PDF for every user scenario.

Where AI Still Falls Short—and Why People Still Matter

Some documents ask more than a model can answer. Two common gotchas:
- Nested tables and forms. A claims form with merged cells can look “tagged” but read like alphabet soup.
- Meaning vs. style. A bold sentence in a paragraph isn’t a heading; many models tag it that way.
Tools also struggle with language switches mid-document, disclaimers that must tie to the right section, and reading orders that look logical to software but feel disorienting in a screen reader. A file may “pass” an automated check yet remain frustrating to use. That gap is not just usability—it’s risk. A defensible review still needs a human to ask: Does this read like an accessible PDF for someone relying on assistive tech?

The Hybrid model for Accessible PDF Compliance

Start with the tool, finish with a person.
- AI first pass: establish the skeleton, set reading order, surface missing text alternatives, and catch obvious metadata gaps.
- Human pass: repair tables, confirm form flow, check headings/links, and test a few pages with NVDA or VoiceOver.
- Evidence trail: keep a short log of what changed and who checked it; if questions come later, you have the paper trail.
This model balances speed with judgment. It scales because automation removes repetition while reviewers focus on the parts that shape the experience and, ultimately, compliance for an accessible PDF in the real world.

AI is Powerful, But Not a Solo Act

AI can accelerate the work, but it can’t replace judgment. If you’re balancing risk with reality, a two-pass workflow (tool, then human) is the path that holds up. The payoff is practical: fewer errors, faster cycles, clearer records, and a more reliable accessible PDF experience for your audience.

If you want a second set of eyes—or a process your team can pick up and run—216digital can help. Schedule an ADA briefing with 216digital, and we’ll map a workflow that fits your documents, your deadlines, and your compliance goals.
Greg McNeil

August 26, 2025

Legal Compliance

Accessibility, accessible PDF, Ai and Overlay Widgets, AI-driven accessibility, PDF, PDF/UA (ISO 14289), WCAG, Web Accessibility, Website Accessibility
Web Accessibility Checklist for CA Businesses
California sets the tone for digital accessibility—and businesses can’t afford to ignore it. Between strict state laws, federal regulations, and an active litigation environment, accessibility isn’t just a best practice; it’s a requirement.

This guide breaks down what compliance means in California and gives you a step-by-step web accessibility checklist you can actually use. Think of it as a roadmap that not only lowers legal risk but also creates a better experience for every visitor on your site.

Why Accessibility Matters in California

California is one of the most aggressive states when it comes to enforcing web accessibility. Both federal and state laws apply, creating more risk for businesses with an online presence.

A few things you should know:
- ADA (Americans with Disabilities Act): Courts in California have ruled that websites and apps connected to physical businesses must be accessible. Cases like Robles v. Domino’s made that crystal clear.
- Unruh Civil Rights Act: Unique to California, this law ties into the ADA but adds monetary damages—starting at $4,000 per violation. Multiple issues can multiply costs quickly.
- CPRA (California Privacy Rights Act): Privacy notices, opt-outs, and user controls must also be accessible to people with disabilities.
- AB 434 (Public Agencies): Requires California government websites to meet WCAG 2.0 AA.
- Section 508 (for federal contractors): Applies if you do business with federal or state-funded entities.
- AB 1757 (Pending): Would make WCAG 2.1 AA mandatory for all California websites and allow individuals to sue directly.
Your California Web Accessibility Checklist

Think of this web accessibility checklist as an ongoing process—not a one-time project. Accessibility isn’t something you can “fix” and walk away from. Each new feature, design tweak, or plugin you add can introduce fresh challenges, so it’s best to weave accessibility into your regular site reviews and updates.

1. Know Your Legal Landscape

Before you start making changes, pause and figure out which laws apply to your organization. A private company, a public agency, and a government contractor each face different sets of rules—and knowing where you fall will shape your strategy.

Begin by asking a few simple questions:
- Is your business based in California, or do you simply serve California residents?
- Which laws apply to you? That could mean the ADA, the Unruh Civil Rights Act, CCPA/CPRA, Section 508, AB 434 for public sector sites, and potentially AB 1757 once it takes effect.
- Who in your organization should own accessibility? Whether it’s your legal lead, a developer, or someone on the marketing team, make sure accountability is clear—and involve design, development, content, and legal voices early.
2. Identify Your Accessibility Gaps with a Web Accessibility Checklist

Once you know your obligations, it’s time to take an honest look at your website. Where might someone hit a barrier?

Start with an automated scan like Google Lighthouse, or WAVE. Tools like these are great for catching obvious issues—missing alt text, weak color contrast—but they only scratch the surface. The real insights come from manual testing. Try navigating your site using just a keyboard, or fire up a screen reader. Can you move through forms, menus, and checkout without a mouse? Does everything make sense when spoken aloud?

Keep careful notes as you go. Screenshots, detailed observations, and a running log of issues will help guide your fixes. Just as importantly, they also show good-faith effort if your compliance is ever questioned. Using a web accessibility checklist here helps you capture both the technical and usability gaps

3. Fix Barriers and Align with WCAG 2.2 Level AA

Now comes the hands-on work: fixing the barriers you’ve found. The most reliable standard to aim for is WCAG 2.2 Level AA, since courts and regulators often look to it as the baseline. WCAG breaks accessibility into four guiding principles—Perceivable, Operable, Understandable, and Robust (POUR). Here’s what that means in practice:

Perceivable
- Add alt text to all meaningful images
- Make sure text can be resized up to 200% without breaking layouts
- Provide captions, transcripts, and audio descriptions for multimedia
- Avoid relying solely on color to communicate information
- Keep text-to-background contrast strong
- Indicate language changes in your site’s code
Operable
- Make sure every function works via keyboard
- Add a “Skip to Content” link so users don’t have to tab endlessly
- Keep buttons, icons, and menus predictable
- Prevent content from shifting unexpectedly when users interact with it
- Let users pause or stop auto-play and extend time limits on forms
- Support both portrait and landscape orientations
Understandable
- Use clear, descriptive headings and labels
- Write page titles that actually reflect what’s on the page
- Make sure error messages are easy to spot and explain how to fix them
Robust
- Test your site across different devices and screen sizes
- Ensure functionality for users with limited mobility
- Use semantic, well-structured HTML so assistive tech works correctly
- Keep content usable even when text spacing is adjusted
4. Don’t Forget Privacy and Legal Disclosures

Accessibility doesn’t stop at your homepage or checkout process. In California, your privacy notices, cookie banners, and consent forms are just as important.

That means every checkbox, toggle, and opt-out option should be easy to reach with a keyboard and clear to a screen reader. Focus states should stand out, and every label should be tied programmatically to its control. When it comes to policies, avoid dense blocks of text. Instead, break them into sections with clear headings and write in plain, straightforward language. And whenever you link to something, make the link text meaningful—skip the vague “click here.” Regulators will expect these areas to meet the same accessibility standards as the rest of your site. A web accessibility checklist can serve as a reminder to evaluate these areas, which often get overlooked.

5. Plan for Ongoing Compliance

The last step is about staying consistent. Accessibility isn’t a box you check off—it’s a practice you build into your regular workflow.

Set up a review schedule: quarterly audits for the full site, plus monthly spot checks for high-traffic pages. Fold accessibility into your design reviews, pull requests, and release cycles so issues get caught early.

Be especially careful with third-party tools. Chat widgets, plugins, and embedded media can easily create barriers if they aren’t coded properly. Vet them before adding them to your site.

And finally, keep your team sharp. Train designers, developers, and content creators regularly so accessibility remains second nature. Maintain a log of issues you’ve found and fixed—this not only helps with continuity but also shows your ongoing commitment if anyone ever challenges your efforts.

Accessibility: Not a Project, a Practice

California businesses operate in one of the most demanding accessibility environments in the country. By treating accessibility as part of your ongoing website maintenance, you protect yourself from lawsuits, reduce customer frustration, and build trust with every visitor.

The important part isn’t achieving perfection immediately—it’s showing steady progress and a willingness to keep improving.

Need Help Making Sense of It All?

If you’re unsure where to begin—or how to scale this web accessibility checklist across your team—216digital can help. We specialize in accessibility audits, practical remediation planning, and ongoing support for businesses serving California consumers.

Schedule a free ADA briefing today and gain clarity on what compliance means for your website in California. Together, we’ll prioritize the fixes that reduce your risk and deliver a better digital experience for everyone.
Greg McNeil

August 22, 2025

Legal Compliance

Accessibility, California Consumer Privacy Act, California Web Accessibility Laws, Legal compliance, WCAG, Web Accessibility, Website Accessibility

What Automated Platforms Do Well

The Role of Accessibility Consultants

Why Consultant-Led Remediation Should Come First

When Automated Platforms Make Sense

How to Decide What’s Right for You

The Long-Term Payoff

Human First, Automation Second

The Rule Behind Buttons vs Links

Why This Tiny Decision Matters More Than It Looks

When It Should Be a Button

When It Should Be a Link

Styling Without Lying: Buttons vs Links in Disguise

Testing the Decision: Buttons vs Links Under Real Inputs

Real-World Fixes That Come Up in Code Reviews

A Short Checklist (Pin It Next to Your Linter)

Wrapping It Up

Understanding the Scope of ADA Title II Compliance

The New Baseline: WCAG 2.1 Level AA

Key Deadlines and Limited Exceptions

Why This Deadline Signals a Shift

A Phased Roadmap Toward ADA Title II Compliance

Phase 1: Assess and Organize (Now through Mid-2025)

Phase 2: Plan and Prioritize (Mid-2025 through End-2025)

Phase 3: Remediate and Test (Early 2026)

Phase 4: Embed in Procurement and Governance (Ongoing)

Phase 5 : Maintain Accessibility Long-Term (Post-Deadline)

Common Pitfalls That Derail Progress

Beyond April 2026: Sustaining ADA Title II Compliance

Getting Started Now

Turning Deadlines Into Opportunity

What Is a VPAT?

A Typical VPAT Includes

What Is an ACR?

How Testing Builds Trust

Comparing VPAT vs. ACR: Core Differences

Best Practices for Creating VPATs and ACRs

Procurement-ready Checklist

Conclusion: Building Confidence Through Transparency

What Is an Accessibility Audit?

What Is a VPAT?

Accessibility Audit vs VPAT: Key Differences

When to Have an Accessibility Audit

When to Have a VPAT Prepared

Do You Need Both?

How They Reduce Risk Together

Practical Scenarios

Final Thoughts

When School Technology Leaves Learners Behind

What Digital Accessibility Looks Like in a School Context

The Power of Accessibility Audits for Schools

VPATs and ACRs: What Procurement Really Needs

Why Audits and VPATs Are Stronger Together (in Education)

Build Digital Accessibility Into the School Year (Without Adding Endless Meetings)

1) Start With High-impact Fixes

2) Equip Every Role.

3) Bake Testing Into Releases

4) Treat PDFs and Slides as Instructions, Not Attachments

5) Monitor and Iterate

Why This Matters for Teaching and Learning

A Long-Term Strategy for Inclusive Schools

Understanding Success Criterion 3.2.1 – On Focus

Why On Focus Matters

Common Pitfalls (and Why They Break On Focus)

How to Achieve Compliance (and Design a Better Experience)

Testing Strategies for On Focus

Manual testing

Assistive Technology Testing

Automated Checks

Bad vs. Good: Concrete Examples

Bad: Form Submits on Focus

Good: Form Submits Only on Activation

Bad: Navigation on Focus

Good: Navigation Only on Activation

Good Example: Custom Control with Predictable Focus

Frequently Asked Questions

Build Predictable Experiences (and Trust)

Why Your Organization Needs a Policy

Core Elements of a Strong Web Accessibility Policy

Purpose and Commitment

Scope