Website Accessibility Archives /Tag

Why ARIA Alone Won’t Fix Your Website’s Accessibility
ARIA (Accessible Rich Internet Applications) has become a mainstay in modern front-end work, giving us a way to make complex interfaces more usable for people relying on assistive tech. But here’s the catch: despite how widely it’s used now, accessibility issues on the web haven’t actually gone down. In fact, reports like the annual WebAIM Million consistently show that pages using ARIA often rack up more accessibility errors than those that don’t. That’s a red flag—and it raises an important question: if ARIA is meant to improve accessibility, why does more ARIA so often lead to worse outcomes?

What ARIA Is—and What It’s Supposed to Do

At its core, ARIA is just a spec for adding semantic meaning where HTML alone doesn’t cut it. When we build custom UI components—think tab lists, modals, or live regions—ARIA roles and attributes tell screen readers what those elements are, how they behave, and when their state changes.

For example, aria-live lets us announce new content to screen readers without forcing a page reload. aria-label gives an accessible name to elements that don’t have visible text. Using role="tablist" clarifies the relationship between grouped tab controls. When used correctly, these attributes bridge the gap between how something looks visually and how it’s experienced non-visually.

When Is It Necessary?

There are valid cases where ARIA is the right tool—like custom widgets that don’t exist in native HTML, dynamic content that needs to be announced, or modal dialogs that require managing focus. In these edge cases, it can give essential context to assistive tech users. The trick is restraint: only reach for ARIA when HTML alone can’t deliver the behavior you need.

Why It Shouldn’t Be the Default Tool

The W3C’s first rule of ARIA is dead simple: “Don’t use ARIA if you can use native HTML.” There’s a reason for that. Semantic elements like <button>, <nav>, and <input> come with baked-in keyboard support, focus behavior, and screen reader semantics.

Replacing these with <div>s or <span>s and trying to patch on ARIA roles is a recipe for trouble. It adds complexity we have to maintain, and it increases the cognitive load on assistive tech users, who now have to deal with custom keyboard logic or missing states that native elements would have handled out of the box.

Common ARIA Misuse That Breaks Accessibility

Misusing ARIA is the fastest way to make things worse. Some of the most common mistakes we see:
- Redundant ARIA: e.g. adding role="button" on a native <button>, which can confuse announcements.
- Incorrect roles or attributes: like using aria-checked on something that’s not checkable.
- Static ARIA states: setting aria-expanded="true" and never updating it when the element collapses.
- Overriding native behavior : trapping focus or breaking expected tab order.
- Misused aria-hidden: This one’s especially nasty. It hides content from assistive tech, which is fine for decorative icons or offscreen helper text. But if you throw it on meaningful content like links or form controls, it removes them from the accessibility tree entirely. That creates “empty” focusable elements and violates the rule that aria-hidden="true" must never be on focusable items.
Take a link that only has an SVG icon with aria-hidden="true". Visually it looks fine, but to a screen reader, it’s just an empty link with no name. Compare that to a native <button> with either visible text or an aria-label—it automatically conveys its purpose. Misusing it like this doesn’t just fail to help; it strips meaning away.

Why ARIA Usage Correlates with More Errors

The WebAIM Million keeps showing the same trend: pages with ARIA average almost twice as many detectable errors as those without. That doesn’t mean ARIA is inherently bad—it means it’s often used wrong.

Here’s why that happens so often:
- More moving parts: Every ARIA attribute is another thing that has to stay in sync as the UI changes.
- Misunderstood implementation: Developers sometimes add it without fully understanding how screen readers will interpret it. For instance, putting aria-hidden on a logo or nav link effectively removes it from the experience for assistive tech users.
- No real testing: There’s a tendency to assume that if ARIA is present, accessibility is solved. Without testing, it’s easy to miss that it’s actually broken.
The Real Fix: Manual Testing and Developer Discipline

