216digital.
Web Accessibility

Phase 1
Web Remediation for Lawsuit Settlement & Prevention


Phase 2
Real-World Accessibility


a11y.Radar
Ongoing Monitoring and Maintenance


Consultation & Training

Is Your Website Vulnerable to Frivolous Lawsuits?
Get a Free Web Accessibility Audit to Learn Where You Stand
Find Out Today!

Web Design & Development

Marketing

PPC Management
Google & Social Media Ads


Professional SEO
Increase Organic Search Strength

Interested in Marketing?
Speak to an Expert about marketing opportunities for your brand to cultivate support and growth online.
Contact Us

About

Blog

Contact Us
  • Ease Into Motion: Smarter Animation Accessibility

    Imagine clicking into a website and being hit with swirling graphics, sliding panels, or a bouncing button that just won’t stop. For many people, that kind of animation isn’t just annoying—it’s physically harmful. Dizziness. Nausea. Migraines. Disorientation. For users with motion sensitivity, these effects are all too common.

    As developers, we love using motion to make our interfaces feel alive. But when it comes to animation accessibility, we need to be just as thoughtful about who we’re designing for. Great UI isn’t just beautiful—it’s inclusive. And making motion safer doesn’t mean removing it altogether. It just means giving people control.

    This guide breaks down what you need to know about motion sensitivity, how to comply with the Web Content Accessibility Guidelines (WCAG), and how to build user-friendly animation for your projects using CSS, JavaScript, and real-world techniques.

    Who’s Affected by Motion—and Why It Matters

    Motion sensitivity happens when animations or transitions trigger unpleasant physical reactions. This might include nausea, vertigo, blurry vision, headaches, or even migraines. It’s especially common for people with:

    • Vestibular disorders
    • Autism spectrum disorder
    • ADHD
    • Epilepsy

    In fact, over 35% of adults experience some kind of vestibular dysfunction by age 40. That’s not a small edge case—it’s a significant part of your user base.

    The Trouble With Flashing and Distractions

    Animations can also cause cognitive overload. Users with ADHD or processing differences may find it hard to stay focused when elements are constantly moving. Looping carousels or animated background transitions can pull attention away from the main content or calls to action.

    And then there’s photosensitive epilepsy. About 3% of people with epilepsy can have seizures triggered by flashing lights—especially red-on-black or high-contrast flickers. That’s why WCAG has strict guidelines around flash frequency.

    WCAG and Animation Accessibility: What to Follow

    Before diving into the specifics, it’s important to understand that these aren’t arbitrary rules—they exist to protect people. Animation accessibility is a fundamental part of inclusive design, and these guidelines offer a framework that helps you avoid unintentional harm.

    Key Guidelines

    • 2.2.2 – Pause, Stop, Hide: Any moving content that starts automatically must have a clear way to pause or hide it, unless the motion is essential.
    • 2.3.1 – Three Flashes or Below Threshold: Avoid flashing more than 3 times per second.
    • 2.3.3 – Animation from Interactions: If your animation happens because someone clicked, scrolled, or hovered—it still needs to be safe and optional.

    How to Apply These Guidelines

    • Don’t loop animations forever.
    • Offer controls to pause or stop motion.
    • Never rely on animation alone to convey important info—back it up with text or icons.

    Animation accessibility is about making sure motion adds value without harm.

    Using CSS to Respect Motion Preferences

    What Is @prefers-reduced-motion?

    This media query checks whether a user has asked for less motion in their operating system:

    @media (prefers-reduced-motion: reduce) {
      * {
        animation: none !important;
        transition: none !important;
      }
    }

    If users toggle Reduce motion in macOS, iOS, Windows, Android, or Linux, they’ll instantly get a calmer experience.

    Design Strategies

    • Remove parallax scroll and large translations.
    • Swap animated GIFs with a static frame or CSS background-image.
    • Tone down fades and slides—transitions shorter than 250 ms are usually fine.
    • Provide fallbacks that still communicate state changes (e.g., use color or underline instead of a shake animation to signal “invalid input”).

    Giving Users Control With JavaScript

    Even if someone’s system doesn’t request reduced motion, they should still have a choice. Here’s a simple example:

    <button id="toggle-motion">Toggle motion</button>
    <script>
      document.getElementById('toggle-motion').addEventListener('click', () => {
        document.body.classList.toggle('reduce-motion');
        localStorage.setItem('reduceMotion', document.body.classList.contains('reduce-motion'));
      });
      // Persist preference between visits
      if (localStorage.getItem('reduceMotion') === 'true') {
        document.body.classList.add('reduce-motion');
      }
    </script>

    Then, in your CSS:

    .reduce-motion * {
      animation: none !important;
      transition: none !important;
    }

    Let users decide what works for them. Animation accessibility is about empowerment.

    Pause on Hover or Interaction

    You can also pause motion when someone hovers or focuses:

    @keyframes spin { to { transform: rotate(360deg); } }
    .loader {
      animation: spin 1.5s linear infinite;
    }
    .loader:hover,
    .loader:focus-visible {
      animation-play-state: paused;
    }

    This small touch gives users breathing room without turning off design completely.

    Progressive Enhancement: Accessibility First

    Start safe, layer on flair. Treat the reduced‑motion version as the baseline and add richer animation only if the user hasn’t opted out. This progressive‑enhancement approach prevents regressions—future devs won’t accidentally forget animation accessibility because the “accessible” state is the default.

    /* Base styles: minimal motion */
    .button {
      transition: background-color 150ms ease-in;
    }
    /* Only animate if motion is OK */
    @media (prefers-reduced-motion: no-preference) {
      .button:hover {
        transform: translateY(-2px);
      }
    }

    You can combine media features to catch multiple needs:

    @media (prefers-reduced-motion: reduce) and (prefers-contrast: high) {
      /* Ultra-accessible styles */
    }

    Performance & UX Benefits of Reducing Motion

    • Battery & CPU savings on low‑power devices (less layout thrashing, fewer GPU layers).
    • A cleaner interface helps all users focus on content and calls to action.
    • Lower cognitive load means faster task success—key in e‑commerce checkouts or complex forms.

    When stakeholders balk at “turning off the fun stuff,” show how reduced motion often speeds up perceived performance and increases conversions.

    Testing for Motion Accessibility

    You don’t need to eliminate all animation—you just need to know when and where it matters.

    Use Tools Like:

    • PEAT (Photosensitive Epilepsy Analysis Tool): Checks flash frequency and contrast against seizure‑safe limits.
    • WAVE: Flags continuous animations and missing pause controls.
    • Google Lighthouse: Includes audits for @prefers-reduced-motion.
    • Manual Device Testing: Turn on Reduce motion in the OS and navigate your site—does anything still move?

    Combine automated scans with human walkthroughs—especially for pages heavy on micro‑interactions. Ask testers with vestibular or cognitive disabilities for feedback if possible.

    Responsible Animation Is Good UX

    Animation accessibility isn’t about banning creativity. It’s about respecting user choice, following WCAG, and providing explicit opt‑ins or opt‑outs. When you honor @prefers-reduced-motion, add site‑level toggles, and keep flashes below seizure thresholds, you deliver the best of both worlds: engaging motion for those who love it and a calm, usable experience for those who don’t.

    Need a quick check on your motion strategy—or a deep dive into ADA compliance across your entire front end? Schedule a personalized accessibility briefing with the team at 216digital. We’ll help you uncover hidden risks, refine your animation patterns, and build inclusive experiences that look amazing and feel great for everyone.

    Let’s create motion that moves people—in the right way.

    Greg McNeil

    May 21, 2025
    How-to Guides, WCAG Compliance
    Accessibility, animation, How-to, motion, WCAG, Web Accessibility
  • Color Contrast That Pops: Accessibility in Every Shade

    Color is one of the most powerful tools in a designer’s toolkit—but without the right contrast, even the most beautiful interface can become unreadable. For users with low vision or color blindness, low contrast isn’t just inconvenient—it can make content completely inaccessible. And while most developers know the basics of accessible design, color contrast often slips through the cracks when brand guidelines or fast-moving deadlines take over.

    This article isn’t a beginner’s primer—it’s a hands-on guide for developers who already know what WCAG is but want smarter, more practical ways to apply color contrast in real projects. From testing tools to design techniques to working with brand colors, we’ll cover how to create experiences that look sharp, function well, and work for everyone.

    Understanding Color Perception and Its Impact on Accessibility

    To build truly inclusive designs, it helps to understand how users perceive color in the first place. The human eye detects color based on hue (the type of color), saturation (how strong it appears), and lightness (how bright or dark it is). This is where the HSL (Hue, Saturation, Lightness) model becomes useful—it mirrors how people actually experience color and helps designers assess contrast more accurately.

    Now, pair that with accessibility data. Around 300 million people worldwide live with color blindness, and another 253 million have low vision. That’s not a small edge case—it’s a significant portion of your audience. For these users, poor color contrast can turn buttons, labels, and links into frustrating puzzles. A green button on a gray background might seem fine to a fully sighted user, but it can disappear entirely for someone with red-green color deficiency.

    By considering how color vision deficiencies affect perception, developers can make smarter choices—ones that improve usability for everyone without drastically changing their design.

    WCAG Guidelines on Color Contrast

    To guide these decisions, the Web Content Accessibility Guidelines (WCAG) lay out specific requirements. For Level AA compliance, normal text must have a color contrast ratio of at least 4.5:1. Large text—defined as 18pt or 14pt bold—can meet a slightly lower bar of 3:1. If you’re aiming for AAA (which is more stringent), the numbers jump to 7:1 and 4.5:1, respectively.

    But contrast isn’t just about text. It also applies to non-text elements like icons, buttons, graphs, and interactive controls. These need to be distinguishable too, especially for users navigating with limited vision or screen magnifiers.

    That said, not everything falls under these rules. Logos and purely decorative graphics are exempt. This makes room for brand expression, but it also challenges teams to strike the right balance: How do you honor brand colors without sacrificing clarity? The good news is that small adjustments can go a long way.

    Tools and Techniques for Evaluating Color Contrast

    So how do you check if your contrast choices meet the mark? Fortunately, there’s a wide range of tools designed to make this easy—no guesswork required.

    Online contrast checkers are a great place to start:

    • WebAIM Contrast Checker is fast and simple—just plug in your colors and get a pass/fail result.
    • TPGi’s Colour Contrast Analyser lets you test live screen elements with an eyedropper tool.
    • Coolors Contrast Checker is especially helpful when working within a palette—it gives instant feedback as you test combinations.

    To take your testing further, browser extensions can simulate what your site looks like to users with different types of color blindness:

    • Colorblindly and Dalton show you how your design holds up for users with vision deficiencies.
    • Color Enhancer for Chrome allows you to customize and tweak colors directly in the browser.

    For those who prefer working within browser developer tools, Chrome DevTools offers built-in accessibility checks. You can inspect elements, see real-time color contrast ratios, and even simulate vision impairments. Pair that with media queries like @prefers-color-scheme or @prefers-contrast, and you’ll be ready to serve more inclusive experiences automatically—based on a user’s own system settings.

    Best Practices for Implementing Accessible Color Contrast

    Once you’ve got the right tools, the next step is applying best practices to your design and development process.

    Start by designing with accessibility in mind from the beginning. Don’t rely on color alone to convey meaning. Pair colors with icons, patterns, or text labels—so if a user can’t see the red “error” outline, they can still read the “required field” message.

    Next, build testing into your workflow. Just like you check for responsive breakpoints or load time, checking for color contrast should be routine. Use automated tests, then follow up with human feedback to catch edge cases tools might miss.

    Also, remember to document your choices. A clear, shared record of approved color combinations and contrast ratios will help your team stay consistent across projects. Whether it’s a design system in Figma or internal guidelines in Notion, this documentation keeps accessibility top of mind for everyone involved.

    The Role of Browser Extensions in User Accessibility

    While developers work hard to build accessible designs, many users also rely on their own tools to improve visibility. Browser extensions like Colorblindly and Dalton allow users to adjust or simulate colors in a way that meets their personal needs.

    It’s important to remember that just because users can adjust colors, doesn’t mean developers shouldn’t strive for accessible defaults. By ensuring strong color contrast from the start, you make life easier for everyone—and reduce the need for users to rely on workarounds.

    Plus, by understanding how these tools work, developers can better anticipate what users experience and design with greater empathy.

    Balancing Brand Identity with Accessibility

    Now comes the tough part—color contrast often butts heads with brand design. Changing a brand’s color palette can feel like touching sacred ground. But here’s the thing: contrast issues can usually be fixed with minor adjustments.

    Sometimes it’s as easy as tweaking brightness or adding a subtle border. Instead of throwing out your palette, consider enhancing it. You might slightly darken a background color, lighten the text, or add supporting visuals that boost readability. Your core colors stay intact—just optimized for accessibility.

    And don’t worry—accessibility lawsuits are rarely about brand color alone. They’re about whether people can actually use your site. Keeping that goal in focus will help guide the right compromises.

    Final Shades of Wisdom

    At its core, color contrast is about communication. It makes your message easier to read, your interface easier to use, and your site more welcoming to everyone—regardless of how they see the world.

    With a solid grasp of the WCAG guidelines, the right tools in your toolkit, and smart design strategies, it’s entirely possible to meet accessibility goals without sacrificing visual style. Make contrast checks part of your process, revisit your palette with intention, and bring your team along with documentation and testing habits.

    And if you’re not sure where to start or want a second opinion, schedule a quick ADA compliance briefing with 216digital. We’ll help you uncover any color contrast issues hiding in plain sight—and map out a path toward a more inclusive, accessible web.

    Greg McNeil

    May 20, 2025
    How-to Guides, WCAG Compliance
    Accessibility, color contrast, WCAG, WCAG 2.1, WCAG Compliance, WCAG conformance, Web Accessibility
  • Mobile Form Accessibility: Don’t Leave Users Behind

    Think about how often you reach for your phone during the day—checking messages, ordering lunch, paying bills, or dashing through a quick form. Now picture each tap, swipe, and pinch becoming a chore because the form wasn’t built with you in mind.Unfortunately, that’s exactly what happens when mobile form accessibility is overlooked for users who rely on screen readers. A few missteps can turn routine tasks into roadblocks. Fixing those gaps keeps everyone’s day moving smoothly—and yes, it makes your product look a whole lot better, too.

    As developers, we’re in a sweet spot to clear those hurdles. Instead of ticking boxes on an accessibility checklist, let’s swap ideas and code snippets that make forms genuinely easy to use. Think of this guide as one dev handing a helpful note to another—no lecture, just practical tips that work in the real world.

    The Real Challenge of Mobile Accessibility

    Roughly 90 percent of screen-reader users browse the web primarily on phones. Yet mobile form accessibility still slips past many reviews. Small oversights—poorly labeled fields, keyboards that bury inputs—can shut people out of shopping carts or log-in screens. Sure, standards like WCAG 2.2 and the European Accessibility Act (EAA) are important, but the endgame is simpler: make everyday online chores painless for everyone.

    Common Barriers with Mobile Form Accessibility

    So, what trips us up when we build (or tune-up) a mobile form? Here are the heavy hitters that screen-reader users run into—and how to dodge them.

    Invisible Text Fields

    Fields can look fine on the surface yet be missing their behind-the-scenes links. When labels and inputs aren’t wired together in code, a screen reader can’t announce them—and the user can’t fill them out.

    Quick fix:

    <label for="email">Email Address</label>
    <input type="email" id="email" name="email">

    Skip placeholder-only labels or fancy <div> stand-ins. Semantic HTML or precise ARIA labels keep everything on the radar.

    Keyboard Blocking Form Fields

    We’ve all watched the on-screen keyboard sail up and hide half the page. For screen-reader users, that’s a full stop.

    A simple JavaScript nudge:

    window.addEventListener('resize', () => {
      document.activeElement.scrollIntoView({ behavior: 'smooth' });
    });

    Let the layout flex so active inputs stay visible, and avoid fixed-position elements that trap content under the keyboard.

    Unexpected Focus Shifts

    Nothing’s more disorienting than the cursor jumping to a random field—or disappearing altogether—mid-form. Auto-focus tricks or live-updating content can make matters worse.

    Rules of thumb:

    • Only auto-focus when it truly helps.
    • Deep dynamic changes to a minimum while someone is typing.
    • Always leave users sure of their spot in the form.

    Practical Steps to Improve Mobile Form Accessibility

    Now that we’ve walked through the most common pitfalls, let’s talk solutions. Fixing mobile form accessibility doesn’t always mean starting from scratch—small, thoughtful adjustments can make a big difference. The goal here isn’t perfection on paper; it’s creating an experience that works reliably for real people on real devices. Below are key practices that help bring your forms up to speed.

    Proper Labeling Is Crucial

    Each form field should have a clear, programmatic label. Screen readers depend on these labels to describe inputs accurately. Relying solely on visual styling or placeholder text often leads to confusion or missed information. Whenever possible, use semantic HTML elements like <label> to ensure clarity and consistency.

    Design with Keyboard Visibility in Mind

    If the keyboard hides your input field, you’re forcing users to guess where they are. This isn’t just frustrating—it can stop someone from completing the form entirely. Design responsively to account for different screen sizes and input methods. Test with your device’s keyboard visible and active. Elements should remain fully accessible without awkward scrolling or zooming.

    Maintain a Logical Navigation Order

    Users often navigate mobile forms using swipe gestures or the Tab key with external keyboards. If your form jumps from field to field out of order—or skips elements entirely—you’ve just introduced an unnecessary obstacle. Use logical DOM ordering and avoid layout tricks that confuse the natural tab order.

    Use Semantic HTML First, ARIA Thoughtfully

    Native HTML elements offer built-in accessibility that ARIA can’t always replicate. For example, a standard <button> is more robust and predictable than a <div> with role= "button". Reach for ARIA only when native elements fall short, and always test thoroughly to ensure you’re enhancing, not complicating, the experience.

    Real-Device Testing Is Essential

    It’s tempting to rely on automated audits or browser tools alone, but they can’t catch everything. Use screen readers like VoiceOver (iOS) or TalkBack (Android) on physical devices to experience your form the way your users do. Listen closely—do labels get announced properly? Does focus land where it should? Manual testing reveals the gaps no automated tool can catch.

    Don’t Forget About Error Messaging

    Accessible forms don’t just help users fill in the blanks—they help users recover from mistakes. Validation errors should be announced clearly and immediately after the user interacts with a field. Use ARIA live regions or focus management to draw attention to problems, and provide guidance that’s easy to understand and act on.

    Support Multiple Interaction Modes

    Not everyone uses a touchscreen the same way. Some rely on voice control, others on external keyboards or assistive switch devices. Design and test with multiple interaction styles in mind. What works great with a finger tap might break down when using voice commands or swiping with a screen reader.

    Taken together, these practices do more than check boxes—they create forms that feel intuitive, responsive, and respectful to all users. And as accessibility standards continue to evolve, these foundational steps help future-proof your code while building trust with your audience.

    Building Mobile Form Accessibility Into Your Workflow

    As developers, we have a real opportunity to do something meaningful. We can move past the minimum and start building digital experiences that work for everyone, not just the majority. It doesn’t require magic—just intention, testing, and a willingness to see the interface through someone else’s eyes. 

    If you’re serious about creating mobile forms that aren’t just technically compliant but actually usable for every user, it’s time to dig deeper. Start testing, keep learning, and if you want an experienced partner to help guide the process, schedule an ADA briefing with 216digital. We’re here to support your journey toward smarter, kinder, and more inclusive design—one tap at a time.

    Greg McNeil

    May 16, 2025
    How-to Guides
    Accessibility, accessible forms, forms, How-to, mobile accessibility, Web Accessibility, Website Accessibility
  • aria-label vs aria-labelledby: When and How to Use Each

    As developers, we know every interactive element—buttons, dialogs, inputs—needs an accessible name. Good semantic HTML handles this automatically. But let’s face it, our apps get complicated. Sometimes, buttons only show icons, dialogs pull their titles from external components, or complex widgets break the neat semantic model. That’s where ARIA attributes come in. Specifically, aria-label and aria-labelledby help us provide clear, 

    screen-reader-friendly names. But they aren’t interchangeable. Knowing when to use each can save you debugging headaches down the line.

    The Common Ground

    First off, let’s review their similarities. Both aria-label and aria-labelledby override native labels provided by HTML. Both directly influence what assistive technologies like screen readers announce. Ideally, though, these ARIA attributes should be your fallback, not the go-to solution—semantic HTML labels are always best.

    Quick side note: If you’re ever curious about the details, check out the Accessible Name Computation Algorithm.

    Using aria-label: Direct and Hidden

    aria-label lets you set an accessible name directly with a string—no extra DOM needed. Here’s a simple example you’ve probably seen before:

    <button aria-label="Search">
      <svg aria-hidden="true" focusable="false">...</svg>
    </button>

    Perfect for icon buttons or elements that don’t have visible labels. But there’s a catch:

    • It’s invisible to sighted users. If your visual UI doesn’t clearly indicate the button’s purpose, this can confuse people.
    • It’s static and won’t automatically update with dynamic content changes.
    • Localization is manual—you need to integrate these labels into your internationalization setup.

    Use aria-label when simplicity outweighs these drawbacks—like icon-only buttons that stay consistent across languages.

    aria-labelledby: Harness Visible Content

    aria-labelledby points directly to visible content already on the page to build the accessible name. This is super helpful for complex widgets or dialogs:

    <div role="dialog" aria-labelledby="dialog-title">
      <h2 id="dialog-title">Settings</h2>
      <!-- More dialog content -->
    </div>

    This is great because:

    • Updates to referenced elements automatically update the accessible name—handy for localization or dynamic UI changes.
    • You can reference multiple IDs to build richer, descriptive names.

    The downside? It requires stable IDs. Reference a missing ID, and your screen reader users will hear nothing—a silent fail you won’t catch easily without testing.

    Picking the Right Attribute

    Choosing between these two attributes boils down to visibility and localization:

    • Visible text already on screen? Use aria-labelledby.
    • Icon-only or hidden label? Use aria-label.
    • Multiple languages or dynamic content? Lean heavily towards aria-labelledby.

    Following these simple guidelines can help keep your UI accessible and your codebase clean.

    Common Mistakes (And How to Dodge Them)

    Let’s get real: we’ve all made these mistakes:

    1. Using both attributes at once: Screen readers only honor aria-labelledby. The leftover aria-label just confuses whoever touches your code next.
    2. Referencing IDs that don’t exist: Silent errors are the worst. Double-check your references with automated tools like axe-core.
    3. Static English aria-labels on multilingual sites: Always leverage your translation pipeline or use aria-labelledby with translated DOM elements.

    Quick example: Imagine a delete button labeled with aria-label="Delete" in English. When your app gets translated into Spanish, this button label stays stuck in English. Switching to aria-labelledby referencing a translated element solves it instantly.

    Performance and Maintenance Tips

    In frameworks like React or Vue, manage your DOM carefully. Always ensure referenced elements exist in the DOM before referencing components mount. Add automated accessibility checks (like Lighthouse) into your CI/CD setup. They’ll quickly catch misconfigured labels and help you maintain consistent accessibility.

    Advanced Label Composition

    Need more detail? Stack IDs with aria-labelledby:

    <span id="action">Confirm</span>
    <span id="item">your subscription</span>
    <button aria-labelledby="action item">...</button>

    Now the screen reader clearly announces, “Confirm your subscription.”

    Dynamic content? Even simpler:

    const statusLabel = document.getElementById("status");
    statusLabel.textContent = isExpired ? "Expired" : "Active";
    // aria-labelledby references statusLabel automatically

    This dynamic updating is invaluable for reactive or state-driven UI.

    Testing Your Accessible Names

    Don’t skip manual checks. Fire up VoiceOver, NVDA, or even JAWS and tab through your components the way real users do. Navigate end‑to‑end, listen for odd announcements, and confirm the focus order feels right. Then pair those spot checks with automated tools in CI so labeling issues get fixed long before code ships.

    Wrapping Up: Making Strategic Choices

    Understanding when to use aria-label versus aria-labelledby might seem minor, but it significantly impacts users’ experience. Choose aria-label for simplicity and directness, especially on icon-driven interfaces. Go with aria-labelledby when leveraging visible, dynamic, or localized content.

    Remember, accessibility is about making your interfaces clear for everyone, not just users relying on assistive tech. The strategic use of these attributes ensures your app feels polished and intuitive.

    Need a quick gut‑check? Schedule an ADA briefing with 216digital. We’ll walk through your codebase together and make sure every label—and the rest of your accessibility stack—hits the mark.

    Greg McNeil

    May 9, 2025
    How-to Guides
    Accessibility, ARIA, aria-label, Web Accessibility, web developers, web development
  • Accessible Accordion vs Disclosure: Dev Best Practices

    Disclosures and accordions show up all over the place—FAQs, menus, settings panels—you name it. They seem simple enough, right? But making sure they actually work for everyone takes more than just toggling some content and calling it a day.

    If you’ve ever wondered when to use <details> versus building an accordion with buttons and ARIA, or how to keep screen reader users from getting lost in a sea of hidden panels, you’re not alone. This guide breaks it all down—what to use, when to use it, and how to build a truly accessible accordion without overcomplicating the code.

    What Are Disclosure and Accordion Widgets?

    Disclosure Widgets: Simple, Native, and Often Overlooked

    Disclosures—also known as show/hide widgets—are ideal for toggling a single section of content. Think expandable FAQs or inline help that doesn’t clutter the UI by default.

    Here’s a basic example using semantic HTML:

    <details>
      <summary>Need more info?</summary>
      <p>Here are more details you might find useful.</p>
    </details>

    This pattern is fully native and built into the browser, which means it comes with keyboard support and screen reader compatibility right out of the box. You also get the open attribute, which allows you to control whether the content is expanded by default.

    The main advantage here is simplicity—no JavaScript needed, and fewer chances to introduce accessibility issues.

    Accordion Widgets: More Complex, More Control

    An accessible accordion expands on the idea of disclosure by managing multiple content panels. In most implementations, only one section is open at a time, helping users stay focused and reducing cognitive overload.

    You can build an accordion using multiple <details> elements, but if you want to control behavior more precisely—like closing other panels when one opens—you’ll need JavaScript.

    Here’s what a minimal HTML-only version might look like:

    <details name="accordion">
      <summary>Step 1</summary>
      <p>Instructions for step one.</p>
    </details>

    But to meet WCAG standards for a true accessible accordion, you’ll need to manage keyboard navigation, state indicators, and focus behavior—topics we’ll cover next.

    Accessibility Considerations Developers Must Prioritize

    Keyboard Navigation That Works for Everyone

    An accessible accordion must support meaningful keyboard interactions. Here’s what users expect:

    • Tab and Shift + Tab to move between interactive elements.
    • Enter or Space to toggle a section open or closed.
    • Arrow Up/Down or Home/End to move between accordion headers in more advanced versions.

    Missing any of these can make your component unusable for keyboard users. The WAI-ARIA Authoring Practices offer detailed guidance on accordion interaction patterns—worth bookmarking for reference.

    Use Semantic Elements—Always

    If there’s one golden rule, it’s this: never sacrifice semantics for styling.

    That means:

    • Use <button> for interactive triggers—not <div>, <span>, or anchor tags without href.
    • If you’re toggling visibility, it’s a button, not a link.
    • Ensure that elements behave as users (and assistive technologies) expect.

    Using semantic elements is one of the most effective ways to ensure your accessible accordion behaves predictably across screen readers and input types.

    Add ARIA Where Needed, Not Everywhere

    ARIA should enhance native HTML—not replace it. But when you’re building a custom accordion in JavaScript, ARIA becomes essential for communicating component state.

    Here’s a basic implementation:

    <button aria-expanded="false" aria-controls="info">More Info</button>
    <div id="info" hidden>
      <p>Here’s the additional info.</p>
    </div>
    
    const btn = document.querySelector('button');
    const content = document.getElementById('info');
    btn.addEventListener('click', () => {
      const expanded = btn.getAttribute('aria-expanded') === 'true';
      btn.setAttribute('aria-expanded', String(!expanded));
      content.hidden = expanded;
    });

    This ensures screen readers can track whether content is visible or hidden, creating a seamless experience for all users.

    Common Accessibility Mistakes (and How to Fix Them)

    Even seasoned devs slip up. Here are a few common issues that can break accessibility—and how to address them:

    MistakeProblemSolution
    Non-focusable triggers<div>s with onclick don’t work for keyboard usersUse <button> or add tabindex="0"
    Links used instead of buttons<a> without href doesn’t convey intentReplace with semantic <button>
    Missing state feedbackScreen readers can’t detect if content is expandedDynamically update aria-expanded
    Focusable elements in hidden contentUsers tab into content they can’t seeUse hidden or display: none correctly

    Most of these issues stem from skipping semantic HTML or relying too heavily on JavaScript without proper state management. An accessible accordion avoids these pitfalls by focusing on clarity, intent, and interaction feedback.

    Best Practices for Developers

    Building an accessible accordion that holds up in the real world means going beyond code snippets. Here’s what to keep in mind:

    Start with Progressive Enhancement

    Whenever possible, begin with HTML <details> and <summary>. They’re accessible by default and supported in all major browsers. Use JavaScript only when additional behavior—like limiting panels to one open at a time—is truly needed.

    Prioritize Focus Visibility

    An accordion is only as accessible as its focus states. Make sure every interactive element has a visible focus indicator, and don’t override :focus-visible in your CSS. This isn’t just a WCAG 2.2 requirement—it’s also just good UX.

    Avoid Overengineering with ARIA

    Don’t reach for ARIA unless you need to. Native HTML tends to be more robust across assistive technologies, and using ARIA incorrectly can make things worse. When in doubt, simplify.

    Test Like a User

    If you’re not testing with a keyboard, you’re flying blind. Add screen reader testing with NVDA, JAWS, or VoiceOver into your QA flow. Run Lighthouse and WAVE scans, but don’t rely on them alone—they won’t catch everything an actual user would encounter.

    Real-World Application: From Good to Great

    Let’s say you’re rebuilding a legacy FAQ section. It uses JavaScript to toggle open answers, but it’s riddled with <div>s and missing ARIA.

    Start by replacing the markup with semantic HTML:

    <details>
      <summary>What’s your return policy?</summary>
      <p>You can return items within 30 days.</p>
    </details>

    Then, enhance with JavaScript if you want only one section open at a time. Layer in ARIA attributes to improve screen reader support. Suddenly, you’ve turned a clunky widget into a polished, accessible accordion that works for everyone.

    Wrapping It Up

    Disclosures and accordions might seem interchangeable, but the differences matter—especially when accessibility is on the line. Whether you’re working on a quick FAQ or building a fully dynamic interface, an accessible accordion ensures users with different abilities can navigate and interact with your content.

    At the end of the day, accessibility isn’t about checking boxes—it’s about building better interfaces for everyone.

    Need help auditing your components?

    216digital offers in-depth accessibility support. Schedule an ADA compliance consultation to review your current implementation and ensure everything meets WCAG standards—without compromising design or performance.

    Greg McNeil

    May 8, 2025
    How-to Guides
    Accessibility, accessible accordion, Disclosure, How-to, HTML, semantic HTML, web developers, web development
  • Accessible Form Validation: A Developer’s Guide

    Forms are everywhere—login screens, signups, feedback surveys, checkout pages. They’re a cornerstone of user interaction on the web. But here’s the thing: if users can’t fill them out easily and accurately, your form isn’t just failing them—it’s failing your business.

    That’s where accessible forms come in. Accessible forms aren’t just about ticking boxes for compliance—they’re about creating better experiences for everyone. Whether someone is using a screen reader, navigating with a keyboard, or dealing with cognitive or motor disabilities, your form should guide, inform, and support them from first click to final submit.

    This guide will walk you through the essentials of accessible form validation, based on WCAG guidelines 3.3.1 through 3.3.4. No legalese—just practical advice you can implement today.

    Meet the Guidelines: WCAG 3.3.1 to 3.3.4

    Let’s simplify the four WCAG success criteria most relevant to form validation:

    • 3.3.1 Error Identification: If something goes wrong, users need to know what happened and where it happened.
    • 3.3.2 Labels or Instructions: Don’t make users guess. Tell them what’s required.
    • 3.3.3 Error Suggestion: If they make a mistake, suggest how to fix it. Don’t just point and shake your digital finger.
    • 3.3.4 Error Prevention: For serious forms (like taxes, legal documents, or financial data), build in checks to stop mistakes before they happen.

    Together, these guidelines form the foundation of truly accessible forms.

    Labeling: The First Step Toward Clarity

    Every good form starts with clear, semantic labeling. You’re not just adding text—you’re defining meaning and context for both users and assistive technologies.

    • Use the <label> element, and link it to the input with for="input-id" and id="input-id".
    • Place labels above the form field, not beside or inside. It’s easier to scan and better supported by screen readers.
    • Be concise but descriptive. Instead of “Name,” try “Full Name (First and Last).”

    Skipping proper labels is one of the fastest ways to make your form inaccessible—and one of the easiest problems to fix.

    Inline Error Messaging: Real-Time Feedback That Actually Helps

    Don’t let users fill out a whole form only to learn they messed up three fields. Inline validation catches issues in real time, helping users correct them before they submit.

    • Position error messages near the field—ideally right below or beside it.
    • Keep the language helpful and plain: “Password must be at least 8 characters.”
    • Use aria-live="polite" to announce error messages as they appear for screen readers.

    This creates accessible forms that support users proactively instead of punishing them after the fact.

    Don’t Skip aria-describedby

    Want to add help text, error messages, or extra instructions that screen readers can pick up? Use aria-describedby.

    This attribute lets you associate one or more descriptions with a form control. It’s a game-changer for accessible forms, especially when validation feedback or detailed guidance is involved.

    Example:

    <input id="email" aria-describedby="emailHelp emailError">
    <small id="emailHelp">We'll never share your email.</small>
    <span id="emailError">Email is required.</span>

    You can dynamically update which IDs are referenced based on validation state, ensuring that assistive tech users always get the right context.

    About Placeholders: Don’t Rely on Them Alone

    We’ve all seen it: fields with placeholder text like “Enter your email,” and no label in sight. Here’s the problem: placeholders disappear as soon as users start typing—and that’s bad news for accessibility.

    Use placeholders for examples, not for instruction.

    • ✅ “example@example.com” is fine.
    • ❌ “Enter your email address” as your only guidance? Not okay.

    Also, watch your contrast ratios. Light gray placeholder text on a white background might look trendy, but it can fail WCAG color contrast guidelines—especially for users with low vision.

    Smart Form Validation

    Validation is about more than catching errors—it’s about building trust. If your form is flaky, unclear, or inconsistent, users will bounce.

    • Use client-side validation (like HTML5 validation or JavaScript) for instant feedback.
    • Always back it up with server-side validation to catch anything missed and guard against malicious input.
    • Block submission until all required fields are valid—and clearly explain why a field isn’t.

    Whether it’s a missed checkbox or a mistyped phone number, your form should guide users toward fixing the issue—not leave them guessing.

    Crafting Helpful, Accessible Error Messages

    Bad error messages are like bad customer service: unhelpful, vague, and frustrating. Let’s fix that.

    • Be specific: “Username is required” > “Error.”
    • Never rely on color alone (like red borders) to indicate problems. Use symbols (like ❗), text, or both.
    • Keep error placement consistent—typically below the input or in the same visual region.
    • Use simple language. If someone has to decode your error message, it’s not helping.

    This clarity benefits everyone—from screen reader users to someone filling out your form on a noisy subway.

    Test It Like You Mean It

    Automated tools are great, but they only catch part of the picture.

    Start with:

    • Lighthouse for quick audits.
    • WAVE for spotting contrast or structural issues.

    Then go deeper:

    • Run through the form with keyboard only—can you reach and complete every field?
    • Try it with a screen reader (VoiceOver, NVDA, JAWS). Does it announce labels, instructions, and errors?
    • Ideally, test with real users with disabilities. There’s no substitute for lived experience.

    Accessible forms are never a “one-and-done” task. They’re a process—build, test, refine, repeat.

    Keep Moving Toward More Accessible Forms

    Every form you build is an opportunity to include—or exclude—someone. Whether it’s a simple newsletter signup or a detailed application, accessible forms ensure everyone gets a fair shot at completing the task.

    This isn’t just about compliance. It’s about craftsmanship. It’s about building smarter, kinder digital experiences—ones that don’t leave users behind.

    Need help building forms that meet WCAG standards and feel good to use? Connect with 216digital. We’ll help you create, audit, and refine accessible forms that work for every user—and every device.

    Greg McNeil

    April 18, 2025
    How-to Guides
    Accessibility, ADA Compliance, forms, How-to, WCAG, Web Accessibility, web development, Website Accessibility
  • Accessible Documents: 7 Issues You Might Overlook

    Have you ever tried to read a PDF on your phone only to pinch‑zoom until the text blurs? Now, picture that same frustration multiplied for someone who relies on a screen reader, a keyboard, or extra magnification. Inaccessible documents aren’t minor annoyances—they’re brick walls that block information. That’s why creating accessible documents is more than a best practice—it’s a necessity.

    This post walks through seven barriers often hidden inside PDFs and Word files. For each one, you’ll see why it matters, which Web Content Accessibility Guidelines (WCAG) success criteria apply, and how a few practical tweaks can open the door for every reader.

    Invisible Obstacles: Why Documents Trip People Up

    Web pages are usually built with clear HTML tags that signal headings, lists, and links. Conversely, documents mix text, images, and complex layouts in a single container. If you skip semantic structure or rely on visual styling alone, those layers become invisible mazes for people using assistive tech.

    WCAG was designed for the web, yet its principles work perfectly for accessible documents. Meeting them keeps your files usable for screen readers, keyboard navigation, high‑contrast modes, and more.

    1. Missing or Misused Headings

    When screen reader users rely on heading levels to navigate, skipping or misusing them turns a well-organized document into a frustrating guessing game. Simply enlarging font size doesn’t cut it—headings need to be properly structured.

    Make it better: Use built-in heading styles (H1, H2, H3, etc.) in Word or Google Docs, not manual formatting. Stick to one H1 per page for your title, followed by a clear hierarchy.

    Don’t forget: WCAG 1.3.1 requires meaningful structure—not just visual formatting. Run an accessibility checker before exporting to PDF to make sure your headings stay intact.

    Pro tip: Set your document language, so screen readers know how to pronounce text correctly. In Word, go to Review > Language > Set Proofing Language.

    2. When PDFs Are Just Pictures

    A scanned contract that looks fine on screen may be completely silent to assistive tech. Without real text, a screen reader simply announces “graphic… graphic… graphic.” There’s no searching, no enlarging, and no reading.

    What to do instead: Use OCR (Optical Character Recognition) to create a text layer. Adobe Acrobat, ABBYY FineReader, and Google Drive all have built-in OCR tools.

    Make it work: Always proofread OCR results—blurry scans and fancy fonts often lead to errors.

    Standards check: WCAG 1.4.5 requires using real, selectable text whenever possible.

    Bonus tip: Use document properties to add a title and author—these help screen readers and improve file organization. In Word: File > Info > Properties.

    3. Color Contrast That’s Too Subtle

    That soft gray text might look sleek on a light background—but if you have low vision or are reading on a dim screen, it becomes nearly invisible.

    How to fix it: Check color combinations before publishing. Use tools like WebAIM’s Contrast Checker or Adobe’s color contrast tools.

    What the guidelines say: WCAG 1.4.3 calls for a minimum contrast ratio of 4.5:1 for standard text.

    Design reminder: Check charts, infographics, and callout boxes too—those often sneak past brand reviews.

    4. Vague Link Text

    When every hyperlink says “Click here,” a screen reader user hears the same phrase over and over, with no context. It’s like walking through unlabeled doors and hoping for the best.

    Do this instead: Write descriptive links like “Download the 2025 Benefits Guide (PDF).” This helps everyone know what to expect before they click.

    Standards note: WCAG 2.4.4 requires link text to make sense on its own.

    Extra clarity: In Word, use ScreenTips (Alt + Ctrl + D) to add hover-text instructions for links.

    5. Images Without Alt Text

    If an image doesn’t include alt text, assistive tech can’t describe it—and users miss the point. Charts, infographics, and even decorative flourishes need attention.

    Quick fix: Describe the key message, not every visual detail. For example, summarize trends or highlight data points in charts.

    WCAG compliance: Guideline 1.1.1 requires text alternatives for all meaningful images.

    Helpful tip: Tag purely decorative images as “null” or “decorative,” so screen readers skip them. For complex visuals, link to a longer description or add it in an appendix.

    6. Tables That Don’t Translate

    Tables made with tabs or manual spacing may look fine, but screen readers can’t follow the structure. Data ends up being read out of order—turning financials or schedules into a jumbled mess.

    Get it right: Use built-in table tools. Define the first row as a header and use column headers where needed.

    Testing tools: In Word: Table > Properties > Row > Repeat as header row. In Acrobat Pro, use the Table Editor and test with NVDA or VoiceOver.

    Remember: WCAG 1.3.1 also applies here—data must be presented with proper markup and relationships.

    Avoid this: Don’t use tables for layout. It may seem like a shortcut, but it often leads to accessibility headaches.

    7. Lists That Don’t Act Like Lists

    Typing dashes or asterisks might look fine visually, but to a screen reader, it’s just a single paragraph. The structure—and meaning—is lost.

    Better approach: Use the bullets or numbering tools built into Word or Docs. Real lists help assistive tech break up and interpret content correctly.

    After exporting: Run “Autotag Document” in Acrobat and verify that lists are correctly tagged.

    WCAG reference: Once again, 1.3.1—structure matters.

    8. Use Clear Language and Layout

    Overly complex language or long-winded paragraphs can be barriers in themselves. Accessibility isn’t just about code or design—it’s about comprehension too.

    Try this: Write with clarity. Use simple words, short sentences, and plenty of white space. Break things up with subheadings and bulleted lists.

    Pro tip: Aim for an 8th-grade reading level or below when possible. Tools like Hemingway Editor or Microsoft Editor can help simplify your language.

    9. Choose the Right Export Settings

    Even the best-crafted document can lose accessibility features when exported carelessly.

    Before hitting “Save As”:

    • Use formats that preserve tags, alt text, and headings (e.g., PDF/A).
    • Use built-in export tools from Word, not third-party converters.
    • Double-check using an accessibility checker like Adobe Acrobat’s.

    10. Provide Alternative Formats

    Not every user consumes content the same way. Offering alternative versions ensures a broader reach.

    Examples:

    • A transcript for a video.
    • A plain-text version of a design-heavy PDF.
    • A mobile-friendly HTML version of a Word document.
    • This level of flexibility supports users with screen readers, low vision, dyslexia, and more.

    Beyond the Basics: Keep Creating Accessible Documents

    Fixing the top document issues is a great start—but real accessibility doesn’t stop at a checklist. It’s something you build into the process and revisit as tools evolve, teams shift, and standards update.

    Don’t rely on tools alone. Automated checkers are helpful for flagging missing tags or contrast issues, but they won’t catch everything. They can’t tell if your heading structure makes sense or if your alt text actually describes the image. A quick manual review—ideally from someone who understands assistive tech—can make all the difference.

    Keep your team in the loop. Many of the most common document barriers come down to simple habits: skipping heading styles, forgetting to add alt text, or using layout tables. Short training sessions or documentation refreshers can prevent a lot of repeat issues, especially if you’re onboarding new staff or updating templates.

    Check your templates yearly. Accessibility standards grow. So do the tools we use to write, design, and export. A quick annual review of your document templates helps ensure you’re not accidentally locking in outdated practices or missing opportunities to improve.

    Make Your Documents Work for Everyone

    Document accessibility isn’t about perfection—it’s about intention. When you take the time to apply heading styles, write descriptive link text, or check contrast ratios, you’re creating something that works for more people, in more ways.

    These changes aren’t hard. They’re habits. And once your team knows what to look for, accessible documents become second nature—just like spell check or formatting a title page.

    At 216digital, we offer more than advice. We can review your files, train your staff, and even build accessible templates tailored to your needs. Every project we take on includes complementary ADA training—so your team is empowered, not just compliant.

    If you’re ready to move past the guesswork and start building documents that include everyone, schedule a quick briefing with us. Together, we can turn accessible content into a shared standard—not a scramble.

    Let’s take that first step—one document at a time.

    Greg McNeil

    April 16, 2025
    How-to Guides
    Accessibility, accessible documents, How-to, PDF, WCAG, Website Accessibility
  • How to Use aria-describedby for Web Accessibility

    Have you ever looked at a form, seen the bold text or red borders, and instantly known what to do next? That’s because as visual users, we get a lot of clues from layout, color, and spacing. But for someone using a screen reader, those visual hints don’t exist. Instead, they rely on code—programmatic clues—to make sense of what’s on the screen.

    That’s where aria-describedby comes in. If you’ve ever struggled to make a form, button, or modal accessible, you’re not alone. aria-describedby is a powerful tool that helps users understand what’s happening—if you use it right.

    In this article, I’ll walk you through how to use aria-describedby the right way. We’ll go through practical code examples, real use cases, and common mistakes. I’ll also show you how it ties into making things like captions and subtitles more accessible, especially for users with assistive technology.

    Unpacking aria-describedby

    aria-describedby lets you link an element to other content that gives extra detail. It points to the ID(s) of one or more elements that contain helpful text. Think of it like this:

    • aria-labelledby gives something its name.
    • aria-describedby gives it extra explanation.

    If a screen reader sees an input with aria-describedby= "pw-hint", it will read the input label and the hint.

    Why It’s Important

    Used correctly, aria-describedby helps you meet the Web Content Accessibility Guidelines (WCAG) success criteria. It improves accessibility for users who rely on screen readers. It’s especially helpful when native HTML doesn’t cover all the information a user needs. This matters for users navigating complex interfaces—like forms, modals, or media players with captions and subtitles.

    When Should You Use aria-describedby?

    • Form fields: Add help text or error messages.
    • Buttons: Clarify what will happen, especially for destructive actions.
    • Dialogs/modals: Explain what the dialog is for.
    • Tooltips: Offer extra information without cluttering the interface.
    • Live status updates: Let users know when things change, like upload progress or loading indicators.

    aria-describedby can even support captions and subtitles in video players by giving extra context for the screen reader user, describing what’s happening beyond the visual content.

    When Not to Use It

    • If HTML already does the job (like using <label> or <fieldset>).
    • If it adds repetitive or unnecessary text.

    Code Walkthroughs: Real-World Examples

    Let’s get into some code. These examples show how to use aria-describedby in ways that make a real difference.

    Form Fields

    Password Requirements

    <label for="pw">Password</label>
    <input type="password" id="pw" aria-describedby="pw-hint">
    <p id= "pw-hint">Password must be at least 12 characters long and include a number.</p>

    Error Messages

    <label for="email">Email address</label>
    <input type="email" id="email" aria-invalid="true" aria-describedby="email-error">
    <p id="email-error" class="error">Please enter a valid email address.</p>

    Multiple Descriptions

    <input type="text" id="username" aria-describedby="username-req username-tip">
    <p id="username-req">Must be at least 8 characters.</p>
    <p id="username-tip">Displayed on your profile.</p>

    Buttons

    Destructive Action Explanation

    <button aria-describedby="delete-desc">Delete Account</button>
    <p id= "delete-desc">This will permanently remove your account and all data.</p>

    Dialogs and Modals

    Accessible Dialog

    <div role="dialog" aria-modal="true" aria-labelledby="dialogTitle" aria-describedby="dialogDesc">
      <h2 id="dialogTitle">Confirm Deletion</h2>
      <p id= "dialogDesc">This action is permanent and cannot be undone.</p>
    </div>

    Tooltips and Live Regions

    Accessible Tooltip

    <input type="text" id="first" aria-describedby="tip1">
    <div id="tip1" role="tooltip">Optional field.</div>

    Status Messages

    <div aria-describedby="upload-status">
      <input type="file" onchange="showUploadStatus()">
      <div id="upload-status" aria-live="polite">Uploading...</div>
    </div>

    These techniques can also apply to custom media players. You can use aria-describedby to point to captions and subtitles that are visible on screen but also need to be announced programmatically.

    Common Mistakes to Avoid

    • Too Many Descriptions: Linking to 3 or 4 IDs might overwhelm users.
    • Broken References: Make sure every ID you point to actually exists.
    • Redundant Content: Don’t repeat what’s already in the label.
    • Timing Issues: Don’t change the text dynamically during focus unless absolutely necessary.
    • Inconsistent Patterns: Keep your approach consistent across similar components.

    Best Practices for Effective Implementation

    • Write Clear Descriptions: Keep them short, useful, and easy to understand.
    • Avoid Jargon: Explain things in plain language.
    • Keep Descriptions Visible: If possible, don’t hide the text—what helps screen reader users can help sighted users, too.
    • Use Native HTML First: ARIA is a supplement, not a substitute.
    • Test Often:
      • Use screen readers like NVDA, JAWS, and VoiceOver.
      • Test in browsers like Chrome, Firefox, and Safari.
    • Stay Consistent:
      • Create reusable components.
      • Document your design patterns.
      • Automate accessibility checks.

    This also applies to any content with captions and subtitles—they should be clearly described in a way that works for both visual and non-visual users.

    Beyond the Code: Organizational Tips

    • Code Reviews Should Include Accessibility
    • Use Linters and Audits: Tools like Google Lighthouse or  WAVE to catch ARIA  barriers.
    • Add Accessibility to Your QA Checklist
    • Train Your Team: Make sure everyone knows what ARIA does and doesn’t do.

    If you’re building tools with captions and subtitles, include accessibility from the start. Don’t bolt it on later.

    Accessible Descriptions, Better UX

    aria-describedby is one of those quiet heroes of accessibility. It helps fill the gaps between what users see and what assistive tech can tell them.

    Used well, it improves the user experience for everyone—not just people using screen readers. It’s especially helpful in forms, dialogs, and anything with captions and subtitles, where the added context can be critical.

    So remember: use aria-describedby intentionally, test it thoroughly, and keep your patterns consistent. And if your team needs help making your site or app more accessible, 216digital offers expert guidance to help you meet compliance standards—while creating a better experience for all users.

    Let’s keep building an internet that works for everyone. One line of code at a time.

    Greg McNeil

    April 11, 2025
    How-to Guides
    ARIA, aria-describedby, How-to, Web Accessibility, web developers, web development, Website Accessibility
  • What Designers Get Wrong About Accessible Web Design

    When we talk about accessible web design, most people picture developers digging into code to fix issues after the fact. But the real magic—and often the biggest missed opportunity—starts much earlier in the process. It starts with us, the designers.

    Design isn’t just about how something looks; it’s about how something works. That includes making sure every user can interact with it, regardless of ability. The challenge is, even seasoned designers can unintentionally leave accessibility gaps in their work. Not out of carelessness, but simply because we weren’t taught to think about it.

    Let’s take a look at the most common ways accessible web design gets overlooked in the design phase—and how small changes can make a big difference. These aren’t technical developer fixes. They’re simple, design-first decisions that help create a more inclusive experience for everyone.

    Relying on Color Alone

    Using color to communicate meaning—like red for errors or green for success—might feel intuitive. But it doesn’t work for everyone. People with color vision deficiencies may not distinguish between red and green. Others might be browsing on devices in bright sunlight or with grayscale settings turned on. Color alone just isn’t enough.

    The good news is that accessible web design doesn’t mean ditching color—it means backing it up. A red border becomes more effective with an icon like an exclamation point and a short label that says “Error.” Color still enhances the message, but now it’s readable by everyone, regardless of how they perceive color.

    Poor Contrast Between Text and Background

    Minimalist palettes are trendy, but light gray text on a white background can create a serious readability issue. For users with low vision, poor contrast turns your carefully crafted content into a frustrating puzzle. It’s not just a style choice—it’s a usability barrier.

    Aiming for at least a 4.5:1 contrast ratio ensures your text is readable under a wide range of conditions, including mobile screens and bright environments. Tools like WebAIM’s Contrast Checker make it easy to test combinations. With accessible web design, clarity and style can absolutely coexist.

    Hover-Only Interactions

    Hover effects can make an interface feel sleek and modern, especially for desktop users. But the reality is that not everyone navigates with a mouse. Touchscreen devices and keyboard users don’t have the option to hover, which means they could miss essential content like tooltips, dropdowns, or action buttons.

    Accessible web design calls for interaction that works across devices and input types. If something appears on hover, it should also be accessible via keyboard focus or tap. That way, no one is left guessing—or worse, completely missing part of the site.

    Hiding or Removing Focus Styles

    One of the more subtle mistakes designers make is removing focus outlines to make interfaces feel cleaner. That glowing blue ring might not match the brand aesthetic, but it’s a crucial indicator for users navigating with a keyboard. It shows where they are on the page.

    Instead of removing it, try styling the focus indicator in a way that fits your brand. Make it visible, make it intentional. It’s a small touch, but it honors the needs of users who rely on keyboard navigation. That’s the heart of accessible web design—keeping things usable, not just pretty.

    Icon-Only Buttons Without Labels

    A trash can, a gear, a hamburger menu—these are all familiar icons to some of us. But they’re not universal. Assuming every user will instantly recognize what an icon means can create confusion, especially for users with cognitive differences or those who are new to digital interfaces.

    By adding a short label like “Delete” or “Settings,” or by providing an accessible name using ARIA labels, you give your users clarity. Icons still add visual interest, but now they’re functional for everyone. It’s another way accessible web design respects a broader range of experiences.

    Vague Link Text

    Link text like “Click here” or “Learn more” might seem harmless, but it quickly becomes a problem for people using screen readers. These users often navigate by skimming a list of links, completely out of the surrounding context. If all the links say the same thing, it’s impossible to know where they go.

    Writing meaningful link text—like “Download the 2025 Pricing Guide” or “Explore Our Accessibility Services”—adds clarity for everyone. Plus, it’s great for SEO. In accessible web design, clarity and functionality always go hand-in-hand.

    Layouts That Fall Apart When Text Is Resized

    Many users with low vision increase their device’s text size to read more comfortably. But if a layout isn’t built to handle that, the entire page can fall apart. Text overlaps, buttons get cut off, and navigation becomes a mess.

    Designing with flexibility in mind—using relative units like em, rem, or percentages instead of fixed pixel values—helps keep layouts intact even when zoomed in. Responsive grids, media queries, and scalable components all support accessible web design by making sure your content can adapt.

    Skipping Alt Text on Images

    Every image on your site has a purpose, whether it’s decorative or informative. But when you leave out alt text—or worse, insert placeholder text like “image123.jpg”—users who rely on screen readers are left without context.

    Good alt text is short, specific, and helps users understand the image’s role in the content. For example, “Smiling customer using our mobile app” is useful. If the image is decorative and adds no meaningful content, you can mark it as such so screen readers skip it. Accessible web design makes visuals work for everyone, not just those who can see them.

    Hard-Coded Font Sizes

    Hardcoding fonts in pixels may seem like a safe bet for maintaining visual control, but it can limit how users adjust their settings. People who need larger text may be blocked by your choices, especially if CSS prevents scaling.

    By using relative units, you give users control over their reading experience. Fonts should scale with their preferences, not fight against them. Accessible web design puts usability first, allowing your audience to engage with your content in the way that works best for them.

    Overly Complex Navigation

    Mega menus, fancy interactions, and unique navigation patterns can look impressive in a mockup—but they can create major barriers for people using keyboards or assistive tech. When navigation becomes a puzzle, users are more likely to get frustrated and leave.

    The most effective navigation is simple, consistent, and easy to explore. Use clear labels, test with keyboard-only input, and rely on semantic HTML whenever possible. Accessible web design doesn’t mean boring—it means dependable, predictable, and inclusive.

    Where Good Design Meets Real-World Impact

    Designers have the power to make the web more inclusive. And the best part? You don’t have to start from scratch. These changes are often small, thoughtful adjustments that make a big difference for users who rely on them.

    Accessible web design isn’t a limitation—it’s an invitation to create better work. It asks us to go beyond trends and think deeply about the people who use the things we build. With every project, we can help make the internet a place where more people feel seen, supported, and able to fully participate.


    If you’re looking for a partner who understands the balance between beauty, functionality, and accessibility, 216digital is here to help. Together, we can make accessible web design the standard—not the exception.

    Greg McNeil

    April 8, 2025
    How-to Guides, Web Design & Development
    Accessible Design, ADA Lawsuit, How-to, responsive design, UX, Web Accessible Design
  • eCommerce Accessibility: Cart & Checkout Best Practices

    As a front-end developer, you already know how much the small stuff matters—clear labels, logical tab order, and meaningful feedback. These details don’t just polish the experience; they make the difference between a site that works for everyone and one that silently shuts people out. When it comes to eCommerce accessibility, gaps tend to show up in the usual suspects: shopping carts, forms, payment flows, and filters.

    Below, we’ll explore common eCommerce accessibility gaps and show you how to fix them. You’ll see examples of HTML and ARIA attributes that make a real difference in usability—without requiring you to overhaul your entire site. Just clean, thoughtful code that helps your work reach more people, the way it’s meant to.

    Why Accessibility Matters in E-Commerce

    Better eCommerce accessibility results in a better user experience. When you streamline navigation, label form fields properly, and offer multiple payment methods, you’re benefiting everyone, not just shoppers with disabilities. You’re also opening your doors to more customers, including those who use screen readers, have limited mobility, or simply prefer an intuitive layout.

    Beyond enhanced usability, there’s also the legal side. Lawsuits related to eCommerce accessibility are on the rise. Addressing accessibility from the start can help reduce legal risks, but the bigger win is ensuring all potential customers feel welcome in your store.

    eCommerce accessibility often breaks down at a few critical points:

    • Shopping carts with unclear or missing labels.
    • Forms and checkouts that don’t offer proper error messages.
    • Payment flows that are dependent on inaccessible CAPTCHAs or limited payment methods.
    • Product filters that are keyboard-incompatible or lack clear feedback.

    If you’re a developer responsible for these features, you’re in the perfect position to fix these problems. A few strategic lines of code or well-placed attributes can help transform a confusing checkout into a seamless experience for all.

    Making Your Shopping Cart Work for Everyone

    Add Clear Labels (Yes, Even for Buttons)

    It’s a common oversight to have buttons or icons without descriptive text. Screen readers can’t interpret an icon unless you provide an aria-label or similar attribute. Give every button clear text or an invisible descriptor for assistive tech.

    <button aria-label="Remove item from cart">
      Remove
    </button>

    This simple step ensures that anyone using a screen reader knows exactly what action they’re about to take.

    Let People Update Cart Items Without Guesswork

    Quantities, item removals, and other cart updates should be straightforward. If you’re using a numeric input, label it properly so a screen reader user knows what they’re adjusting.

    <label for="quantity">Quantity:</label>
    <input type="number" id="quantity" name="quantity" min="1" value="1">

    When quantity fields are clearly labeled and keyboard-friendly, customers can adjust items easily—no mystery involved.

    Show Helpful Feedback When Things Go Wrong

    Errors happen: maybe a shopper enters an invalid quantity or tries to remove an item that’s no longer in stock. Instead of reloading the entire page (and frustrating users), use an aria-live region to announce errors in real-time:

    <div role="alert" aria-live="assertive">
      Error: Please enter a valid quantity.
    </div>

    This alerts people using screen readers without forcing them to refresh or hunt for an error message.

    Shipping Forms That Are Easy to Use (and Easy to Navigate)

    Use Straightforward, Consistent Labels

    Forms can become confusing if users aren’t sure what to type. Proper <label> tags tied to the correct inputs make a huge difference for both sighted customers and those using assistive tech.

    <label for="address">Shipping Address:</label>
    <input type="text" id="address" name="address">

    When labels are descriptive and consistent throughout the form, everyone knows exactly what information to provide.

    Make Sure Users Can Tab Through Fields Logically

    Keyboard-only users often navigate by pressing the Tab key. If your form fields aren’t in a logical sequence, they’ll jump around unpredictably. Paying attention to the natural DOM order is usually enough, but if you must alter it, use tabindex carefully.

    Show Errors Clearly and Offer Suggestions

    Generic error messages like “Invalid input” force users to guess what they did wrong. Instead, offer specific guidance so people know exactly how to fix the issue:

    <div role="alert">
      Error: ZIP code must be five digits.
    </div>

    This clarity benefits everyone, speeding up the checkout process and reducing frustration—two big wins for eCommerce accessibility.

    Designing a Payment Flow That’s Smooth and Inclusive

    Offer More Than One Way to Pay

    Variety in payment methods—credit cards, PayPal, Google Pay, Apple Pay, etc.—ensures different shoppers can complete purchases in a way that suits them. Some assistive technologies work better with certain payment platforms, so having options expands your customer reach.

    If You Use CAPTCHAs, Make Them Accessible

    Nothing derails a checkout faster than an inaccessible CAPTCHA. If possible, rely on server-side checks. If you do need a CAPTCHA, consider offering an audio version or a more user-friendly alternative. This prevents people with disabilities from being locked out at the final step of their eCommerce accessibility journey.

    Choose Accessible Payment Gateways

    Third-party payment platforms can introduce new accessibility issues. Do a quick review to ensure any external gateway meets basic WCAG standards and is compatible with screen readers and other assistive tools. Even the best checkout flow can fail if the final payment step isn’t accessible.

    Don’t Let Product Filters Be a Barrier

    Make Filters Keyboard-Friendly

    Checkboxes, sliders, and dropdowns all need to be navigable via keyboard. That means ensuring users can Tab to each control, use arrow keys for sliders, and press Enter or Space to toggle checkboxes or confirm a selection.

    Let Users Know What Filters Are Applied

    Always make it clear which filters are currently active, both visually and programmatically (via ARIA attributes). This helps sighted users and people using screen readers track their selections and remove or adjust filters easily.

    Stick to Native HTML Controls When Possible

    While custom-styled checkboxes and radio buttons can look appealing, they often introduce accessibility quirks. Native HTML elements are easier to make accessible:

    <fieldset>
      <legend>Filter by Size</legend>
      <label><input type="checkbox" name="size" value="small"> Small</label>
      <label><input type="checkbox" name="size" value="medium"> Medium</label>
      <label><input type="checkbox" name="size" value="large"> Large</label>
    </fieldset>

    You can style them to fit your brand while ensuring they work out of the box for most assistive tech. It’s one of the easiest ways to improve eCommerce accessibility.

    Testing and Validating Your Work

    Start with Automated Tools (But Don’t Stop There)

    Tools like Google Lighthouse and  WAVE are great starting points. They scan for many common issues, but automated tests can’t cover everything, especially more nuanced user interactions.

    Test Manually with Real Assistive Tech

    Grab a screen reader like NVDA (Windows) or VoiceOver (Mac). Try using only your keyboard to navigate the site. This hands-on approach reveals a lot about real-world usability that automated checks might miss—especially in areas related to eCommerce accessibility.

    Get Feedback from Real Users

    If you can, involve people with disabilities in your testing. Their direct experience helps pinpoint issues you might never notice on your own. Real-world feedback is invaluable for refining the shopping journey.

    Small Fixes, Big Impact

    Building an accessible eCommerce site doesn’t require a complete overhaul. Most improvements, like adding clear labels or structuring forms properly, are quick, incremental changes in your code. These small fixes can significantly enhance the experience for shoppers who rely on assistive technology—and often make the site more pleasant for everyone else as well.

    If you want more detailed guidance or an expert review, there are plenty of resources on WCAG and web.dev. You can also team up with 216digital, where we specialize in making sure online stores meet eCommerce accessibility standards from start to finish. Whether you need help with checkout flows, product filtering, or a full-site audit, our team is here to ensure every shopper can complete their purchase with ease.

    Remember: inclusive design isn’t just a checkbox—it’s a mindset. By prioritizing eCommerce accessibility at each step of your development process, you’ll build online shopping experiences that truly welcome everyone. And that’s good business for everyone involved.

    Greg McNeil

    April 4, 2025
    How-to Guides
    Accessibility, ecommerce website, How-to, WCAG Compliance, Web Accessibility, web developers, web development, Website Accessibility
1 2 3 … 8
Next Page
216digital Scanning Tool

Audit Your Website for Free

Find Out if Your Website is WCAG & ADA Compliant













    216digital Logo

    Our team is full of expert professionals in Web Accessibility Remediation, eCommerce Design & Development, and Marketing – ready to help you reach your goals and thrive in a competitive marketplace. 

    216 Digital, Inc. BBB Business Review

    Get in Touch

    2208 E Enterprise Pkwy
    Twinsburg, OH 44087
    216.505.4400
    info@216digital.com

    Support

    Support Desk
    Acceptable Use Policy
    Accessibility Policy
    Privacy Policy

    Web Accessibility

    Settlement & Risk Mitigation
    WCAG 2.1/2.2 AA Compliance
    Monitoring Service by a11y.Radar

    Development & Marketing

    eCommerce Development
    PPC Marketing
    Professional SEO

    About

    About Us
    Contact

    Copyright 2024 216digital. All Rights Reserved.