WCAG Archives - Page 2 of 8/Tag

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

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

What An Accessible PDF is—And Why the Law Cares

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

PDF/UA (ISO 14289): Technical Conformance

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

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

How They Fit Together

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

Operational Definition of “Compliant”

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

Why PDFs Are So Often Non-compliant

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

What AI-powered Accessibility Tools Do Well (Today)

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

Where AI Still Falls Short—and Why People Still Matter

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

The Hybrid model for Accessible PDF Compliance

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

AI is Powerful, But Not a Solo Act

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

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

August 26, 2025

Legal Compliance

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

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

Why Accessibility Matters in California

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

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

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

1. Know Your Legal Landscape

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

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

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

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

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

3. Fix Barriers and Align with WCAG 2.2 Level AA

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

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

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

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

5. Plan for Ongoing Compliance

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

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

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

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

Accessibility: Not a Project, a Practice

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

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

Need Help Making Sense of It All?

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

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

August 22, 2025

Legal Compliance

Accessibility, California Consumer Privacy Act, California Web Accessibility Laws, Legal compliance, WCAG, Web Accessibility, Website Accessibility
Email Accessibility: Make Every Click Count

You spend hours testing subject lines, analyzing open rates, and crafting the perfect call to action. But if your emails are not accessible, you may be unintentionally excluding millions of potential readers. More than one billion people around the world live with some form of disability, and many rely on assistive technologies such as screen readers, magnifiers, or keyboard navigation to interact with digital content. This is why email accessibility should be at the center of every campaign you send.

This is where email accessibility makes a difference. Accessible emails do not only support people with disabilities; they also improve reach, engagement, and usability for everyone. You can think of accessibility as a safety net during your quality assurance process, one that helps make sure your hard work actually reaches its audience. The encouraging part is that small and thoughtful changes can create a big impact.

Structure and Layout: Design for Navigation, Not Just Aesthetics

Attractive design may catch the eye, but structure is what allows readers to move through your message with ease. Using semantic heading tags such as <h1>, <h2>, and <h3> helps organize your content in a way that screen reader users can understand. Headings should flow in a logical order without skipping levels. Relying on bold text or font size alone to show importance does not provide the same clarity.

Tables are another common issue. They should be avoided for layout purposes whenever possible because screen readers can misinterpret them. If a table must be used for structure, adding role="presentation" tells assistive technology that it is decorative rather than data.

It is also important to test your emails using only the Tab key. If you cannot reach every link, button, and input field by tabbing through the message, your subscribers will face the same problem.

Image Accessibility: More Than Just Pretty Pictures

Images are powerful in marketing emails, but without the right preparation, they can create barriers. Every image should include descriptive alt text that explains its purpose. If the image is decorative and does not add meaning, use empty alt text so that screen readers can skip it.

Critical information, such as discount codes or calls to action, should never exist only within an image. Live text ensures that the message still appears even if images are turned off in the inbox. A good test is to disable images and see whether the email still conveys your intended message.

Animations also require care. Flashing or strobing content can cause serious discomfort or even seizures for some readers. Autoplaying GIFs may distract from your main message. Whenever possible, give users the ability to pause or stop moving elements.

Links and Calls to Action: Clear, Clickable, Inclusive

Calls to action are where engagement happens, and they must be designed with clarity in mind. Instead of vague text such as “Click here,” choose phrases like “Read the full guide” or “Shop the new collection.” Screen reader users often move through an email by jumping between links, so each one needs to make sense on its own.

Links should always be visually distinct. Underlining them is the best practice since relying on color alone is not effective for people with color blindness. Buttons and links should also be large enough to tap easily on a mobile device. A minimum size of about 44 by 44 pixels provides enough room for users with limited dexterity. Spacing links apart reduces the chance of misclicks. These adjustments not only improve email accessibility but also increase click-through rates by making the experience smoother for everyone.

Copywriting and Readability: Make Every Word Count

Email accessibility applies to words as much as to code or design. Short and direct sentences help readers understand quickly. Breaking your content into smaller paragraphs with clear subheadings makes the email less overwhelming.

Avoid heavy jargon or insider language that may confuse people. Simple words in everyday language travel further and faster. Writing in an active voice also helps keep your copy engaging.

Do not forget the basics of text styling. Font sizes should be at least 14 points, which is especially important for people with low vision or anyone reading on a small screen. Text should be left-aligned only, since centered or justified alignment slows down reading speed and can reduce comprehension.

Multimedia Content: Do Not Skip the Captions

Many email campaigns now include video, audio, or GIFs. These can make content more dynamic, but they bring accessibility challenges that need attention. Any video or audio clip should come with captions or transcripts. Captions are essential for people who are deaf or hard of hearing, but they also help people who are in noisy environments or those who are somewhere quiet and cannot turn on the sound.

Animated GIFs should avoid flashing sequences or rapid loops. If movement is key to your message, include a description of it in the email copy or offer a static fallback image. Multimedia can be powerful, but it should never come at the expense of accessibility.

A Pre-Send Accessibility Checklist

Before you hit send, it helps to run through a quick accessibility check. Try navigating the email with only your keyboard. Make sure every image includes descriptive alt text or an empty alt attribute if it is decorative. Look at your link text and ask if it clearly describes the action or destination. Turn images off and check if the message still makes sense. Confirm that your color contrast is strong enough to read comfortably. Review your animations to see if they are subtle and under control. Lastly, read the text on both desktop and mobile screens to confirm that the font size is easy to read.

These checks only take a moment, but they can prevent frustration and lost engagement.

Accessibility Is a Long Game, but Every Email Helps

No email will ever be perfectly accessible. The goal is not perfection but progress. Each improvement you make expands your reach, improves engagement, and builds trust with your audience.

Email accessibility is not only about legal compliance. It is also about creating meaningful connections. By removing barriers, you ensure that your message reaches as many people as possible and resonates more deeply with them. Making email accessibility part of your long-term strategy strengthens both your brand reputation and the experience of every subscriber.

The next time you prepare a campaign, add accessibility to your checklist. Treat it as part of your workflow, not an extra chore. An inaccessible email is never as effective as it could be.

If you need a clear plan for accessible digital communication, schedule an ADA briefing with 216digital. We will walk you through practical steps to make your email campaigns and your digital presence more inclusive, more effective, and better prepared for the future.

Greg McNeil

August 12, 2025

How-to Guides, Legal Compliance

Accessibility, email accessibility, WCAG, WCAG Compliance, Website Accessibility
When Web Accessibility Standards Gets Fuzzy
Every team that works on digital accessibility eventually runs into the same moment: the rules don’t feel black and white. You’re following the Web Accessibility Guidelines (WCAG) and doing your best to interpret them. Then suddenly, you find yourself asking: Does this count? Are we helping everyone, or could this fix create a new barrier somewhere else?

That’s not a sign you’re doing something wrong. It’s how web accessibility standards are written. WCAG is designed to cover countless technologies, contexts, and user needs—not to prescribe one rigid answer for every situation. That flexibility leaves room for judgment, but it can also leave teams second-guessing their choices.

This article is here to help. We’ll walk through why these “grey areas” exist, why they’re not a weakness but a feature of the standard, and—most importantly—how you can approach them with confidence. You’ll get a practical, repeatable framework to guide decisions, reduce risk, and keep accessibility focused on what really matters: creating digital experiences that work for people.

What Are WCAG “Grey Areas”?

“Grey areas” are success criteria that can be met in more than one valid way, or where context changes the best answer. They matter because solving for one disability group can, at times, introduce friction for another. Trade-offs are real, and responsible teams face them head-on.