Automated tools are useful for catching low-hanging fruit like missing alt text, color contrast issues, or syntax errors. But they can’t tell you if your ARIA actually works. They’ll detect if aria-expanded is present—but not if it updates correctly when toggled.

Same thing with aria-hidden: they’ll warn you that it’s there, but not if you used it correctly. Maybe the hidden element is decorative (fine) or maybe it’s essential (not fine). Only a human can tell. Most ARIA issues are about behavior and context, which tools can’t judge.

Testing It in the Real World

To know your ARIA implementation works, you’ve got to test it like real users would:
- Keyboard-only navigation: Make sure everything interactive is reachable by tab, focus order makes sense, and keys like Enter, Space, and Arrow keys behave as expected.
- Screen reader testing: Try NVDA on Windows, VoiceOver on macOS, or JAWS if you’re in enterprise. Confirm that roles, labels, and states are being announced correctly—and that hidden content stays hidden without killing important info.
- User testing: If possible, bring in assistive tech users or trained accessibility testers to see how your UI holds up in practice.
Doing this builds confidence that your ARIA-enhanced components are actually usable.

Build a Feedback Loop Into the Dev Process

Accessibility shouldn’t be a post-launch patch job. Bake it into your development flow. Do accessibility checks during code reviews, QA, and design iterations. When you add ARIA, document the behavior you expect, and get feedback from teammates or AT users to verify it works.

Practical Guidelines for Responsible ARIA Use

If you want to use it safely, stick to a few core habits:
- Follow the WAI-ARIA Authoring Practices (APG): They provide vetted patterns and working code examples.
- Use ARIA only when you have to: Lean on semantic HTML first, and treat it as a fallback.
- Test thoroughly: Validate behavior with keyboard and screen readers, not just automated checkers.
- Review aria-hidden usage carefully: Only hide decorative or duplicate content. Never hide focusable items, form controls, or nav links.
- Document your decisions: Leave comments or README notes explaining why it was added and how it’s supposed to work.
- Make accessibility a team effort: It’s not just the job of one dev or QA engineer. Everyone owns it.
ARIA Isn’t a Shortcut—It’s a Responsibility

ARIA is powerful, but it’s not magic. Used carelessly, it creates new barriers and frustrates the very people it’s meant to support. Used deliberately—with a “native first” mindset, real testing, and team buy-in—it can make complex interfaces accessible without breaking usability.

Respect ARIA’s complexity, but don’t fear it. Real accessibility comes from thoughtful use of semantic HTML, strategic ARIA when it’s actually needed, and consistent real-world testing.

If you want to level up your accessibility practices and cut risk, 216digital offers ADA briefings built specifically for dev teams. Schedule one today and start building better, more inclusive code.
Greg McNeil

September 12, 2025

How-to Guides, Legal Compliance

Accessibility, ARIA, keyboard accessibility, WCAG, web developers, web development, 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
Boost Summer Sales with E-Commerce Accessibility
Four days. Over $24 billion spent online. More than half of those purchases made on phones. That was July—not November—which shows just how much summer now acts like a peak shopping season. For eCommerce leaders, the takeaway is straightforward: every second of your mobile experience either builds revenue or lets it slip away.

Design and performance are important, but they don’t go far enough if parts of your site are still hard to use. E-commerce accessibility is what turns casual browsing into completed orders. Small improvements—better contrast on banners, alt text on product images, tap-friendly buttons, or checkout flows that support wallet payments—can make the difference between an abandoned cart and a sale. What follows is a clear plan to help you prepare for summer’s surge in a way that’s practical, manageable, and built to deliver results.

Why Summer’s Surge Matters

The way people shop has shifted. Purchases aren’t tied to desktops or long browsing sessions anymore—they happen in small windows throughout the day. Whether it’s scrolling on the train, tapping through a checkout line, or quickly buying something after dinner, mobile has become the primary storefront.

