Web Accessibility Archives /Tag

Document Accessibility: Read Between the Lines
Forms, reports, policies—documents are at the heart of how organizations communicate. They guide collaboration within teams, shape the way businesses present information to clients, and carry essential services from government agencies to the people who rely on them. Yet in conversations about accessibility, documents are often left behind while websites and apps take center stage.

Here’s the truth: more than 1.3 billion people worldwide live with disabilities. When documents aren’t accessible, they don’t just frustrate users—they block access to opportunities, services, and information. And those barriers come with consequences: compliance risks, wasted resources, and lasting damage to trust.

This article explores why document accessibility matters, the risks of ignoring it, and the practical steps any organization can take to make inclusivity part of every page.

Why Documents Get Left Behind

When accessibility comes up, the spotlight usually lands on websites and apps. Documents, by comparison, are treated like static files—uploaded once and quickly forgotten. But unlike a web page that can be redesigned or corrected on the fly, a document can sit in a folder for years, carrying the same barriers forward each time it’s shared.

That’s where the challenge really begins. Over time, organizations accumulate thousands of forms, reports, and guides. Without document accessibility built in, every one of those files can become a roadblock for someone simply trying to get information. And here’s the irony: even if your website is fully compliant, a single inaccessible PDF can undo that progress in one click.

Think about the typical customer or employee journey. They may interact with your website first, but sooner or later, they’ll be asked to download a policy, fill out a form, or read a report. If that moment becomes a dead end because the file wasn’t created with accessibility in mind, the experience fractures. What could have been a seamless process becomes a frustrating—and sometimes exclusionary—obstacle.

It’s not a minor detail. It’s a gap that matters.

The Ripple Effect of Inaccessible Documents

Ignoring accessibility doesn’t just inconvenience a few people—it ripples outward, affecting user experience, compliance, operations, and public trust.

Excluding People Who Rely on Assistive Technology

Picture navigating a long policy document with no headings, a jumbled reading order, or unlabeled tables. For someone using a screen reader, that isn’t just confusing—it’s exclusion. Instead of being empowered with information, the user is essentially told: this wasn’t made with you in mind. Document accessibility flips that experience, replacing confusion with clarity and restoring equal access.

For many people, this isn’t a matter of preference; it’s a matter of participation. A job seeker filling out an application, a student applying for financial aid, or a patient reviewing a health policy—each of these moments hinges on clear, usable documents. When accessibility is missing, doors close. When it’s present, those same doors open wide.

Legal and Compliance Risks

Accessibility laws don’t stop at websites. In the U.S., Section 508 requires federal agencies and contractors to make documents accessible. Courts increasingly reference WCAG in ADA-related cases, and states like California and Colorado explicitly include documents in their accessibility standards.

This means organizations that overlook document accessibility aren’t just leaving users behind—they’re exposing themselves to avoidable legal and financial risks. Settlements, remediation costs, and reputational fallout can far outweigh the effort it would have taken to build accessibility in from the beginning.

Strains on Operations and Budgets

Waiting to retrofit inaccessible files is like ignoring a small leak until the basement floods. By the time the problem surfaces, you’re dealing with archives of PDFs, Word files, and PowerPoints that all need fixing. That kind of scramble drains resources at the exact moment teams need them most.

By contrast, building accessibility into workflows from the start keeps projects moving smoothly and reduces long-term costs. It’s the difference between consistently maintaining a car and waiting for the engine to fail—one approach keeps you moving, the other leaves you stranded.

Damage to Trust and Reputation

Accessibility is also about values. Every time someone encounters an inaccessible document, it can feel like a closed door. On the flip side, organizations that consistently publish accessible files send a very different message: we thought of you, and you matter here.

That kind of trust sticks. Customers who feel included are more likely to stay loyal. Employees who see their organization invest in accessibility feel valued and supported. Communities notice when organizations lead with inclusion rather than scramble after being called out.

Habits That Make Documents Accessible

The encouraging part is that accessibility doesn’t hinge on massive overhauls. It comes down to steady, thoughtful habits that make communication easier for everyone.
- Start with what matters most. Prioritize high-impact files like benefits forms, contracts, or applications—where barriers are most costly.
- Keep it clear and legible. Use readable fonts at accessible sizes, and ensure strong color contrast. Don’t make users squint or guess.
- Guide readers with structure. Headings, bullet points, and logical reading order transform a wall of text into something navigable.
- Write links with meaning. Swap vague text like “click here” for specifics such as “Download the 2024 Annual Report.”
- Label charts and tables. A short title or alt text can make data accessible where it otherwise would be invisible.
- Double-check reading order. Confirm assistive technologies present content in the intended sequence.
- Use plain, approachable language. Accessibility and clarity overlap—what’s easier for one person usually helps everyone.
- Think accessibility early. Bake it into templates and workflows. What’s built right the first time doesn’t have to be rebuilt later.
- Build team confidence. Training, resources, and occasional outside expertise embed document accessibility into culture, not just checklists.
When these habits become routine, accessibility stops feeling like an “extra step.” It becomes part of what good communication looks like.