These scenarios highlight why web accessibility standards are intentionally flexible, pushing teams to weigh impact, not just compliance.
- Dark mode: A darker theme can reduce glare and help many people with low vision or light sensitivity. But some users with dyslexia or astigmatism may read best with higher-contrast dark text on a light background. A user-controlled toggle is a solid compromise.
- Reflow (SC 1.4.10): Avoiding horizontal scroll at 320–400 px width sounds simple, until a multi-column data table collapses and users lose the ability to compare rows and columns.
- Non-text contrast (SC 1.4.11): What counts as “essential” visual information? In infographics or dense UIs, borders, separators, and icon strokes can be more important than they look at first glance.
- Link purpose (SC 2.4.4): Is “See details” okay? Often yes—if the link sits under a descriptive product name or is wrapped with an accessible name/description that conveys purpose. If a page lists 20 identical “Read more” links with no additional context, that’s a problem.
- Alt text: Even the basics aren’t always basic. An image might need a rich description on a museum site, but be marked decorative in a dashboard if it adds no meaning.
Why Ambiguity Exists—and Why That’s Okay

WCAG isn’t a script; it’s a set of outcomes. It avoids prescribing specific UI patterns so it can work across devices, frameworks, and future tech. That flexibility can feel frustrating when you need a yes/no answer today. But it’s also where web accessibility standards allow accessibility leadership to shine.

The goal isn’t perfection. It’s clarity, consistency, and usability—especially for people who rely on assistive technology. When the standard leaves room for interpretation, your job is to apply sound reasoning, test with real users, and document what you did and why.

A Practical Framework for Resolving WCAG Grey Areas

Use this five-step process to move from “it depends” to “here’s what we’ll do.”

Step 1: Start with the Source

Go beyond the short success-criterion text and read the Understanding WCAG guidance. These pages explain intent, define terms, and include examples and common failures. Many “edge cases” are addressed there, even if not word-for-word identical to your scenario.

Tip: Keep a shared team doc of the Understanding pages you reference most. It speeds consensus.

Step 2: Analyze Real User Impact

Shift from “Does this pass?” to “Who does this help or hinder—and by how much?” Consider:
- Screen reader and braille users
- Keyboard-only and switch users
- Low-vision users (zoom, magnifiers, custom styles)
- Users with cognitive or attention-related conditions
- Motion/vestibular sensitivities and color-vision differences
Ask: Does one option create a minor inconvenience while another blocks a key task? If a choice affects checkout, account access, or a critical service, prioritize task success over neatness or brand purity.

Step 3: Test with People Who Use AT

When the stakes are high, run quick, focused usability tests with people who use assistive tech. You don’t need a giant study. Five to eight participants who reflect the impacted group can reveal what theory can’t.
- Scope the test to the specific component or flow.
- Observe with screen readers, keyboard only, and zoom.
- Capture where users stumble, not just what they say.
User evidence turns debates into decisions.

Step 4: Phone a Friend (the Right One)

If internal consensus stalls, bring in an accessibility expert with hands-on WCAG experience—ideally someone comfortable with dynamic UIs, eCommerce patterns, and ARIA.

Credentials like CPACC can help, but project-based proof matters most: “Show me where you solved this before.”

Step 5: Document Your Rationale

Most teams skip this safety net. For every grey-area decision, record:
- The WCAG criterion(s) at issue
- The ambiguity you faced
- The options considered
- The reasoning: user impact, technical feasibility, constraints
- Any expert input or user-testing results
- The final decision and where it applies (component, template, page type)
Store this where designers, developers, QA, and product can find it. You’ll create consistency across teams and time.

Common Examples, Resolved with the Framework

Let’s revisit those tricky scenarios and apply the process. This is where teams can see how web accessibility standards translate from theory into practice.

Reflow vs. Data Integrity (SC 1.4.10)
- Challenge: A comparison table collapses at 320 px, and users can’t relate cells across columns.
- Approach: Understanding WCAG clarifies that the intent is to avoid two-dimensional scrolling for most content while preserving meaning.
- Decision: Provide a responsive table with a toggle: stacked rows by default for small screens, with a “Compare columns” view that preserves tabular relationships and allows horizontal scroll within the table container. Add a “Skip to table comparison” anchor and ARIA summary to explain the toggle.
- Result: Reflow is respected where it helps, and comparison remains possible where it matters.
Link Purpose in Card Grids (SC 2.4.4)
- Challenge: Product cards each have an image, name, price, and a “See details” link.
- Approach: Screen reader testing shows that when the product name is an accessible link, the extra “See details” adds noise.
- Decision: Make the product title the primary link with a descriptive accessible name (e.g., “View details for Acme Pro Blender”). Keep “See details” visible but aria-hidden or make it a button that moves focus to the same target for sighted mouse users who expect it.
- Result: Purpose is clear programmatically and visually; duplication is removed for AT users.
Non-Text Contrast on Icon Buttons (SC 1.4.11)
- Challenge: Icon-only controls use thin strokes that technically reach 3:1 against the background, but some users miss them.
- Approach: Prioritize recognizability over minimalism.
- Decision: Increase stroke width and contrast on the icon and its focus indicator. Add an accessible name (e.g., “Filter results”) and a visible label on hover/focus for cognitive clarity.
- Result: The control is perceivable and operable for more users—even if it slightly shifts the visual aesthetic.
Dark Mode and Motion Preferences
- Challenge: Dark mode improves comfort for many, but not all. Animations delight some, but can trigger discomfort for others.
- Approach: Respect user control and system settings.
- Decision: Provide a theme toggle that remembers preference. Honor prefers-color-scheme and prefers-reduced-motion. Keep contrast targets consistent across themes.
- Result: Users opt into what works for them; your defaults are inclusive, not absolute.
Alt Text in Dashboards
- Challenge: Decorative charts and status icons risk becoming screen reader noise.
- Approach: Identify the purpose of each image.
- Decision: Provide a textual summary or data table for the chart. Mark decorative images with empty alt (alt=""). For meaningful icons, supply concise alt text or an aria-label on the control they’re part of.
- Result: Users get the information without redundant chatter.
Let Strategy Guide You—Not Guesswork

Grey areas in web accessibility standards aren’t flaws to fear—they’re invitations to make thoughtful, people-first choices. With a repeatable process, you can:
- Ground decisions in the intent of WCAG, not just the letter web accessibility standards.
- Weigh real user impact over theoretical compliance.
- Validate with targeted testing and expert input.
- Build a paper trail that improves consistency and reduces risk.
Accessibility is a journey, especially on complex products. You won’t get every decision perfect the first time, and that’s okay. What matters is that your choices are deliberate, documented, and centered on the people who need your site to work every single time.

Need a second set of eyes? If your team is wrestling with ambiguous criteria, we can help you apply web accessibility standards in a way that fits your design system, codebase, and real users. Schedule an ADA briefing with 216digital to walk through your grey-area challenges and map a clear, defensible path forward.
Greg McNeil

August 7, 2025

WCAG Compliance

Accessibility, WCAG, WCAG Compliance, WCAG conformance, Website Accessibility
UX in Mind: Your Simple Guide to Accessible Design
The success of any website or app really boils down to one thing: how it feels to use. If people can navigate your site easily, find what they’re looking for, and get things done without frustration, they’re far more likely to stick around—and come back. But when the experience is confusing, clunky, or leaves some users behind? That’s when you lose them.

At its core, good UX design is about making sure everyone can use your product—regardless of ability, device, or familiarity. The best experiences don’t just work for some; they work for all.

We’ve put together a practical checklist to help you design with accessibility in mind—covering visual, auditory, motor, and cognitive needs. And we’ll point you toward helpful tools and resources so you can keep learning, keep improving, and keep building digital experiences that truly welcome everyone.

The Fundamentals of Accessible UX

Accessibility is about designing for how people actually live and interact—not just for some perfect, idealized user. It’s about making space for the full range of human experiences, because that’s who’s showing up at your digital doorstep. And when you zoom out, the impact becomes clear: over 16% of the world’s population lives with a significant disability. When you keep that in mind from the start, the end result isn’t just more inclusive—it’s better for everyone.