Industry data backs this up. Mobile commerce is expected to generate over $2.5 trillion in sales globally this year, accounting for more than 60 percent of all e-commerce. For businesses, that means mobile optimization isn’t optional. Without it, brands risk losing customers to competitors who offer a more seamless experience. And when mobile readiness is paired with e-commerce accessibility, the benefits go even further, ensuring that every shopper—not just most—can complete their purchase with ease.

Why e-commerce Accessibility Builds Trust and Loyalty

One in four adults in the U.S. lives with a disability, representing trillions in global spending power. Yet many e-commerce sites still have barriers: low-contrast text, missing alt text, or forms that don’t work with screen readers.

These aren’t small mistakes—they’re lost sales. Nearly 9 out of 10 shoppers won’t return after a poor experience. By contrast, removing accessibility barriers improves the journey for all customers:
- Clearer navigation benefits busy parents shopping on the go.
- Higher contrast helps people outdoors in bright sun.
- Streamlined forms cut friction across the board.
Accessibility isn’t just compliance—it’s customer experience.

A Checklist for Seasonal Optimization

You don’t need to overhaul your entire site to make it work better for summer shoppers. The biggest wins usually come from tightening up a few areas that directly affect how fast someone can find what they want and check out. Here’s where to focus:

Mobile Performance

Most summer shoppers are on their phones, sometimes with less-than-perfect service. Test your site on real devices, not just a desktop simulator. Keep images lean, make pages load in under three seconds, and check how it performs on a basic cellular connection. Those small speed gains often decide whether a cart gets completed.

Navigation That Works on Small Screens

Clear menus, a visible search bar, and buttons that are easy to tap matter more than you think. If someone has to pinch and zoom just to click, you’ll lose them. Adding digital wallets like Apple Pay or Google Pay also trims precious seconds off checkout.

e-commerce Accessibility Essentials

Take a fresh look at contrast, alt text, and forms. Can a product photo be understood without seeing it? Does your promo banner stand out when read aloud by a screen reader? Can someone tab through the entire checkout with a keyboard? These quick checks reveal where shoppers might be getting stuck.

Promotions People Can Actually Use

Discounts only drive revenue when customers can interact with them. Design banners that stay legible in bright light, code calls-to-action correctly, and build offers so customers can always redeem them.

Seasonal Discovery

Social platforms push more traffic than ever, and many customers will jump straight from TikTok or Instagram to checkout. Captions and clear descriptions help that content perform better while also making it accessible. On your site, think seasonally—customers searching “grill” or “beach” should land on relevant results.

Checkout Without Friction

Cart abandonment still costs retailers billions. Keep it short, show customers where they are in the process, and let them check out without creating an account. Adding trust signals—like secure payment icons—can make a big difference in whether they finish the purchase.

Real-time Feedback

Don’t wait until after a sale is over to see what went wrong. Track cart abandonment, page load times, and accessibility errors as they happen. That way, you can make fixes while the promotion is still live.

Seasonal Updates

Fresh visuals help keep the store feeling current, but clarity matters most. Summer-themed banners, bright colors, or back-to-school imagery should still meet accessibility standards so that promotions are visible to everyone.

From Sizzle to Sale: Why Accessibility Pays

You don’t need a massive redesign to be ready for summer. What you need is to clear away the small obstacles that quietly cost sales. Make promotions easy to see and interact with. Keep navigation simple, even on a phone. Let customers check out the way they already prefer. And make sure each step—search, product view, add-to-cart, and checkout—works smoothly for every shopper, including those using assistive technology. That’s how e-commerce accessibility drives real business results: more orders completed, fewer abandoned carts, and happier customers who come back.
Think of it as preparing for today and investing in tomorrow. The improvements you make now to support summer sales will keep paying off during back-to-school, holiday, and every seasonal promotion that follows. If you’d like a clear picture of where your site is strong and where quick wins are waiting, 216digital offers ADA briefings designed to be straightforward and actionable.
Greg McNeil

August 18, 2025

The Benefits of Web Accessibility