Building a Culture That Lasts

Accessibility isn’t a one-off project—it’s a mindset. Organizations that delay or treat it as optional often find themselves scrambling later, stuck between urgent deadlines and legal requirements.

Those that weave document accessibility into everyday work create a foundation for resilience and growth. They also discover a simple truth: when documents are accessible, they serve everyone better. Employees waste less time fixing broken files. Customers encounter fewer frustrations. Leaders gain the peace of mind that comes from knowing their communications reflect both compliance and care.

At its core, this work is about people. Every accessible document removes one more barrier. Each one tells the reader: we see you, we planned for you, and you belong here. That’s more than compliance. That’s care in action.

From Awareness to Action

Accessible documents reduce inefficiency, protect against legal risks, and strengthen reputations. But beyond the practical, they serve a human purpose: making sure vital information—job applications, financial aid forms, health policies—is available to everyone.

Document accessibility isn’t an afterthought. It’s the foundation of fair, effective communication.

If your organization is ready to turn awareness into action, schedule an ADA briefing with 216digital. We’ll help you build a strategy that makes accessibility part of your culture—so every file reflects not just compliance, but genuine inclusion.
Greg McNeil

September 24, 2025

The Benefits of Web Accessibility

Accessibility, accessible documents, accessible PDF, PDF, Web Accessibility, Website Accessibility
Why 2025 Is All Talking Inclusive Brand Design

Selena Gomez’s Rare Beauty fragrance bottle did more than launch a scent—it made a statement. Co-created with a hand therapist, the rounded bottle sits comfortably in the hand, and its spray requires little effort to use. It’s beautiful, it’s practical, and it’s proof that accessibility doesn’t weaken design—it strengthens it, setting a new standard for what good design looks like.

That’s the essence of inclusive brand design. When thoughtfulness meets elegance, accessibility doesn’t water down your brand—it elevates it. And in 2025, customers expect that same level of intention in every part of the experience, including digital spaces.

The Business Case for Inclusive Brand Design

Rare Beauty shows how inclusive brand design that removes barriers builds loyalty—not just among people with disabilities but among their families, friends, and communities. Today’s consumer base—especially Millennials and Gen Z—cares about values as much as products. They expect brands to reflect social responsibility in ways that are tangible.

When accessibility becomes part of your brand’s DNA, you send a clear message: you belong here. That emotional connection pays off in loyalty, repeat business, and word-of-mouth advocacy.

The Market Opportunity

And that loyalty doesn’t exist in a vacuum—it ties directly to spending power. Globally, more than 1.3 billion people live with a disability. When you factor in families and support networks, the purchasing power of this community reaches $13 trillion annually. This is not a niche—it’s one of the most influential markets in the world.

Rare Beauty’s own growth underscores the opportunity. By 2023, it had generated $350 million in sales, fueled in part by its reputation for accessibility and inclusivity. Inclusive brand design isn’t a side initiative anymore—it’s a driver of brand strength.

The Digital Disconnect in Inclusive Brand Design

But here’s where many brands stumble. They may create a product that’s thoughtful and inclusive, but their digital storefront doesn’t measure up. Maybe the packaging is easy to open, but the checkout can’t be navigated with a screen reader. Perhaps the store welcomes everyone, but the app’s colors make it unusable for many. These gaps aren’t just inconvenient—they’re exclusionary.

The Reality in Numbers

And customers feel these gaps every day—the numbers confirm it. WebAIM’s research across one million homepages found nearly 51 million accessibility errors—an average of 51 per site. More than 94% of homepages had at least one WCAG violation. Meanwhile, nine out of ten users say they’ve personally encountered accessibility barriers while browsing. And the impact is immediate: 70% of disabled shoppers abandon websites that are too difficult to use.

The Unfinished Promise

Behind those numbers are people who want to engage with a brand and can’t. That’s what makes digital inaccessibility more than a technical issue—it’s an unfinished promise. A brand may succeed in making products inclusive, but if its digital presence doesn’t reflect that same care, customers notice. It’s not just a broken experience—it costs brands sales, trust, and reputation.