And yes, the benefits are very real:
- You’ll reach more people
- Build stronger trust with your audience
- Lower your legal risks
- And create a smoother, more enjoyable experience across the board
But to get there, it helps to understand how accessibility and usability work together.

Accessibility vs. Usability

Accessibility and usability go hand in hand, but they aren’t quite the same thing. Accessibility means people can use your site—regardless of ability. Usability means they want to. It’s the difference between building a ramp and making sure the door is easy to open once you get there. When both are in place, you’re not just meeting a requirement—you’re delivering a great experience.

So how do you do that in practice?

In the sections ahead, we’ll walk through four key areas to focus on: visual, auditory, motor, and cognitive accessibility. Each one connects to the WCAG POUR principles—Perceivable, Operable, Understandable, and Robust—which are all about making digital content work well for as many people as possible, in as many ways as possible.

Visual Accessibility: Making Your Content Clear

When it comes to digital experiences, what people see—and how clearly they see it—matters. Strong accessible design means your content shows up well for everyone, no matter their vision or viewing environment. Whether someone’s using a screen reader, navigating with magnification tools, or just scrolling on their phone in the sun, your design choices can make a big difference.

Color and Contrast: Give Every Element a Voice

Color does a lot of heavy lifting in design, but it shouldn’t have to carry meaning on its own. Good contrast helps your content stand out and stay legible in all kinds of settings—from dark rooms to bright sidewalks. Use tools like WebAIM Contrast Checker to spot trouble areas before your users do.

Instead of just using red to show an error, pair it with an icon and a message that says what’s going on. That way, everyone—regardless of how they see color—gets the same info. And skip putting important text over photos or gradients. It might look nice, but it often makes things harder to read.

Try this: View your layout in grayscale. Can you still tell what’s what? If not, it’s time for a few tweaks.

Text and Typography: Keep It Clean and Comfortable

Fonts don’t just carry words—they carry the experience. Stick with simple, sans-serif fonts like Arial, Helvetica, or Open Sans. They’re easier to read and less likely to cause eye strain. Avoid fancy decorative fonts for body copy, and go with a minimum of 16px for body text. Line height should feel breathable—somewhere around 1.4 to 1.6x the font size—so your words don’t feel cramped.

And remember, people should be able to zoom in up to 200% without a loss of content. That’s not just a nice-to-have—it’s part of WCAG’s requirements.

Quick test: Zoom way in and try navigating with just a keyboard. Everything should still be readable, usable, and scroll in one direction.

Images and Media: Describe What Matters

Images aren’t just decoration—they carry meaning, emotion, and context. But that only works if everyone gets to experience them. That’s where alt text comes in. For each image, ask yourself: What is this doing here?

If it’s decorative, mark it with empty alt text (alt=""). If it’s showing something important—like a process, a chart, or an instruction—give it a short, clear description. And for complex visuals? Offer a more detailed breakdown nearby or link out to a longer description.

Heads up: Avoid embedding key text inside images. If you have to, make sure that the same info is also available as live text on the page.

Links and Structure: Build a Clear Path

“Click here” doesn’t cut it anymore. Link text should be clear and specific—like “Download the full pricing guide” or “View shipping options.” This gives screen reader users meaningful context and helps anyone scanning your page understand exactly where a link will take them.

But clarity isn’t just about links—it’s about how the entire page is structured.

Use semantic headings (H1 to H6) to create a strong, logical outline. That helps screen reader users and keyboard navigators alike. And if you want to go a step further, use ARIA landmarks (like role= "main" or role= "navigation") to give even more structure to your layout.

Try this: Tab through your site or listen to it with a screen reader. If the page sounds confusing out loud, it probably reads that way too.

Auditory Accessibility: Sound That Speaks to Everyone

Audio can bring depth to your content—but only if it’s accessible. Make sure all multimedia includes captions or transcripts. This isn’t just about supporting users who are d/Deaf or hard of hearing—it’s about meeting people where they are: whether they’re in a crowded café, a quiet office, or scrolling with the sound off.

Captions should be accurate, well-timed, and include important background sounds like [music] or [laughter] when they add meaning. Bonus points if you also let users control playback speed, jump to specific moments, or pause when needed.

Skip the surprise: Don’t autoplay audio or video. And if it starts automatically, make sure there’s an easy-to-find pause or mute button.

If your design relies on voice commands, always offer another way to engage—like buttons, text input, or keyboard shortcuts. Voice should be an option, not a barrier.

Motor Accessibility: Let Everyone Navigate Their Way

Not everyone uses a mouse. For some users, navigating your site with a keyboard—or assistive tools like switch controls—is their primary method. That’s why motor accessibility is so important.

Your site should be fully usable with just a keyboard. That means:
- A logical tab order that follows the flow of the page
- Visible focus styles that clearly show where the user is
- Accessible modals that keep focus inside until they’re closed
- A skip link to let users jump past repeated content
Touch targets need to be big enough—at least 44px by 44px—and spaced well so people don’t hit the wrong button by accident. And don’t rely on hover-only tooltips. Make sure the same info shows up when elements get keyboard focus or a tap.

Test it out: Try using your site with only the keyboard. You’ll quickly spot any dead ends or frustrating traps.

Cognitive Accessibility: Make It Clear, Make It Work

Cognitive accessibility is about reducing mental strain. It’s for users who may be neurodivergent, have memory or learning differences, or just want a simpler, calmer experience (which, honestly, is all of us sometimes).

Consistency is key. Stick with familiar UI patterns and avoid switching up layouts too often. Too many options on one page? That can be overwhelming. Break things down. Keep it focused.

Tips that go a long way:
- Use plain, conversational language
- Break content into bite-size chunks
- Add helper text or examples near form fields
- Use bullet points and clear headers to help users scan
Avoid flashy carousels, blinking elements, or countdown timers that can’t be paused. If a timer is necessary—say for a session timeout—give users a heads-up and a way to extend their time.

Pro move: Offer a simplified or “reading mode” view for content-heavy pages. It can make a big difference in comprehension and comfort. These types of accessible design choices often benefit all users, not just those with cognitive disabilities.

Accessible Design Checklist

Keep this quick-reference checklist close at hand:

▪ Strong color contrast (4.5:1 minimum)

▪ No reliance on color alone for important information

▪ Legible, scalable fonts and adequate spacing

▪ Descriptive alt text for images

▪ Clear, descriptive link text

▪ Proper heading structure (H1–H6)

▪ Keyboard navigable with logical tab order

▪ Captions and transcripts for all multimedia

▪ Accessible media playback controls

▪ Large, spaced interactive elements

▪ Consistent layout and navigation

▪ Plain language instructions

▪ Flexible time limits for tasks and forms

Accessible Design Never Clocks Out

You’re already doing the work—asking better questions, designing more thoughtfully, and looking at your site through more than one lens. That’s what leads to lasting change.

There’s no final destination when it comes to accessible design. But every shift in your design process—every adjustment, every decision made with someone else’s experience in mind—moves the web in the right direction.

And if you ever want backup or a fresh set of eyes, 216digital is here to help. We offer accessibility briefings to give you clarity, confidence, and a plan to move forward.
Greg McNeil

July 24, 2025

How-to Guides

Accessibility, Accessible Design, Graphic Designer, How-to, inclusive desgin, UX, WCAG, Web Accessibility, Web Accessible Design
What States Have Their Own Accessibility Laws?
It’s one thing to know that digital accessibility matters. It’s another to figure out which accessibility laws actually apply to your business—and that’s where things start to get murky. Some states follow the federal lead. Others have their own rules, timelines, and expectations. A few have no official laws at all but are still seeing lawsuits.

It’s not always clear where the lines are. And if you’re trying to do things right—without getting blindsided later—it helps to know what’s happening in your state, not just in theory.

Here’s what’s really going on across the country, one state at a time.

