Website 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
ADA Guidance Documents: Now You See Them, Now You Don’t
You’re ready to make your site accessible, but the “how” still feels scattered—too many opinions, not enough plain steps. You want a path that fits busy days, real budgets, and a team that’s already stretched. Maybe you’ve got a dozen tabs open and the same question lingering: “Where do we start?”

This guide gives you that grounding. We’ll explain why some public resources shifted (including ADA guidance documents) and what hasn’t changed about your responsibilities—then offer a calm, repeatable way to keep improving without the overwhelm.

Behind the Headlines: What Actually Changed

For years, website owners leaned on plain-English materials from the Department of Justice (DOJ) to turn legal text into everyday decisions. In March 2025, the DOJ withdrew a set of those materials—older how-to pages and pandemic-era Q&As. These ADA guidance documents weren’t binding law, but they acted like a friendly sidebar: “Are headings structured so screen readers can move around?” “Do forms have clear labels and announced errors?” “Do videos ship with captions by default?”

The intention was to “streamline.” The result, for many teams, was losing that quick translation layer. The ADA didn’t change. The shortcut explanations did.

What Are ADA Guidance Documents—and Why They Mattered Online

Guidance sits between regulations and real life. It doesn’t create new rules; it shows what good looks like. For web teams, that practicality was gold. It helped product leads, designers, developers, and content editors turn big goals into small, repeatable habits:
- Use semantic headings and landmarks so navigation is predictable.
- Ensure keyboard access works everywhere—and that focus is easy to see.
- Write meaningful alt text and descriptive link text.
- Tie error messages to the right fields and announce them clearly.
- Caption video and provide transcripts for audio.
In short: fewer guesses, fewer do-overs, fewer users getting stuck.

What This Means Day to Day

When the handy reference disappears, hesitation sneaks in. A button ships without an accessible name. Focus gets trapped in a modal. A hero banner looks great but misses contrast by a hair. A form works with a mouse but not a keyboard. None of these are headline news alone; together they slow someone’s day—or stop it. Without familiar ADA guidance documents, teams second-guess what’s “good enough,” and releases start to feel inconsistent.

But the baseline didn’t budge. The ADA still requires effective, equal access online. Courts still enforce it. And people still expect to complete tasks without extra hoops. The safest—and most respectful—move is to keep going, visibly and steadily.

Why Waiting for New Guidance Is Risky

It’s tempting to pause and hope for a new official playbook. Three reasons to keep moving instead:
- Legal exposure. Courts across the U.S. recognize that inaccessible sites and apps can violate the ADA. That trend didn’t reverse.
- Reputation and trust. Accessibility issues show up in reviews and social posts; quiet fixes made early rarely do.
- Real people, real tasks. When login, checkout, or account recovery breaks for assistive-tech users, you’re not just risking a suit—you’re losing customers.
Silence—or withdrawn ADA guidance documents—is not a safety net.

What Web Compliance Looks Like Right Now

Even without those quick-reference pages, your backbone is solid:
- Standards: Treat WCAG 2.1 Level AA as today’s target and map sensible upgrades toward WCAG 2.2. WCAG gives your team a shared, testable language for “accessibility.”
- Process: Fold accessibility into everyday work—requirements, design reviews, coding practices, content checks, QA, and release.
- Evidence: Keep lightweight notes on what you tested, what you fixed, and what’s queued. Perfect isn’t required; active, good-faith effort matters.
A Calm, Practical Web Plan (Built for Busy Teams)

Think “little and often,” not “big and never.” Small habits—kept—beat big intentions that stall.

1) A One-sentence North Star

“Everyone should be able to find, understand, and complete key tasks on our site—without special instructions.” When trade-offs get messy, let that sentence break the tie.

2) Make It Visible In Design

Bake contrast rules, focus styles, and ARIA patterns into your design system. Add a five-item gate to design reviews: contrast, text scaling, focus order, error visibility, and respect for motion/animation preferences. These guardrails prevent expensive rework later.

3) Test Every Release—Quickly And Consistently
- Run an automated scan for the easy wins (contrast flags, missing labels).
- Do a keyboard-only pass for navigation, focus order, skip links, menus, and modals.
- Add a screen-reader spot check (one core task in NVDA or VoiceOver) to confirm headings, landmarks, labels, and announcements make sense.
- Media check: captions/transcripts and no surprise auto-play.
- Ten focused minutes can save hours of cleanup.
4) Prioritize By User Impact

Fix blockers first—anything that keeps someone from starting, finishing, or recovering a task (focus traps, unlabeled inputs, errors that aren’t announced, inaccessible captchas). Then clean up the friction.

5) Write For Clarity

Descriptive link text beats “click here.” Headings should be meaningful and in order. Error messages should be specific and tied to their fields. Plain instructions help everyone, not just screen-reader users.

6) Train in Micro-moments

Skip the marathon. Rotate five-minute refreshers: writing alt text, managing focus in modals, structuring headings, testing keyboard paths. Small lessons stick because people can finish them.

7) Invite Feedback—And Close the Loop

Publish a simple accessibility statement with a real contact path. When someone reports an issue, acknowledge it, fix it, and thank them. That response builds trust and brings problems to you early.

8) Document Just Enough

Keep a rolling log (tickets or a short doc) noting checks, defects, fixes, and what’s next. It’s team memory, proof of progress, and a calmer conversation if you ever need to show your work.

Beyond Compliance: Better Web, Better Business

Compliance is the floor. Inclusion is the opportunity. The same choices that meet WCAG also reduce support friction and lift conversions: clearer forms, reliable focus, readable text, captions that help commuters and quiet-office viewers alike, motion that respects user settings. You don’t need fresh ADA guidance documents to make that case—the impact shows up in your analytics, your reviews, and the quiet relief of users who can simply get things done.

A Clear, Steady Path Forward

Here’s the bottom line: the ADA still stands, and the withdrawn ADA guidance documents didn’t change what “good” looks like online. Rebuild the convenience layer yourself—standards as guardrails, small checks each release, micro-training that sticks, open feedback, and just-enough documentation.

Start small. Keep going. Write down what works. That’s how you protect your brand, respect your users, and give your team a sustainable way to ship accessible experiences. And if a short, expert walkthrough would help you set that cadence, consider scheduling an ADA briefing with 216digital—calm, practical, and focused on your next few steps.
Greg McNeil

September 18, 2025

Legal Compliance

Accessibility, ADA, ADA Compliance, ADA Web Accessibility, WCAG, 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
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

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

Behind the Headlines: What Actually Changed

What Are ADA Guidance Documents—and Why They Mattered Online

What This Means Day to Day

Why Waiting for New Guidance Is Risky

What Web Compliance Looks Like Right Now

A Calm, Practical Web Plan (Built for Busy Teams)

1) A One-sentence North Star

2) Make It Visible In Design

3) Test Every Release—Quickly And Consistently

4) Prioritize By User Impact

5) Write For Clarity

6) Train in Micro-moments

7) Invite Feedback—And Close the Loop

8) Document Just Enough

Beyond Compliance: Better Web, Better Business

A Clear, Steady Path Forward

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