The Benefits of Embracing Digital Accessibility

The good news is, every barrier you remove creates an opportunity. Where inaccessible design closes doors, inclusive brand design opens them—to new customers, stronger relationships, and measurable business gains.

Reach More Customers, Build More Trust

When brands invest in accessibility, they close that gap. They prove their values go deeper than marketing copy, and customers reward that consistency with loyalty and advocacy. Accessibility, in practice, becomes one of the clearest signals of integrity.

Boost Search Visibility

And the benefits don’t stop with customers. Accessibility improvements often strengthen a site’s technical foundation, which search engines reward. Clear structures, descriptive alt text, and intuitive navigation make it easier for Google to crawl and index content. A study by Semrush and Accessibility Checker found that 73% of sites improving accessibility saw organic traffic increase, averaging 12% growth.

Better Experiences for Everyone

Accessibility also lifts usability across the board. Captions help both deaf viewers and commuters watching in noisy environments. Strong color contrast helps those with low vision and anyone outdoors in bright light. Larger tap targets assist users with motor limitations and people juggling a phone in one hand. When accessibility is built in, everyone benefits.

Efficiency and ROI Gains

And inside the business, accessibility creates efficiency. Cleaner, structured code reduces development rework. Streamlined flows cut down on support tickets. Easier checkouts lift conversion rates. The ROI is striking: Forrester estimates that every $1 invested in accessibility can return up to $100 in benefits. It’s proof that accessibility doesn’t just pay off in trust—it pays off in operations too.

Five Building Blocks for Inclusive Brand Design Online

Recognizing the benefits of accessibility is just the beginning. The real progress comes from knowing how to put those values into practice. Accessibility doesn’t just appear—it’s the result of clear priorities and consistent habits.

These five building blocks give you a practical, everyday path forward:

1. Start with the Standards

Start with WCAG 2.1/2.2 Level AA. These guidelines are practical blueprints for creating experiences that are perceivable, operable, understandable, and robust.

2. Audit, Prioritize, and Iterate

Run an accessibility audit to map where you stand. Fix the highest-impact issues first—navigation, forms, alt text, and color contrast. Take it step by step; progress compounds quickly.

3. Design and Develop for Accessibility

Accessibility isn’t something you tack on at the end—it’s built in. Use semantic HTML. Structure headings clearly. Write meaningful alt text. Provide captions and transcripts. Ensure your site works fully by keyboard and with screen readers.

4. Blend Automation with Human Testing

Automated tools catch a lot, but only about 30% of real-world barriers. Human testing, especially with assistive technology users, surfaces the rest. Together, they give you both coverage and authenticity.

5. Create a Culture, Not a Checklist

Most importantly, make accessibility part of the way your brand works, not just a task on the to-do list. Train teams across design, development, and content. Build accessible components into your design systems. Encourage accountability so accessibility becomes second nature, woven into your culture.

A Chance to Lead With Inclusion

Every interaction online tells people something about your brand. When your digital spaces aren’t accessible, that message can be louder than you think—even if it wasn’t your intent. Customers notice when barriers are in the way, and they remember which brands make it simple to connect.

Accessibility isn’t just a box to check anymore—it’s what separates brands that feel relevant from those that feel outdated. With 88% of websites still missing the mark on compliance, the chance to stand out is wide open. Choosing accessibility is more than compliance; it’s a clear sign that your values extend from the products you offer to the way people experience your brand online.

At 216digital, we help make accessibility part of your everyday design process, not something tacked on at the end. If you’re ready to create an inclusive and dependable online presence, schedule an ADA briefing with us today. Let’s make sure your online spaces reflect the same care and integrity as the products you’re proud to share with the world.

Greg McNeil

September 23, 2025

The Benefits of Web Accessibility

Accessibility, Accessible Design, Benefits of Web Accessibility, Inclusive design, Web Accessibility, Web Accessible Design, Website Accessibility
Say More with Accessible Web Content
We spend a lot of time tuning headlines and chasing algorithms. But the work that truly moves the needle is simpler: say what you mean so more people can use it. Clear content builds trust, lowers support requests, and makes your message easier to find. That’s the power of accessible web content—it helps people first, and performance follows.

Content isn’t a “design extra” in accessibility. Writers, editors, marketers, and developers shape how people understand a page. This article offers practical, jargon-light techniques you can apply right now. They align with WCAG, but they’re written for real teams on real deadlines, with real audiences who just want answers that make sense.