The Federal Foundation for Digital Accessibility

Before we get into what each state is doing, let’s take a quick look at the bigger picture. At the federal level, two key laws shape how we approach digital accessibility: the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act. These set the baseline—and everything else tends to build from there.

Americans with Disabilities Act (ADA)

The ADA has been around since 1990, created to prevent discrimination against people with disabilities in all areas of public life. While the law doesn’t specifically mention “websites” or “apps,” courts have increasingly interpreted digital platforms to fall under its scope—especially when tied to public services or businesses that serve the public.

Titles II and III of the ADA
- Title II applies to state and local governments. It requires their websites and digital services—like online forms, schedules, and service portals—to be accessible to people with disabilities.
- Title III covers private businesses and nonprofits, from retailers and restaurants to healthcare providers. If you’re offering goods, services, or information online, accessibility isn’t optional—it’s expected.
Although the ADA doesn’t lay out specific technical standards, most lawsuits point to the Web Content Accessibility Guidelines (WCAG) as the benchmark. Ultimately, ADA compliance is about more than avoiding a lawsuit—it’s about making sure everyone, regardless of ability, can fully participate in today’s digital world.

Section 508 of the Rehabilitation Act

Section 508 of the Rehabilitation Act plays a major role in shaping digital accessibility across federal agencies. Originally passed in 1973 and expanded in 1998, it requires that all federal electronic and information technology (EIT) be usable by people with disabilities. That includes everything from websites and software to internal systems and public documents.

But its impact goes beyond government offices. If you’re a contractor or vendor working with federal agencies, you’re expected to follow these same standards. That has made Section 508 a powerful driver of accessible design across both public and private sectors.

Together, Section 508 and the ADA form the foundation for digital accessibility compliance across the country. But depending on where you operate, state-specific laws may also come into play.

States with Their Own Accessibility Laws

While every state must comply with the ADA and Section 508 over 30 states have adopted digital accessibility requirements beyond the federal baseline.

Alaska

Alaska does not currently have its own state-specific digital accessibility laws. However, the state government maintains a State of Alaska ADA Compliance Program and voluntarily adheres to WCAG 2.1 Level AA standards for its own digital services. This means that while there are no separate legal mandates in place, Alaska’s agencies are actively working to ensure their websites and online content are accessible to individuals with disabilities.

Arizona

Arizona has incorporated digital accessibility into its statewide IT policy. The state’s accessibility policy requires all government agencies and entities receiving state funding—except certain universities—to follow clear accessibility guidelines. These standards are designed to ensure that public-facing digital content is usable by people with disabilities and aligned with current best practices, including WCAG principles.

Arkansas

Arkansas has its own digital accessibility law known as Act 1227 of 1999. This legislation requires that all state government agencies and entities receiving state funding ensure their websites are accessible—particularly to individuals who are blind or visually impaired. While the law predates modern WCAG guidelines, it underscores the state’s early commitment to creating digital spaces that serve all users equally.

California

California has some of the most comprehensive digital accessibility laws in the country, reflecting the state’s broader commitment to civil rights and inclusive technology. Key statutes include:
- Government Code Section 11545.7: Requires every state agency to post a certification of compliance with digital accessibility standards on their website every two years. Sites must meet the requirements of Sections 7405 and 11135 and align with WCAG 2.0 Level AA.
- Government Code Section 7405: Reinforces Section 508 of the Rehabilitation Act and mandates that state agencies ensure their electronic and information technology is accessible.
- Unruh Civil Rights Act: Prohibits businesses from discriminating based on disability, including through their digital services. The law applies even to out-of-state companies selling products or services to Californians. Violators can face minimum fines of $4,000 per offense.
- Government Code Section 11135: Similar to the Unruh Act, but focused on state-run or state-funded programs. It bars discrimination in any activity or program operated by or receiving financial support from the state.
Taken together, these laws make California one of the most proactive states when it comes to digital inclusion—and a state where accessibility compliance is not just encouraged, but enforceable.

Colorado

Colorado is one of the most recent states to pass ts digital accessibility laws with House Bill 21-1110, also known as the Colorado Laws for Persons with Disabilities. Effective July 1, 2024, this legislation builds on federal requirements by mandating that all digital content from state agencies and public higher education institutions be accessible to individuals with disabilities. The law also ensures that no person with a disability is excluded from any service, program, or activity offered by a public entity or state agency.

Connecticut

Connecticut requires all state agencies to follow a Universal Website Accessibility Policy. This policy mandates conformance with WCAG 1.0 Level A and includes a Checklist of Design Requirements to help agencies meet usability and accessibility expectations. While the standards are dated, they represent an early commitment to digital inclusion.

Delaware

Delaware has a state Digital Accessibility Policy that requires all public-facing digital content to meet WCAG 2.1 Level AA standards. This ensures that state websites and services are usable by individuals with disabilities.

Georgia

Georgia requires all state-managed digital content to meet WCAG 2.1 Level AA. This ensures that websites and services from state agencies are accessible and usable for people with disabilities.

Idaho

Idaho provides Web Publishing Guidelines that outline IT and telecom standards for state agencies, along with templates and accessibility best practices to help make digital content more inclusive and user-friendly.

Illinois

Illinois adheres to the Illinois Information Technology Accessibility Act (IITAA), requiring all state agencies and public universities to ensure their websites and IT systems are accessible to individuals with disabilities. The act outlines clear technical standards and encourages forward-thinking digital inclusion efforts.

Indiana

Indiana enforces Indiana Code 4-13.1-3, which supports Section 508 of the Rehabilitation Act. This law mandates that all digital services—including websites, applications, IT systems, and digital documents—managed by the state must be accessible to people with disabilities.

Iowa

Iowa follows a Website Accessibility Standard that requires all state agencies and publicly funded contractors to meet WCAG 2.0 Level AA. This ensures digital content and services align with accessibility best practices.

Kansas

Kansas implements digital accessibility through its Information Technology Executive Council (ITEC) Policy, which sets accessibility requirements for all state agencies and contractors handling digital assets.

Louisiana

The Louisiana Office of Technology Services (OTS) has adopted WCAG 2.1 as the baseline accessibility standard for all state-managed digital content, ensuring compliance with current accessibility guidelines.

Maine

Maine’s Digital Accessibility and Usability Policy requires all state-produced digital content and services to meet accessibility standards. Vendors must comply with WCAG 2.0 Level AA, with oversight and support provided by the Information Technology Accessibility Committee and the Maine IT Accessibility Team.

Maryland

Maryland enforces the Maryland Information Technology Nonvisual Access (MD IT NVA) Regulatory Standards, which require all new or upgraded IT systems within the state government to be fully accessible for nonvisual users.

Massachusetts

The Enterprise Information Technology Accessibility Policy in Massachusetts mandates that all applicable digital assets, including software, websites, and reports, meet WCAG 2.1 Level AA. Compliance is required for all executive branch agencies.

Michigan

Michigan’s Digital Accessibility Standard applies to websites, software, digital reports, and other digital assets. Executive branch agencies are required to ensure conformance with WCAG 2.1 Level AA.

Minnesota

Minnesota enforces the State of Minnesota Digital Accessibility Standard, most recently updated on July 1, 2024. It requires state agencies to meet WCAG 2.1 and provide accessible websites and digital documents.

Missouri

Missouri’s law, RSMo. 161.935, requires that all state agencies ensure their information technology is accessible throughout development, procurement, maintenance, and use. The law also extends to contracts and grants involving ICT.

Montana

Montana’s accessibility requirements are defined in state code 18-5-605 (formerly HB 239), which mandates that all state agencies provide IT access to individuals who are blind or visually impaired.

Nebraska

Nebraska’s Accessibility Policy requires that all ICT provided by state agencies meet WCAG 2.1 standards to ensure accessibility for users with disabilities.

Nevada