2025, Accessibility, Benefits of Web Accessibility, Website Accessibility
How to Meet California Web Accessibility Laws in 2025
If your website serves Californians, you’re stepping into one of the most lawsuit-heavy digital environments in the country. California leads the nation in web accessibility lawsuits—and the pace isn’t slowing in 2025.

That reality can feel overwhelming. The headlines make it seem like one slip could land you in court. The rules aren’t always easy to interpret, and the stakes feel high. But here’s the thing: you’re not powerless. With the right understanding and a proactive plan, you can protect your business, meet California’s requirements, and even turn accessibility into an advantage.

This guide will break down California’s web accessibility laws, recent legal updates, and practical steps you can take right now to stay ahead. Let’s walk the landscape—and give you a clear path forward.

Web Accessibility in California Isn’t Optional Anymore

California, New York, and Florida consistently account for the majority of ADA-related website lawsuits nationwide. What makes California different is the mix: federal law, state law, and a culture of active enforcement all rolled together.

And here’s the kicker: you don’t need a physical storefront in California to be pulled into this mix. If you sell online to Californians, your website is within reach of these laws.

Bottom line: if your digital presence isn’t accessible, you’re at risk. Fixing it early is always easier—and far less expensive—than scrambling after a lawsuit.

Why California’s Web Accessibility Laws Are Tougher

California has always been out in front on consumer protections and civil rights, and that leadership shows up online. Courts and lawmakers here push harder for accessibility and hold organizations accountable when they fall short.

The result? Higher expectations, more lawsuits, and often bigger settlements compared to other states. Planning for accessibility in California isn’t just good practice—it’s basic risk management.

Multiple Legal Layers to Consider

California’s legal framework is layered and powerful. Here’s how the pieces fit:

Federal Law: Americans with Disabilities Act (ADA)

The ADA doesn’t name websites directly, but courts—including those in California—have repeatedly ruled that business websites and mobile apps count as “public accommodations” under Title III. Translation: if you sell or serve online, your site must be accessible.

State Law: Unruh Civil Rights Act

The Unruh Act takes the ADA and makes it California law—with teeth. Plaintiffs can seek damages of at least $4,000 per violation, plus attorney’s fees. Add in emotional-distress claims, and those numbers climb fast. This law is one of the most common tools used in web accessibility lawsuits, and it applies to out-of-state businesses, too.

State Government Codes

California has written accessibility directly into law for public agencies. Three key sections work together:
- 11545.7 : Requires state agencies to post a compliance certificate on their websites every two years, confirming alignment with WCAG 2.0 AA.
- 7405 : Reinforces Section 508 of the Rehabilitation Act, requiring agencies to keep electronic and information technology accessible.
- 11135 : Extends protections to all state-funded or state-run programs, prohibiting discrimination in digital systems.
Public Sector Rule: AB 434

Since 2019, agencies must meet WCAG 2.0 AA and post a signed compliance certificate on their homepages. While this applies to government entities, it signals where the state is headed: higher standards and stronger accountability.

Taken together, these laws make California one of the most proactive states when it comes to digital inclusion—and a place where compliance isn’t optional, it’s enforceable.

What’s New (and What’s Coming) in 2025

California’s accessibility environment doesn’t sit still. Here’s what to keep your eye on this year:

CCPA and CPRA Accessibility Requirements

California’s data privacy laws now go hand in hand with accessibility. Under the California Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA), privacy notices, consent forms, and opt-out mechanisms must all be accessible. If you’re collecting data from Californians, accessibility is officially part of your privacy compliance checklist.

AB 1757: A Bill with Big Implications

Introduced in 2024, AB 1757 could become law in 2025. If passed, it would:
- Require WCAG 2.1 AA compliance for all websites and apps offering goods or services in California.
- Create a private right of action, letting individuals sue directly without waiting for state enforcement.
- Extend liability to third-party developers and vendors, not just the businesses they build for.
If this bill becomes law, lawsuits will expand—and fast. Preparing now is far less costly than reacting later.

How Courts Are Using WCAG