Plain Language Is the Heart of Accessible Web Content

Plain language is not “dumbing it down.” It’s respect. Many public-facing teams aim for an elementary reading level; professional material often targets a middle-school level. And when you’re busy, simple always wins—whether you’re a novice or an expert scanning on a phone between meetings.

Try this:
- Use a readability tool (Hemingway, Grammarly) to check grade level.
- Swap jargon for everyday words. “The site adjusts to your screen” beats “utilizes responsive design principles.”
- Prefer active voice: “Change your password every three months,” not “It is recommended…”
- Lead with the point, then add detail.
- Keep one idea per paragraph. Use person-first, inclusive language when you reference people with disabilities.
Short sentences steady the pace. A few longer ones add rhythm and nuance. Together, they make meaning land without strain.

Make Your Page Easy to Scan—By People and Tools

Titles, URLs, and headings are how busy readers—and assistive tech—map a page. If the map is messy, the journey is slow.

Best practices:
- Write unique, descriptive titles. Put the most important words first and, when it fits, match the H1.
- Use readable URLs (/web-design-services, not ?id=47289).
- Use one H1. Nest headings in order (H2 → H3) like chapters and subchapters.
Screen reader users often navigate by headings. A logical outline turns scanning into understanding. Clear structure makes pages easier to skim, and it makes accessible web content faster to find, reuse, and maintain.

Links and Images That Strengthen Accessible Web Content

“Click here” makes people guess. It also fails when a screen reader pulls out a list of links with no surrounding context.

Instead:
- Write link text that stands on its own: “Download the accessibility guide.”
- Make labels unique so users know which link goes where.
Effective Alt Text

Alt text explains an image’s purpose when images don’t load or when a user can’t see them.

Guidelines:
- Be concise—under ~125 characters—and capture what the image means to the page.
- Decorative images should be skipped with empty alt text (alt="").
- For complex visuals (charts, infographics), add a short alt summary and provide a fuller explanation nearby.
These small choices help everyone—search engines, skimmers, and people using assistive tech—get the same story.

Accessible Audio and Video for Every Situation

Not everyone can turn on sound. Some people prefer reading. Others are in a noisy shop or a quiet office. Without captions or transcripts, they miss your message.

Do this:
- Provide accurate, synchronized captions. Add speaker labels when voices change.
- Offer transcripts with timestamps and descriptions of meaningful sounds or visuals.
- Edit auto-generated captions. They’re a starting point, not a finish line.
Captions and transcripts travel well across devices and contexts, turning media into content that’s flexible, shareable, and dependable—another pillar of accessible web content.

Guidance That Doesn’t Assume Vision or Memory

Task-heavy pages—forms, checkouts, dashboards—depend on clear instructions. Plain direction removes guesswork and stress.

Practical moves:
- Use direct, concrete prompts: “Enter your full name and email address.”
- State rules up front: “Password must be at least 8 characters.”
- Write helpful errors that explain what went wrong and how to fix it: “Enter a valid email, like name@example.com.”
- Don’t rely on color, location, or shape alone. If you say “the green button on the right,” also name the button.
The goal is guidance that stands on its own—no color key, no guessing, no hidden requirements.

Formatting That Keeps Accessible Web Content Readable

Good layout choices help everyone. They also keep cognitive load low.

Recommendations:
- Left-align text. Full justification can create rivers of space that are harder to read.
- Choose legible sans-serif fonts at a comfortable size (around 16px / 12pt or larger).
- Give text room to breathe with generous line spacing and white space.
- Keep paragraphs short (3–4 sentences). Use lists for steps and grouped ideas.
- Verify pages remain readable and usable when zoomed to 200%.
- Ensure sufficient color contrast (aim for at least 4.5:1 for normal text). Don’t rely on color alone for meaning.
These choices signal care. They tell readers, “We made room for you here.”

Why These Techniques Matter