Nevada enforces its ADA Technology Accessibility Guidelines, which apply to all state entities and require conformance with WCAG 2.1.

New Hampshire

New Hampshire has its own Web and Mobile Application Accessibility Standards, which apply to all state agencies. The standards reinforce Section 508 compliance and recommend WCAG 2.0 as a guide to increase accessibility. A downloadable PDF of the standard is available on the state’s accessibility policy webpage.

New Jersey

New Jersey passed NJ A4856, a law requiring all digital platforms and web services used by school districts, charter schools, renaissance schools, and the Marie H. Katzenbach School for the Deaf to meet WCAG 2.1 Level AA.

New York

New York follows Accessibility of Information Communication Technology (NYS-P08-005) along with Senate Bill S3114A. These policies set the minimum accessibility standards for state agency websites and require conformance with the most current version of the WCAG.

Ohio

Ohio’s Administrative Policy IT-09: Website Ability mandates that all state agency websites, including those developed by third-party vendors, conform to WCAG 2.0 Level AA.

Oklahoma

Oklahoma enforces the Electronic and Information Technology Accessibility (EITA) Law, passed in 2004. This law incorporates the updated Section 508 standards and mandates WCAG 2.0 compliance for all state agencies.

Pennsylvania

Pennsylvania’s Information Technology Policy (ITP-ACC001) requires that all state government agencies meet revised Section 508 standards and the most current version of WCAG Level AA. Agencies are also encouraged to strive toward Level AAA.

Rhode Island

Rhode Island mandates that all state websites meet W3C’s Priority 1 Checkpoints, which are based on WCAG 1.0 standards.

Texas

Texas enforces the Texas Web Accessibility Standards, which are part of its Electronic Information Resources Accessibility Policy. Based on Section 508, these standards also include unique criteria for webcasts, applets, and plug-ins. In addition, Texas Administrative Code Sections 206 and 213 require that all state government and higher education websites meet accessibility standards.

Utah

Utah’s code 63A-16-209 outlines accessibility requirements for executive branch agencies. It mandates that agency websites and IT systems conform to the latest version of WCAG.

Virginia

Virginia enforces both the Virginia Information Technology Access Act (ITAA) and the Virginia Information Technology Accessibility Standard. Created by the Virginia Information Technologies Agency (VITA), these standards require conformance to Section 508 and WCAG 2.0 Level AA for all state agencies and higher education institutions.

Washington

Washington enforces the USER-01 Accessibility Policy (formerly Policy 188), which applies to all state agencies. It sets WCAG 2.1 Level AA as the minimum requirement for digital accessibility.

Need Help Navigating Accessibility Laws?

rying to make sense of accessibility laws—especially when each state plays by slightly different rules—can feel like walking through fog. Just when you think you’ve figured it out, something changes. That’s completely normal.

If you’re not sure where your website stands or what steps to take next, you don’t have to figure it out alone. We work with teams every day who are navigating this same landscape. Whether you’re starting from scratch or trying to patch up an old site, we’re here to help you move forward confidently—with clarity, not confusion.

Let’s talk. Schedule an ADA briefing with 216digital, and we’ll help you sort out what applies, what matters most, and what to do about it.

Note: This article is for informational purposes only and does not constitute legal advice. Laws are subject to change. Always consult with legal counsel or a qualified accessibility specialist.
Greg McNeil

July 22, 2025

Legal Compliance

Accessibility, accessibility laws, state accessibility laws, WCAG, Web Accessibility, Website Accessibility
How to Identify Decorative Images for Accessibility
Images can bring a web page to life—but not all of them need to speak. When it comes to web accessibility, knowing which images are decorative and which are informative is key to creating a cleaner, smoother experience for people using screen readers and other assistive technologies. That’s where alternative text (alt text) comes in.

You probably already use alt text to describe important images. But what about the purely visual ones—those flourishes and background elements? If they don’t add value beyond appearance, they might be decorative images. This article helps you identify which images fall into that category and how to properly mark them, so screen reader users aren’t bogged down by unnecessary noise.

By focusing on even small improvements—like skipping redundant descriptions—you can build better, more respectful websites.

What Makes an Image “Decorative”?

Let’s start with the basics. According to WCAG 2.1 Success Criterion 1.1.1: Non-text Content, all meaningful non-text content must have a text alternative. But decorative images are an exception—they don’t need a description because they don’t carry meaning.

So, what exactly counts as decorative?

Common Decorative Image Types
- Borders, swirls, and flourishes that are strictly for looks
- Icons next to already-labeled buttons (like a phone icon next to the word “Call”)
- Stock photos that add mood or style but aren’t referenced in content
- Repetitive logos or design elements used as dividers or backgrounds
If removing the image doesn’t change the message or function of the page, you’re likely dealing with a decorative image.

Making the Right Call: Informative or Decorative?

It’s not always black and white. Here are a few quick questions to help:
- Does the image convey info that isn’t available in the text?
- Would a user miss out on something if the image was gone?
- Is the image part of an instructional step, chart, or link?
If you answer yes to any of these, the image is probably informative—and it needs descriptive alt text. If not, you may be safe to treat it as decorative.

For a more detailed approach, try W3C’s Alt Decision Tree. It’s a great tool, but don’t worry—no one expects you to follow it like a script. Trust your content instincts too.

Common Mistake Alert: Don’t mark company logos, charts, or instructional images as decorative. If they carry meaning or serve a function, they need proper alt text.

How to Properly Mark Decorative Images in Code

Once you’ve determined that an image is decorative, here’s how to ensure assistive technologies skip over it.

Use an Empty Alt Attribute

This is the most common and widely supported method:
```
<img src="divider.png" alt="">
```
Why does this work? A screen reader will completely ignore the image. This prevents confusion and keeps users focused on meaningful content.

But be careful: don’t skip the alt attribute altogether. Leaving it out may cause screen readers to read the file name—something like “divider-dot-p-n-g”—which is exactly the kind of noise we’re trying to eliminate.

Use role="presentation" or aria-hidden="true"

For SVGs, icons, or complex visual elements that can’t use alt="", try one of these:
```
<svg role="presentation">...</svg>
<img src="swirl.svg" aria-hidden="true">
```
What’s the Difference?
- role= "presentation" tells assistive tech: this element is just for visuals.
- aria-hidden= "true" hides the element from all assistive tech completely.
Choose one—don’t combine them with an empty alt attribute. Using both can confuse the accessibility tree and cause unpredictable results.

Best Practices & Pitfalls to Avoid

To keep your decorative images accessible:
- Use only one method to mark an image as decorative
- Test your implementation using screen reader emulators, WAVE, or Lighthouse
- Avoid using the word “decorative” in the alt text—use an empty alt attribute instead.
- Always include the alt attribute, even if it’s empty.
- Be careful not to hide meaningful images by using aria-hidden="true".
It’s also a good idea to review your CMS settings. Many platforms automatically insert images or fill alt text fields with file names. Stay alert!

Why It Matters: The Impact of Doing It Right

When you handle decorative images properly, you create a better user experience for everyone:
- Less noise for screen reader users, making it easier to navigate pages
- A clearer focus on important content and messages
- Reduced cognitive load, especially for users with visual or cognitive disabilities
- Cleaner code that’s easier to maintain and optimize
Bonus: It can even help with SEO by making your site more semantic and purposeful.

Real users have reported better experiences when extra, repetitive images are removed from their screen reader journey. It’s a small step with a big payoff.

Beyond Alt Text: Decorative Images Are Just One Part

Identifying and labeling decorative images is one part of a much larger accessibility picture. But it’s a foundational step.

Teams should regularly audit content—especially in environments where new images are often added, like blogs or e-commerce templates. Ask yourself: are new images truly meaningful, or just visual noise?

Also, remember: accessibility isn’t one person’s job. It’s a shared responsibility. Designers, devs, marketers, and content creators all play a role in making digital experiences more inclusive.