Even though WCAG isn’t named in every law, California courts lean on WCAG 2.1 AA when ruling on cases. Decisions like Robles v. Domino’s Pizza and Thurston v. Midvale Corp. make it clear: businesses are expected to meet these standards.

In short: WCAG 2.1 AA is your strongest legal defense and your most practical roadmap.

What WCAG 2.1 AA Covers

The guidelines are built around four principles:
- Perceivable: Content can be seen or heard (e.g., alt text, video captions).
- Operable: Users can navigate (e.g., keyboard-friendly, logical tab order).
- Understandable: Information and navigation are predictable (e.g., consistent menus, clear error handling).
- Robust : Works across today’s and tomorrow’s assistive technologies.
Think labeled forms, color contrast that passes, error messages that actually help, and no features that rely on hover alone. That’s where legal risk starts to drop.

What Businesses Should Do Now

Here’s how to get started without stalling:

Start with a Self-Audit

You don’t need a full professional audit to take the first step. Try this:
- Run free tools like WAVE or Google Lighthouse.
- Test with a screen reader (NVDA, VoiceOver on Mac).
- Use a color contrast checker.
These quick wins surface obvious barriers and get your team thinking about accessibility in action.

Focus on WCAG 2.1 AA

This is the benchmark California courts already use—and AB 1757 may make it law.
- Review templates, navigation, and interactive elements.
- Test checkout flows and account portals from start to finish.
- Check both desktop and mobile.
Proactive compliance costs less than defending a lawsuit. It also puts you ahead when regulations tighten.

Think Beyond Compliance

Yes, accessibility reduces risk. But it also grows your audience. More than 61 million Americans live with a disability. Making your site inclusive builds loyalty, improves SEO, and strengthens your brand. Following California’s web accessibility laws isn’t just about defense—it’s about long-term growth.

Don’t Wait for the Lawsuit

California’s web accessibility laws are tightening, and enforcement is active. Waiting for a complaint is a gamble—and an expensive one.

Act now. Align with WCAG 2.1 AA. Bake accessibility into your website strategy. You’ll reduce legal risk, expand your reach, and strengthen your reputation.

At 216digital, we help businesses tackle accessibility with practical solutions that reduce legal exposure and build better customer experiences.

Our ADA Briefing is a no-pressure way to:
- Understand how California’s laws apply to your site.
- Identify your biggest areas of risk.
- Walk away with a clear, actionable plan.
Don’t wait for a lawsuit to force your hand. Protect your business now—and build a digital experience that truly includes everyone.

Schedule your ADA Briefing with 216digital
Greg McNeil

August 15, 2025

Legal Compliance

Accessibility, accessibility laws, California Web Accessibility Laws, state accessibility laws, Web Accessibility, Website Accessibility

What ARIA Is—and What It’s Supposed to Do

When Is It Necessary?

Why It Shouldn’t Be the Default Tool

Common ARIA Misuse That Breaks Accessibility

Why ARIA Usage Correlates with More Errors

The Real Fix: Manual Testing and Developer Discipline

Testing It in the Real World

Build a Feedback Loop Into the Dev Process

Practical Guidelines for Responsible ARIA Use

ARIA Isn’t a Shortcut—It’s a Responsibility

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

Standards and Guidelines

Accountability

Testing and Monitoring

Training and Culture

Feedback and Grievance Process

Review and Updates

Internal Policy vs. Public Accessibility Statement

Common Pitfalls

Moving from Policy to Practice

Drafted. Signed. Now, Let’s Do This.

What An Accessible PDF is—And Why the Law Cares

PDF/UA (ISO 14289): Technical Conformance

WCAG for PDFs: Publication Context and User Outcomes

How They Fit Together

Operational Definition of “Compliant”

Why PDFs Are So Often Non-compliant

What AI-powered Accessibility Tools Do Well (Today)

Where AI Still Falls Short—and Why People Still Matter

The Hybrid model for Accessible PDF Compliance

AI is Powerful, But Not a Solo Act