WCAG 2.2 (W3C’s current recommendation) gives teams a shared yardstick. The POUR framework—Perceivable, Operable, Understandable, Robust—turns good writing habits and clean structure into checks you can actually verify. Here’s how that plays out in day-to-day work:
- Perceivable: Make meaning available beyond sight alone. 1.1.1 Non-text Content asks for useful alt text; 1.4.3 Contrast (Minimum) expects readable color contrast. Together they ensure images and text still communicate when visuals fail or vision varies.
- Operable: People must be able to find and use things. 2.4.6 Headings and Labels rewards clear, descriptive headings; keyboard-friendly navigation pushes toward predictable movement through a page.
- Understandable: Content should read cleanly and behave as expected. 3.3.1 Error Identification favors messages that say what went wrong and how to fix it—perfect for forms and flows.
- Robust: Code should work with current and future tech. 4.1.2 Name, Role, Value is where semantic HTML shines, helping assistive technologies reliably understand controls and their states.
You don’t need to memorize the spec. Use POUR as a short, practical lens while you write and review: if a decision helps someone perceive, operate, understand, or reliably use the page, you’re moving in the right direction—and you’ll have the checkpoints to prove it. It’s not meant to slow you down; it’s there to turn good intentions into repeatable habits that make accessible web content easier to ship.

Ensure Your Words Work—Not Just Look Right

Use tools to catch patterns. Use people to confirm meaning.

Helpful tools:
- Accessibility checkers (like WAVE or Google Lighthouse) surface common issues early.
- Readability and contrast tools help you tune language and color choices.
Manual checks:
- Try a screen reader (NVDA on Windows, VoiceOver on macOS).
- Navigate with a keyboard only. Can you reach and use every control?
- When possible, invite feedback from people with diverse abilities.
Make it repeatable:
- Keep a short pre-publish checklist: heading order, meaningful links, alt text added, language attribute set, clear form labels and errors.
- Schedule content accessibility reviews so improvements stick. This is how you keep accessible web content strong as pages, teams, and priorities change.
Accessible Content Is Good Content—Let’s Get You There

You don’t have to fix everything at once—just make the next thing better. A clearer title here, a stronger alt text there, a caption polished before it goes live. Small improvements stack up fast, and your audience feels the difference.

As you roll out a new product, kick off a seasonal sale, or hit publish on a blog, take a gentle pause: Does the page read easily? Do the links explain themselves? Will someone using a screen reader get the same story as everyone else? That quiet check-in becomes a habit, and that habit becomes consistency—without slowing your team down. Over time, those small, steady choices turn into a recognizable voice: thoughtful, trustworthy, and human.

If you’d like a partner to help keep that momentum, 216digital is here. We can share simple checklists, coach your team, and set up light-touch reviews so every release ships with confidence. Schedule an ADA briefing with us, and let’s make the next launch your clearest one yet—then repeat it with every product, sale, and post.
Greg McNeil

September 19, 2025

How-to Guides

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

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

What Automated Platforms Do Well

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

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

The Role of Accessibility Consultants

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

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

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

Why Consultant-Led Remediation Should Come First

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

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

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

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

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

When Automated Platforms Make Sense

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

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

How to Decide What’s Right for You

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

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

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

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

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

The Long-Term Payoff

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

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

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

Human First, Automation Second

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

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

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

September 17, 2025

Testing & Remediation

Accessibility, Accessibility Remediation, Accessibility testing, automated scans, automated testing, consultants, Web Accessibility, Web Accessibility Remediation, Website Accessibility
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

Why Documents Get Left Behind

The Ripple Effect of Inaccessible Documents

Excluding People Who Rely on Assistive Technology

Legal and Compliance Risks

Strains on Operations and Budgets

Damage to Trust and Reputation

Habits That Make Documents Accessible

Building a Culture That Lasts

From Awareness to Action

The Business Case for Inclusive Brand Design

The Market Opportunity

The Digital Disconnect in Inclusive Brand Design

The Reality in Numbers

The Unfinished Promise

The Benefits of Embracing Digital Accessibility

Reach More Customers, Build More Trust

Boost Search Visibility

Better Experiences for Everyone

Efficiency and ROI Gains

Five Building Blocks for Inclusive Brand Design Online

1. Start with the Standards

2. Audit, Prioritize, and Iterate

3. Design and Develop for Accessibility

4. Blend Automation with Human Testing

5. Create a Culture, Not a Checklist

A Chance to Lead With Inclusion

Plain Language Is the Heart of Accessible Web Content

Make Your Page Easy to Scan—By People and Tools

Links and Images That Strengthen Accessible Web Content

Effective Alt Text

Accessible Audio and Video for Every Situation

Guidance That Doesn’t Assume Vision or Memory

Formatting That Keeps Accessible Web Content Readable

Why These Techniques Matter

Ensure Your Words Work—Not Just Look Right

Accessible Content Is Good Content—Let’s Get You There

What Automated Platforms Do Well

The Role of Accessibility Consultants

Why Consultant-Led Remediation Should Come First

When Automated Platforms Make Sense

How to Decide What’s Right for You

The Long-Term Payoff

Human First, Automation Second

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?