And if you’re using modern frameworks like React or Vue, be sure your components handle decorative images correctly and out of the box. A simple alt=”” on a reusable image tag can save a lot of friction.

Keep Image Accessibility Intentional

To recap: If an image is purely decorative, mark it so that screen readers skip over it. Use an empty alt="", or where needed, role= "presentation" or aria-hidden= "true". Don’t mix methods, and always test your work.

Improving how you handle decorative images might seem like a small detail, but it’s a powerful way to respect your users and refine your site’s accessibility. Thoughtful design isn’t just about how a site looks—it’s about how it feels to navigate.

Need a second pair of eyes on your accessibility implementation?

Schedule an ADA accessibility briefing with 216digital. Our experts can help you identify gaps, offer hands-on guidance, and take the guesswork out of inclusive design—so your digital experiences work better for everyone.
Greg McNeil

June 23, 2025

How-to Guides

How-to, Image Alt Text, WCAG, WCAG Compliance, web developers, web development
Descriptive Page Titles for Better Accessibility
If you’ve ever had 15 tabs open at once (and let’s be honest—who hasn’t?), you know how frustrating it is to click around trying to remember which one is which. When the titles are clear, you can find what you’re looking for in a second. When they’re not, it’s a guessing game.

For users who rely on screen readers or who live with cognitive or memory challenges, vague titles aren’t just annoying. They’re a real barrier. That’s where descriptive page titles come in. They make a huge difference in helping all users navigate the web more easily, and they support your site’s overall usability and accessibility—without requiring a major overhaul.

Best of all, it’s one of the simplest changes you can make that still packs a serious punch. A good page title improves orientation, reduces confusion, boosts your SEO rankings, and even helps reduce legal risk under the Americans with Disabilities Act (ADA). All with a few well-chosen words.

What WCAG 2.4.2 Actually Requires

Under WCAG 2.4.2—a Level A requirement in the Web Content Accessibility Guidelines (WCAG)—every web page must have a title that clearly describes its topic or purpose. It’s one of the most fundamental accessibility requirements, but it’s also one of the most overlooked.

Simply having a <title> tag isn’t enough. What’s inside that tag matters. A vague or generic title—like “Home” or “Untitled”—does little to help users understand what the page is actually about. It’s a bit like labeling all your folders “Stuff”—no one can navigate that efficiently, especially not users relying on assistive technologies.

This is especially important for screen reader users. Page titles are often read aloud as soon as a page loads or when switching between browser tabs. That brief moment of context helps them know exactly where they are. Similarly, sighted users benefit from meaningful titles when scanning through multiple open tabs or saving bookmarks for later reference.

Who Benefits from Descriptive Page Titles?

The short answer? Everyone. But here’s how it really plays out for different types of users:
- Screen reader users hear the page title as their first introduction. A vague or incorrect title can throw them off or force them to dig deeper than necessary.
- People with cognitive or memory challenges rely on titles to quickly understand whether a page is relevant. A well-written title can prevent information overload and reduce frustration.
- Mobility-impaired users benefit because they can avoid unnecessary clicks or key presses if the title tells them they’re on the wrong page.
- Everyone else—yes, even those without disabilities—appreciates descriptive page titles for the sheer convenience. Clear titles make it easier to navigate tabs, scan bookmarks, and share links confidently.
When a title says exactly what a page delivers, no one has to guess. That’s good usability—and that’s what accessibility is really about.

Common Title Mistakes (And How to Fix Them)

Even with the best intentions, many websites still fall into title traps. Let’s look at a few common problems:
- Too Vague: Titles like “Home” or “Blog” don’t help much when you’re trying to tell one tab from another.
- Reused Titles: When every blog post or account page is titled the same—like “Monthly Statement”—users lose their place quickly.
- Doesn’t Match the Page: If your title says “Pricing,” but the page is about features or FAQs, that mismatch causes confusion.
- Overloaded for SEO: You’ve seen these: “Best Home Trim Vinyl Windows Outdoor Accessories 2025 Guide.” They’re trying to do too much and end up helping no one.
Better Examples

Consider replacing generic titles with more descriptive ones. For example, swap “Blog Post” with “How to Write Descriptive Page Titles.” You might also change “Services” to “Real World Accessibility | 216digital,” or “Contact” to “Contact Us – 216digital Web Team.”

These small edits bring clarity, build trust, and boost both accessibility and SEO

Accessibility and SEO: They Work Together

There’s a common myth that writing for accessibility hurts SEO—but that couldn’t be further from the truth. In fact, descriptive page titles are a perfect example of how accessibility and SEO can work in harmony.

Search engines love pages with relevant, concise, and unique titles. So do people. That means when you follow accessibility best practices, you’re also improving your site’s visibility and user engagement.

Tips for Great Titles
- Keep them between 30–60 characters so they don’t get cut off in search results or browser tabs.
- Use primary keywords naturally, not awkwardly.
- Try using a pattern like: [Page Topic] | [Brand Name].
So, “About” becomes “About Our Team | 216digital” and “Pricing” becomes “Website Accessibility Pricing | 216digital.”

It’s easy to see how small tweaks can have a big payoff.

How to Improve Your Titles—Step by Step

Here’s a quick plan to help you get your titles in shape:

Audit Your Site

Use automated tools to spot missing, duplicate, or unusually long titles. But don’t stop there—manual review is key to catching vague or misleading language that tools might miss.

Apply a Simple Template

Keep it consistent across your site: “[Page Topic] | [Brand]” works for most needs and helps build recognition.

Loop in Your Team

Content creators, developers, designers, and SEO specialists should all care about good descriptive page titles. Make it a shared goal—not an afterthought.

Add it to Your Checklist

Whether you’re launching a new blog post, updating a product page, or doing a site redesign, reviewing the title tag should be part of the process every time.

The Risks of Getting It Wrong

Ignoring this part of accessibility can lead to bigger problems. WCAG 2.4.2 is part of ADA compliance, and missing or misleading titles are often among the first things flagged in accessibility audits. If you’re not in compliance, you could be vulnerable to lawsuits—and nobody wants that.

But beyond legal risk, failing to use descriptive page titles sends the wrong message. It suggests your site wasn’t built with every user in mind. And that hurts brand trust more than you might think.

Final Thoughts: Titles That Work for Everyone

It’s easy to overlook something as small as a page title. But when you take a step back, you’ll see that descriptive page titles affect every part of your site—from how users find you, to how they feel while browsing, to whether they come back at all.

This one fix can make your site more usable, more discoverable, and more inclusive—without blowing up your workflow or budget. That’s what we call a smart move.

Ready to Take Action?

Want help reviewing your site for accessibility wins like this one? Schedule an ADA briefing with 216digital. We’ll show you how small changes like descriptive page titles can lead to big improvements in compliance, usability, and user trust—no pressure, no hard sell.

Let’s build a web that works for everyone—starting with the title.
Greg McNeil

June 18, 2025

How-to Guides

Accessibility, How-to, Page Titles, WCAG, WCAG Compliance, Web Accessibility, web developers, web development, Website Accessibility
Web Accessibility for Retailers Under Legal Fire
If you’re running an online retail business, digital accessibility might not be the first thing on your to-do list—but it needs to be. In today’s eCommerce landscape, accessibility for retailers isn’t just a best practice—it’s a legal requirement and a smart business move.

Retail websites are complex, dynamic, and frequently updated, which makes them especially vulnerable to accessibility issues. And as more people rely on online shopping to meet daily needs, the stakes are higher than ever. Lawsuits are on the rise, but more importantly, so is the expectation that your site works for everyone.

Product carousels, filters, multi-step checkout processes, popups, modals, and embedded third-party tools all add complexity and make accessibility more difficult.

Why Web Accessibility for Retailers Matters

Retailers have become one of the biggest targets for digital accessibility lawsuits. In fact, in 2024 alone, 77% of all web accessibility lawsuits in the U.S. targeted online retailers—making the industry the most litigated digital sector. These lawsuits aren’t just targeting Fortune 500 brands; regional and mid-market businesses are facing legal action at an increasing rate.

There are several reasons for this:

Retail Websites are Dynamic And Complex

They’re filled with product carousels, filters, multi-step checkout processes, popups, modals, and embedded third-party tools—all of which can be difficult to make accessible. Without proper structure, markup, and ARIA attributes, these elements can become unusable for people relying on screen readers or keyboard navigation.

eCommerce Sites Are Constantly Updated

Product pages change, promotions rotate, and new features are added regularly. These updates often introduce new accessibility problems—especially when not reviewed with accessibility in mind.

Online Shopping is Essential

It’s no longer a luxury; it’s how millions of people access everyday goods and services. If a website prevents someone from completing a purchase due to an accessibility barrier, it becomes a civil rights issue—legally and ethically.

Demand Letters Are Widespread

Each year, hundreds of thousands of demand letters are sent to businesses for digital accessibility violations. These letters signal that a company is excluding people with disabilities, and the reputational damage can be immediate.

Legal and Technical Web Accessibility for Retailers

Title III of the Americans with Disabilities Act (ADA)requires U.S. retailers to ensure accessibility for people with disabilities in all places of public accommodation. In today’s digital world, the courts and the Department of Justice (DOJ) have made it clear: this requirement also applies to websites—especially those that sell goods and services to the public.

Courts and plaintiffs use the Web Content Accessibility Guidelines (WCAG) as the standard for compliance in nearly all accessibility-related lawsuits. The DOJ reaffirmed this approach in 2024, solidifying WCAG as the benchmark for evaluating whether a website is accessible.

The Four Golden Rules of Accessibility: POUR

At the heart of WCAG are four key principles known by the acronym POUR: Perceivable, Operable, Understandable, and Robust. These form the foundation for accessible digital experiences and help ensure your website works for everyone.
- Perceivable – Users must be able to identify and interact with content. This includes providing text alternatives for images, captions for videos, and other sensory accommodations.
- Operable – The site must support navigation with a keyboard, screen reader, or other assistive tools—without relying solely on a mouse.
- Understandable – Information and functionality should be easy to comprehend and behave in expected ways to avoid confusion.
- Robust – Content must be compatible with a wide range of current and future assistive technologies, such as screen readers or voice commands.
And it’s not just your website. These principles should also extend to digital documents, confirmation emails, customer service interactions, and anything else a user might engage with online.

Common Pitfalls on Retail Websites

Retail sites face some of the most complex accessibility challenges. Here are a few issues that often trigger lawsuits:
- Unlabeled or mislabeled form fields that prevent screen reader users from checking out.
- Broken keyboard navigation makes it impossible for users with motor impairments to complete transactions.
- Missing alt text on product images.
- Low color contrast between text and backgrounds.
- Non-dismissable modals or popups that trap users.
- Checkout flows that break when even one component isn’t accessible.
These barriers frequently appear when using templates, third-party plugins, or custom JavaScript that hasn’t been accessibility-tested. They can completely disrupt the buying experience for users who depend on assistive technologies. Web accessibility for retailers requires a consistent and intentional approach to prevent these obstacles from resurfacing.

What Happens If You’re Sued

Most lawsuits begin with a demand letter—often asking for immediate remediation and a financial settlement. If ignored, this can escalate into a federal lawsuit under the ADA or state-level laws like California’s Unruh Civil Rights Act, which allows for additional penalties.

Settlements may cover remediation costs and legal fees, but the real damage is often reputational—especially when exclusion of disabled users becomes public knowledge.

Even if your business wins the case, legal defense costs are high. And if your site remains non-compliant, you may be targeted again. With web accessibility for retailers, prevention is significantly less costly than a reactive legal defense.

A Proactive Plan for Retailers

Accessibility isn’t a one-time fix. It’s an ongoing strategy. Here’s how to start with accessibility for retailers:

1. Start with an Audit

Use automated tools like Lighthouse or WAVE for a quick scan. But don’t stop there—manual testing is essential for identifying real-world usability barriers.

2. Fix Key Areas First

Prioritize your homepage, product pages, cart, and checkout. Make sure form fields are labeled, keyboard navigation works, and screen readers can read your content.

3. Address Dynamic Elements

Focus on complex components—like popups, modals, filters, and third-party integrations—that often create the biggest challenges. Use semantic markup and ARIA attributes to support assistive tech.

4. Monitor Continuously

Your site changes frequently. Build accessibility checks into your update process so new features don’t break usability, or use a monitoring service like a11y.Radar.

5. Train Your Team

Give your developers, content editors, and marketing teams the knowledge they need to create inclusive content from the start.

6. Consider Outside Help

Accessibility is nuanced. A qualified team can help you get it right—and keep it that way.

Retailers: Don’t Let Accessibility Be an Afterthought

Web accessibility for retailers is no longer optional. It’s central to building a sustainable, inclusive, and legally safe business. In a digital environment where over 30% of the top 500 eCommerce retailers were sued last year, doing nothing is no longer a risk—it’s a liability.

But there’s a real upside, too. Accessibility leads to better experiences, broader audiences, stronger SEO, and a more trusted brand.

Start now. Audit your site. Fix the gaps. Train your team. Partner with experts. Turn accessibility from a compliance headache into a strategic advantage.

Need Help Making Your Retail Site Accessible?

216digital offers full audits, real-world testing, and proactive monitoring to ensure your site meets WCAG standards and stays lawsuit-resistant. Let’s make your eCommerce experience inclusive—and legally safe—from day one.
Greg McNeil

June 11, 2025

Legal Compliance

Accessibility, ADA Compliance, ADA Lawsuit, ecommerce website, Retail, WCAG, Web Accessibility, Website Accessibility
WordPress Accessibility: Common Pitfalls & Fixes
WordPress gives developers a head start with accessibility—but it’s just that: a start. While the platform includes solid foundations like semantic markup and keyboard-friendly admin features, building an experience that works for everyone still requires thoughtful decisions on our part. As developers, we’re in a unique position to go beyond the basics, spotting the small oversights that can create big barriers for users.

In this guide, we’ll walk through some of the most common accessibility missteps we see in WordPress projects—along with practical fixes you can implement right away. Whether you’re refactoring an old theme or launching something new, these insights are meant to help you create experiences that are not just compliant, but genuinely inclusive.

Misuse of Heading Structures for Visual Styling

It’s easy to reach for <h2> or <h3> tags to style text because they’re built into most WordPress themes with bold and larger font sizes. But when headings are used purely for visual emphasis—not structure—you end up distorting the page’s semantic outline.

Why It Matters

Screen reader users often rely on heading navigation to scan and jump between sections. If headings are skipped, out of order, or misused, the page becomes harder to understand, and key content may get missed entirely.

How to Fix It
- Use CSS for Styling: Apply styles using classes or inline styles, not heading tags. In Gutenberg, you can use blocks with custom styles or reusable blocks instead of jumping heading levels.
- Follow a Logical Heading Hierarchy: Begin with one <h1> per page (usually the title), then use <h2> for top-level sections, <h3> for subsections, and so on.
- Audit Your Work: Use tools like WAVE or the Google Lighthouse Accessibility Report to evaluate your heading structure and flag potential misuses before they go live.
Overreliance on Theme Defaults for Color Contrast

Many developers trust their WordPress theme’s default color scheme to do the heavy lifting—but while a palette may look good visually, it doesn’t mean it’s accessible. Default colors often fail to meetWCAG 2.1 AA standards, especially for body text and buttons.

Accessibility Risk

Poor color contrast is a major barrier for users with low vision or color blindness. If your text blends into the background, you’re excluding readers—sometimes without realizing it.

Practical Fixes
- Test Contrast Ratios: Use WebAIM’s Contrast Checker or the Color Contrast Analyzer to validate text against its background.
- Override Theme Defaults: Most modern themes offer customization options via the Customizer or Full Site Editing. Make small adjustments—lighten text, darken backgrounds—to meet or exceed the 4.5:1 minimum contrast ratio.
- Offer User Controls: Consider giving users the ability to switch to high-contrast mode with plugins like “WP Accessibility.” This gives more control to your users while improving inclusivity.
Improper List Markup Practices

It’s not unusual to see developers create the appearance of a list using <div> tags, line breaks, or other non-semantic methods—especially in custom blocks or page builders commonly used in WordPress.

Why It’s a Problem

Screen readers rely on semantic tags like <ul>, <ol>, and <li> to announce that a list exists, how many items are in it, and how items relate to each other. Without this structure, users lose context.

Best Practices
- Use Native List Markup: If it’s a list—code it as a list. Use <ul> for unordered lists and <ol> for ordered ones. Wrap each list item in <li>.
- Handle Nesting Thoughtfully: For sub-lists, nest another <ul> or <ol> inside an <li>. Screen readers will announce the nested structure properly.
- Test Your Output: Run accessibility audits or inspect the DOM to ensure list structures are coded semantically, especially when using custom Gutenberg blocks or page builders.
Neglecting Contextual Relevance in Alt Text

WordPress auto-generates alt text from image file names if authors don’t supply one. That’s how you end up with images labeled “IMG_4829.jpg”—which isn’t helpful to anyone.

Why It Matters

Alt text should describe why the image is there, not just what it looks like. If the image provides important context, instructions, or emotion, a generic label fails users who rely on screen readers.

What Developers Can Do
- Write Purpose-Driven Alt Text: If the image is showing a concept, outcome, or step in a process, describe that context directly. For example, “Screenshot of the plugin settings menu with Accessibility Mode enabled.”
- Avoid Phrases Like “Image of…” Screen readers already announce the presence of an image. Jump straight into the relevant description.
- Use Empty Alt for Decorative Images: For visuals that are purely aesthetic and add no informational value, use alt="" so assistive tech knows to skip it entirely.
Overuse and Misapplication of ARIA Attributes

ARIA is a powerful toolset—but like any tool, misuse can cause more harm than good. Adding roles and attributes without understanding their implications can break screen reader behavior or clutter the accessibility tree.

The Real Cost

Improper ARIA use can confuse assistive technologies, interfere with default behaviors, and even make components harder—not easier—to use. Overengineering is just as dangerous as under-engineering.

Smarter ARIA Use
- Favor Native HTML First: If you’re building a checkbox, <input type="checkbox"> with an associated <label> is far more reliable than using a <div> with ARIA roles and states.
- Use ARIA Only When Required: If you’re building a custom interactive widget (like a tabbed interface or menu), consult the ARIA Authoring Practices Guide. Choose correct roles and manage keyboard interactions accordingly.
- Test Your Implementation: Use screen readers like NVDA or VoiceOver to verify that ARIA is behaving as expected. Pay attention to focus, announcements, and interaction patterns.
Overlooking Keyboard Navigation and Focus Management

Many developers unintentionally design for mouse users first. But for users relying on keyboards—whether due to preference, disability, or temporary injury—keyboard accessibility is critical.

Key Accessibility Concerns
- No Visible Focus Indicators: Removing browser outlines with outline: none; without providing alternatives leaves users lost.
- Custom Components Not Keyboard-Aware: Modals, sliders, dropdowns, and carousels built from scratch often lack proper keyboard event handling and focus management.
Developer-Friendly Fixes
- Ensure Focus Visibility: Style focused elements clearly using CSS, like :focus { outline: 2px solid #000; }. Customize this to match your theme, but don’t remove it entirely.
- Handle Keyboard Events: For custom components, add keydown or keyup listeners to handle Enter, Escape, and Arrow keys appropriately. Don’t rely on click events alone.
- Do Keyboard-Only Testing: Regularly test your site using only the keyboard. Tab through each interactive element and verify focus moves logically, without skipping important controls.
What True Accessibility Looks Like in WordPress

Accessibility isn’t a checklist—it’s a mindset. When we write clean, semantic code, ensure visual clarity, and support every way a user might interact with our sites, we’re not just doing right by WCAG—we’re doing right by our users. The real goal is to build experiences that work for everyone, without assumptions about how people navigate the web.

As WordPress developers, we have powerful tools and a vibrant ecosystem at our disposal. Let’s use them with care and intention. Keep testing, stay curious, and don’t hesitate to dig deeper. And if you’re looking to strengthen your accessibility efforts, 216digital offers ADA compliance briefings tailored to development teams. We’re here to support your work—because inclusive development is better development.
Greg McNeil

June 10, 2025

How-to Guides, Legal Compliance

Accessibility, How-to, WCAG, Web Accessibility, web developers, web development, Website Accessibility, WordPress

What An Accessible PDF is—And Why the Law Cares

PDF/UA (ISO 14289): Technical Conformance

WCAG for PDFs: Publication Context and User Outcomes

How They Fit Together

Operational Definition of “Compliant”

Why PDFs Are So Often Non-compliant

What AI-powered Accessibility Tools Do Well (Today)

Where AI Still Falls Short—and Why People Still Matter

The Hybrid model for Accessible PDF Compliance

AI is Powerful, But Not a Solo Act

Why Accessibility Matters in California

Your California Web Accessibility Checklist

1. Know Your Legal Landscape

2. Identify Your Accessibility Gaps with a Web Accessibility Checklist

3. Fix Barriers and Align with WCAG 2.2 Level AA

4. Don’t Forget Privacy and Legal Disclosures

5. Plan for Ongoing Compliance

Accessibility: Not a Project, a Practice

Need Help Making Sense of It All?

Structure and Layout: Design for Navigation, Not Just Aesthetics

Image Accessibility: More Than Just Pretty Pictures

Links and Calls to Action: Clear, Clickable, Inclusive

Copywriting and Readability: Make Every Word Count

Multimedia Content: Do Not Skip the Captions

A Pre-Send Accessibility Checklist

Accessibility Is a Long Game, but Every Email Helps

What Are WCAG “Grey Areas”?

Why Ambiguity Exists—and Why That’s Okay

A Practical Framework for Resolving WCAG Grey Areas

Step 1: Start with the Source

Step 2: Analyze Real User Impact

Step 3: Test with People Who Use AT

Step 4: Phone a Friend (the Right One)

Step 5: Document Your Rationale

Common Examples, Resolved with the Framework

Reflow vs. Data Integrity (SC 1.4.10)

Link Purpose in Card Grids (SC 2.4.4)

Non-Text Contrast on Icon Buttons (SC 1.4.11)

Dark Mode and Motion Preferences

Alt Text in Dashboards

Let Strategy Guide You—Not Guesswork

The Fundamentals of Accessible UX

Accessibility vs. Usability

Visual Accessibility: Making Your Content Clear

Color and Contrast: Give Every Element a Voice

Text and Typography: Keep It Clean and Comfortable

Images and Media: Describe What Matters

Links and Structure: Build a Clear Path

Auditory Accessibility: Sound That Speaks to Everyone

Motor Accessibility: Let Everyone Navigate Their Way

Cognitive Accessibility: Make It Clear, Make It Work

Accessible Design Checklist

Accessible Design Never Clocks Out

The Federal Foundation for Digital Accessibility

Americans with Disabilities Act (ADA)

Section 508 of the Rehabilitation Act

States with Their Own Accessibility Laws

Alaska

Arizona

Arkansas

California

Colorado

Connecticut

Delaware

Georgia

Idaho

Illinois

Indiana

Iowa

Kansas

Louisiana

Maine

Maryland

Massachusetts

Michigan

Minnesota

Missouri

Montana

Nebraska

Nevada

Use `role="presentation"` or `aria-hidden="true"`