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

  • 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

  • Alt Text: Why Marketing Copy Hurts Accessibility

    Have you ever hovered over an image on a webpage and noticed a small snippet of text appear? That text is called “alt text,” and it plays a powerful role in how people experience your site—especially those who rely on screen readers. Yet it often remains an afterthought. That’s a problem. When handled correctly, it not only helps visually impaired users understand your images, but it can also support your SEO goals. On the other hand, stuffing alt text with keywords or using it as hidden ad space can frustrate visitors and hurt your search rankings.

    In this article, you’ll learn why alternative text matters, how it benefits both accessibility and SEO, and how to write it in a clear, concise, and helpful way rather than a spammy or sales-focused one. Whether you’re a solo entrepreneur, a web developer, or part of a digital marketing team, these principles will help you craft alt text that meets user needs without alienating search engines—or your audience.

    Why Alt Text Matters

    Imagine you’re shopping for a laptop case online, and you can’t see the product images. Screen reader users rely on alt text to “hear” what’s happening in each image, from color to texture. If it is nothing more than “Get the best laptop case here,” that user is left with zero details about the product. They might simply leave for a site that offers the information they need. When you write alt text that clearly states “Black leather laptop case with a zipper and handle,” you empower all customers, including those with visual impairments, to make informed decisions.

    SEO Wins

    Search engines analyze alt text to better understand what each image represents. This can give your site a leg up in search rankings for relevant queries. However, algorithms have grown smart enough to recognize keyword-stuffed or spammy text. If your alt text reads like a desperate attempt to shoehorn “laptop case” 10 times, you might do more harm than good. Concise, descriptive text helps Google and other search engines match your site with the people who genuinely want to find your products.

    Common Alt Text Pitfalls

    Keyword Overuse

    It can be tempting to sneak in extra keywords to boost SEO. But endless repetition—like “car seat protector, seat protector for cars, vinyl seat protector”—makes the text clunky and unhelpful. Search algorithms can detect spammy patterns, and users who rely on screen readers will find the repetition tedious or confusing.

    Marketing Copy Disguised as Descriptions

    Some site owners treat alt text fields as free ad space, writing something like:

    “Our top-selling leather laptop case, now 20% off! Don’t miss this exclusive deal—buy today!“

    While it may read like a catchy tagline, it doesn’t describe the image. A screen reader user learns nothing about color, texture, or design. Plus, Google doesn’t benefit from vague promotional language and might even flag your page as low-quality.

    Empty or Missing Alt Text

    Perhaps the biggest mistake is neglecting alt text entirely. In that case, a screen reader user hears nothing—just empty space—making it impossible to engage with or understand the image. If a product image is critical to your sales, that’s a huge missed opportunity.

    Repeating “Image of”

    Screen readers already announce that an element is an image. If your alt text says “Image of a black laptop case,” it’s redundant. Jump straight to the essential details: “Black leather laptop case with a zipper and handle.”

    Writing Alt Text the Right Way

    Focus on Real Descriptions

    The primary function of alt text is to describe the image so someone can visualize it through words. For a black vinyl car seat protector, a simple yet complete phrase might be:

    “Black vinyl seat protector on the driver’s seat with a zippered pocket.”

    This gives useful details while remaining concise—no filler like “best seat protector,” no repeated keywords, and no promotional language.

    Keep It Concise Yet Informative

    Alt text generally doesn’t need to be more than one or two short sentences. Offer key details without overwhelming the user. For a laptop case, mentioning the color, material, and whether it has a handle or zipper is usually enough. Screen reader users just need the essentials to identify or comprehend the image.

    Context Is Important

    If the image has a functional role—like a button or a link—clarify that. For instance, if users click an image to add a product to their cart:

    “Add to cart button for black vinyl seat protector”

    This way, a screen reader announces the function, not just the object in the image.

    Skip Redundant Phrases

    Screen readers typically announce that an element is an image, so writing “Image of” or “Graphic showing” is unnecessary. Go straight into the description. It keeps your text short and saves valuable time for the user.

    The Real-World Impact of Bad Alt Text

    Frustrating Users

    When alt text is stuffed with marketing copy or random keywords, it becomes meaningless for users with visual impairments. They hear a repetitive sales pitch instead of valuable information. This frustration often leads them to abandon your site, which hurts your brand image—and your bottom line.

    Possible Legal Ramifications

    In an era of heightened focus on digital accessibility, businesses risk legal consequences by not meeting basic standards. Some organizations have faced lawsuits for failing to include alt text. While legal outcomes vary by location and industry, it’s best to be proactive.

    Lower Search Engine Rankings

    Search engines want to display content that offers value. If your alt text is obviously spammy or unhelpful, algorithms may penalize your pages or push them further down the results. A high bounce rate—where users leave quickly due to poor user experience—also signals to Google that your site isn’t meeting visitor needs.

    Practical Steps to Improve Your Alt Text

    Conduct an Alt Text Audit

    Start by reviewing your site for missing or poor-quality alt text. Tools like the WAVE Web Accessibility Evaluation Tool highlight potential issues. Many SEO platforms also include site audits that can reveal duplicated alternative text text or keyword stuffing.

    Leverage AI Judiciously

    AI can be a lifesaver if you have thousands of product images. Tools like Google Vision offer automated descriptions, but they’re not always accurate. AI might misidentify colors or add superfluous words, so always review automatically generated alt text for accuracy and clarity.

    Follow Recognized Guidelines

    The Web Content Accessibility Guidelines (WCAG) provide standardized advice on writing effective alternative. Aim to:

    • Describe the image’s important details.
    • Keep it concise.
    • Skip filler words like “picture of.”
    • Use empty alt text (alt=" ") for purely decorative images that don’t add information.

    Test with Real Users

    Whenever possible, invite screen reader users to test your site. No automated tool can replace real feedback from people who use assistive technology daily. They’ll quickly tell you if your alt text is too vague, too repetitive, or missing crucial details. Their firsthand insights can highlight any confusion or gaps.

    Best Practices at a Glance

    • Prioritize clarity: Let users know exactly what they’re “seeing” through your words.
    • Stick to relevant details: Think color, material, function, or context—not ad slogans.
    • Limit keywords: A single, well-placed keyword can assist SEO. Overuse can sabotage it.
    • Adapt to the image: Product angles differ, so describe each image’s unique perspective.
    • Check surrounding text: If “black laptop case” appears in the product name next to the image, you may not need to repeat it in the alt text.

    Conclusion

    In today’s competitive online environment, you can’t afford to overlook the importance of alt text. A single line of well-chosen words can be the difference between an inclusive, intuitive user experience and a site that feels incomplete to a significant segment of your audience. By writing concise, descriptive alt text—free from keyword stuffing and promotional fluff—you create a more welcoming website and help search engines better understand your content.

    If you’re ready to enhance your site’s accessibility while protecting its SEO standing, consider partnering with 216digital. We’ll help you fine-tune your alt text (and the rest of your site) so that every visitor, whether they see your images or hear them described, gets the information they need. Embracing accessibility and clarity isn’t just the right thing to do—it’s also a savvy move for your online presence.

    Greg McNeil

    March 28, 2025
    The Benefits of Web Accessibility
    Accessibility, Alt text, How-to, Image Alt Text, Marketing, SEO, WCAG, Website Accessibility

  • Accordion Accessibility: Common Issues & Fixes

    Organizing content effectively on the web is about more than just layout—it’s about usability and inclusivity. When users are forced to scroll through long pages of uninterrupted text, the experience becomes inefficient and frustrating.

    Enter accordion components: interactive UI elements that allow content sections to be expanded or collapsed. When implemented correctly, accordion accessibility streamlines navigation and improves content organization. However, if accessibility is overlooked, these helpful components can quickly become barriers.

    This guide explores how to design accessible accordion components that enhance the user experience and meet all users’ needs—regardless of their abilities. We’ll cover best practices for structure, semantics, ARIA attributes, keyboard support, and implementation strategies to help you build inclusive, user-friendly interfaces.

    Why Accordion Accessibility Matters

    Accordions are essential: they reduce visual clutter and allow users to interact with content on their terms. Whether it’s an FAQ page, a product feature breakdown, or technical documentation, accordions help surface only the content that matters at the moment.

    However, it’s crucial to remember that not all users interact with content similarly. Screen reader users, keyboard-only users, and others with varying access needs must be able to operate accordions just as easily as those using a mouse or touchscreen. Accessible design isn’t just a nice-to-have—it’s an essential component of responsible development.

    The Building Blocks of an Accordion Accessibility-Friendly Component

    1. Structure: Header and Panel

    Every accordion should be composed of two core parts:

    Header (Trigger)

    A clickable element (typically a <button>) that users activate to show or hide content. It usually includes a descriptive label and may feature visual indicators like arrows or plus/minus icons.

    Panel (Content)

    The content is associated with the header. It should be hidden from view and keyboard focus when collapsed and fully accessible when expanded.

    For effective accordion accessibility, each header must be clearly linked to its corresponding panel—visually for sighted users and programmatically for assistive technologies.

    2. Keyboard Navigation

    One of the most common accessibility pitfalls with accordion components is insufficient keyboard support. If users can’t operate your interface without a mouse, it’s not accessible.

    Your accordion must support the following interactions:

    • Tab / Shift + Tab: Move between focusable elements, including accordion headers.
    • Enter or Space: Expand or collapse the currently focused header.
    • Arrow Up / Arrow Down: Navigate between accordion headers.
    • Home / End: Jump to the first or last header within the accordion group.

    By supporting these interactions, you ensure that keyboard users have the same level of control as mouse users.

    3. Use Semantic HTML

    Semantic HTML provides the backbone of accessibility. It ensures assistive technologies can understand the structure and function of your content without additional cues.

    Best Practices for Accordion Accessibility

    • Use heading elements (<h3>, <h4>, etc.) to maintain the document outline.
    • Place a <button> inside the heading to toggle visibility.
    • Wrap panel content in a <div> that follows its associated button.

    Why <button> and not <div> or <a>?

    Buttons are keyboard-focusable by default, accessible to screen readers, and support interactions like Enter and Space. Enter and Space. If you rely on <div> or <a> for toggling, you’ll need extra code to achieve the same level of accordion accessibility.

    4. Implementing ARIA Attributes

    ARIA (Accessible Rich Internet Applications) attributes enhance accessibility when native HTML doesn’t fully express an element’s role or state. In custom accordions, these attributes help communicate dynamic behavior to assistive technologies.

    ARIA Attributes for Accordion Accessibility

    • aria-expanded: Indicates the panel’s expanded (true) or collapsed (false) state. Applied to the button.
    • aria-controls: Points to the id of the panel controlled by the button.
    • aria-labelledby: Applied to the panel, this links it back to its header button for context.
    • aria-hidden:Use decorative icons or non-informative content to prevent screen readers from announcing them.

    These attributes ensure that screen reader users receive clear, relevant information about the accordion’s behavior and structure.

    Implementation Examples

    Option 1: Native HTML with <details> and <summary>

    For a semantic-first approach, HTML offers a native accordion-like behavior:

    <details>
  <summary>Shipping Information</summary>
  <div>
    <p>We offer free shipping on orders over $50...</p>
  </div>
</details>

    Pros

    • Minimal code
    • Built-in keyboard support
    • Accessible by default in modern browsers

    Cons

    • Styling can be limited
    • Inconsistent support across all assistive technologies

    This is a great lightweight option for simple use cases but may fall short in more complex interfaces.

    Option 2: Custom JavaScript Accordion with ARIA

    If you need more control, a custom accordion allows full styling and behavior management—just be sure to handle accordion accessibility properly.

    HTML Structure

    <h3>
  <button aria-expanded="false" aria-controls="panel1" id="accordion1">
    Shipping Info
  </button>
</h3>
<div id="panel1" role="region" aria-labelledby="accordion1" hidden>
  <p>We offer free shipping on orders over $50...</p>
</div>

    JavaScript snippet

    const buttons = document.querySelectorAll('button[aria-expanded]'); buttons.forEach((button) => { const toggleAccordion = () => { const expanded = button.getAttribute('aria-expanded') === 'true'; button.setAttribute('aria-expanded', String(!expanded)); const panel = document.getElementById(button.getAttribute('aria-controls')); panel.hidden = expanded; }; button.addEventListener('click', toggleAccordion); button.addEventListener('keydown', (event) => { if (event.key === 'Enter') { toggleAccordion(); } }); });

    This implementation not only handles basic interaction but also improves navigation for keyboard users. Combined with semantic structure and ARIA, it creates a robust and inclusive experience.

    Best Practices to Keep in Mind

    • Use Clear Labels: Avoid generic labels like “Section 1.” Use descriptive headers that make sense out of context.
    • Provide Visual Cues: Arrows or plus/minus icons help users understand that a section is expandable. Consider animations that reinforce open/close behavior.
    • Maintain Focus Indicators: Never remove focus outlines unless you’re replacing them with custom indicators that are just as visible.
    • Be Selective with Accordions: Don’t hide critical content. It should be visible by default if the information is essential (e.g., pricing, legal disclaimers).

    Testing Accessibility

    Even well-intended implementations can miss the mark without testing. Include accessibility testing as part of your development workflow:

    • Keyboard-Only Testing: Navigate the accordion entirely by keyboard.
    • Screen Reader Testing: Use tools like NVDA, JAWS, or VoiceOver to check for correct announcements.
    • Automated Tools: Run your component through tools like WAVE, or Lighthouse to identify missing attributes or ARIA misuse.
    • Manual Code Review: Double-check that all attributes, labels, and roles are properly implemented.

    Final Thoughts

    Accessible accordions do more than organize content—they foster a better, more inclusive web. By prioritizing structure, semantics, ARIA roles, and thoughtful interaction design, you empower all users to engage with your content meaningfully.

    If you’re unsure where to start or want to ensure your components meet accessibility standards, consider working with an experienced accessibility partner like 216digital.  We specialize in helping teams build digital experiences that work for everyone—by default, and with accordion accessibility baked in.

    Greg McNeil

    March 27, 2025
    How-to Guides
    Accessibility, accordion, accordion accessibility, How-to, web developers, web development, Website Accessibility

  • A Guide to Accessible Table Design & Development

    Once upon a time, table design was web design. Before the elegance of CSS Grid or the flexibility of Flexbox, we built entire sites with <table>, <tr>, and <td> like it was second nature. They were the backbone of layout — the duct tape holding the early web together. But as web development matured, we traded layout tables for cleaner, more semantic code. Still, tables remain essential — not for layout, but for what they were truly meant to do: present data.

    So, where do tables fit into modern, accessible web design? When are they appropriate, and how do we use them in a way that supports users of all abilities, including those using screen readers or keyboard navigation?

    In this guide, revisit table design through a modern lens  — not to reminisce about the old days of spacer GIFs and nested rows, but to examine how to use tables the right way today. Whether you’re structuring tabular data or dealing with legacy layouts, we’ll walk through practical techniques for designing and coding tables that are both functional and inclusive.

    Understanding Tables in Web Design

    Tables still serve a clear purpose in today’s web — when used thoughtfully. But there’s a key distinction: data tables are for presenting information, and layout tables… well, those belong in the same drawer as Netscape hacks and the blink tag. How you use them matters, especially for folks navigating with a screen reader or keyboard.

    Understanding the difference is the first step toward solid, accessible table design that doesn’t leave users behind.

    Data Tables

    Need to show structured data like schedules, product comparisons, or sales reports? That’s what data tables were born to do. When used well, they make complex info digestible — like a well-organized spreadsheet that doesn’t make you want to flip your monitor.

    Making Data Tables Accessible

    Start with semantic HTML — <th> for headers, <caption> for context, and group rows and columns meaningfully. These tags are like orientation tools for assistive tech — they help users actually understand the structure, not just hear a blob of words.

    Reading order is your next frontier. If your table reads like it was assembled after three espressos and a deadline, it’s time to regroup. Make sure users can follow the flow with no surprises.

    And if you’re knee-deep in rowspans and colspans, it’s worth pausing to ask: “Is this actually helping, or am I just flexing?” Clean table design helps avoid this entirely.

    Layout Tables

    Let’s talk about the fossil in the room: layout tables. We all used them. Some of us even nested them. Some of us still wake up in cold sweats because of them.

    Why They Were Used

    Back in the day, if you wanted a three-column layout, you reached for a table. Pixel-perfect footer? Table. It was the best option we had — right up until CSS knocked politely and said, “I got this.”

    Why It’s Time to Move On

    CSS changed the game. Layout tables now clutter your markup, confuse screen readers, and break responsiveness faster than you can say “media query.” The result? A tangled mess that’s hard to debug and harder to maintain.

    Golden rule: Tables for data. CSS for layout. Break this rule only under duress (or for archaeological purposes).

    If you must touch layout tables, think of it less as designing a layout and more as preserving legibility. It’s a survival-style form of table design.

    When You Have to Use Layout Tables

    Sometimes, you inherit legacy code that’s more delicate than a house of cards. Or you’re working with a CMS that still thinks it’s 2003. When you’re stuck, the goal becomes minimizing the chaos.

    Best Practices for Using Layout Tables (Responsibly)

    • Skip semantic elements: Leave <th> and <caption> out. They’ll only mislead screen readers.
    • Use role= "presentation": This politely tells assistive tech, “Nothing to see here — just visuals.”
    • Keep content order logical: It might look fine, but hit the tab or turn on a screen reader. If it reads like a jigsaw puzzle, rework it.
    • Make it responsive — sort of: You’re already doing something frowned upon. At least don’t let it collapse on mobile.

    CSS to the Rescue

    Need flexible, responsive, accessible layouts? CSS has your back. You’ve got two powerhouse options ready to roll.

    CSS Grid Layout

    CSS Grid is built for complex, two-dimensional layouts. It gives you surgical control over rows and columns without diving into the <td> abyss.

    Heads-up: Keep your DOM order consistent with your visual order. Otherwise, assistive tech users will be piecing together your layout like a mystery novel.

    CSS Flexbox

    Flexbox handles one-dimensional layouts like a champ. Think nav bars, form groups, toolbars — anything that lines up in a row or column.

    Just remember, Flexbox can reorder your layout visually, but screen readers still follow the source order. Rearranging things for aesthetics? Fine. Just don’t confuse your users while you’re at it.

    Both of these tools help prevent misuse of tables and support better table design principles by removing the temptation to force non-tabular content into table markup.

    Follow the Principles, Not Just the Code

    Accessibility isn’t about ticking boxes — it’s about designing with real people in mind. Think about how someone actually experiences your content. No mouse. No visuals. Just structure, clarity, and flow.

    If someone is using a screen reader, keyboard navigation, or sip-and-puff device, your clean CSS layout means nothing if your content order is a mess. Great table design considers these experiences from the start.

    Key Guidelines from WCAG to Keep in Mind:

    • Info and Relationships (1.3.1): Use markup to show how data connects. Don’t rely on appearance alone.
    • Meaningful Sequence (1.3.2): Your content should flow in a way that makes sense, both visually and in the code.

    Quick Recap: Best Practices

    • Use tables only for tabular data — not layout, not nostalgia
    • Mark up data tables semantically — <th>, <caption>, proper scope
    • Use CSS (Grid or Flexbox) for layout — always
    • Only use layout tables when you absolutely have no other option
    • If you must use layout tables, strip out semantics and add role=" presentation"
    • Don’t rely on automated tools alone — test with real assistive tech

    Final Thoughts

    The web’s grown a lot since the days of spacer GIFs and table-based layouts — and thankfully, so have our tools. We can build cleaner, more flexible, more inclusive sites with far less hassle than we could a decade ago.

    So let’s do that. Use tables where they belong — to present data. Embrace modern CSS for everything else. And always remember: building for accessibility doesn’t slow you down. It just makes your work better.

    And if you’re ever elbow-deep in a legacy layout table with seven levels of nested <tr>, know this: someone out there gets it. And they’re probably muttering “never again” right along with you — while dreaming of cleaner table design.

    Greg McNeil

    March 18, 2025
    How-to Guides
    Data tables, How-to, table design, web developers, web development

  • How to Make Mega Menus More Accessible

    A mega menu is typically a large, two-dimensional panel that appears when a user interacts with a top-level navigation item. It’s often used by eCommerce stores or websites with many different product categories or content sections. Because it can display a wide variety of links in a single view, a mega menu helps visitors explore your site quickly—no endless drilling down into submenus.

    But here’s the catch: while mega menus make navigation simpler for many users, they can also create barriers for some. For example, hover-triggered mega menus might be useless for someone relying on a keyboard. Or, if the menu isn’t properly labeled, a screen reader user might get stuck in a confusing loop of unlabeled links.

    These barriers matter because web accessibility is not just about following rules—it’s about ensuring everyone can use your site. If you leave people out, you risk alienating customers who want to purchase your products or read your content. So, let’s dive into some common accessibility issues and how to fix them.

    Overcoming Common Accessibility Challenges

    Improving Hover Functionality

    Most mega menus open when you hover your mouse over the navigation item. However, hover-based menus can cause big problems for keyboard users (or anyone who can’t use a mouse).

    • Inaccessible for Keyboard Users: People who navigate with the keyboard use the Tab key to move from link to link. If a menu only opens on hover, these users can’t open the submenu.
    • Overly Sensitive Interactions: Sometimes, mega menus can pop open or shut at the slightest movement of your mouse. This makes them frustrating to use for everyone.
    • The “Diagonal Problem”: If you move the mouse at an angle, you can sometimes trigger submenus you didn’t intend to open.

    Best Practice: Use a click to open the submenus instead of relying on hover. This way, both mouse and keyboard users have a more predictable experience. A click is a clearer signal of intention, reducing accidental openings or closings.

    Making Menus Easy to Close

    A menu that’s hard to dismiss can trap users, especially if it covers a large portion of the screen. On the other hand, a menu that closes too quickly can frustrate users who accidentally hover away for a split second.

    Solutions:

    1. Escape Key Support: Let users close the menu by pressing the Escape key. This is a standard expectation in many UI patterns and helps keyboard users exit quickly.
    2. Delayed Closing: If you decide to keep some hover functionality, add a slight delay before the submenu disappears. This grace period prevents the menu from closing by mistake if a user’s pointer drifts outside the panel for a moment.

    Enhancing Keyboard Accessibility

    Logical Keyboard Navigation

    Keyboard navigation is a critical part of web accessibility. You want the user’s Tab key presses to move in a clear, intuitive order:

    1. First Tab: Highlight the first top-level navigation item.
    2. Enter Key: If the focused top-level item has a submenu, pressing Enter opens that submenu. Pressing Enter again on any submenu item activates the link.
    3. Tab Within a Submenu: Moves focus to the next item in the submenu.
    4. Escape Key: Closes the submenu and returns focus to the parent menu item.
    5. Shift + Tab: Moves backward through the items, letting users navigate in reverse.

    This logical flow ensures that people who rely on the keyboard won’t get lost or stuck.

    Providing Clear Focus Indicators

    When users press Tab, they should be able to see exactly which menu item is highlighted. This means using visible focus indicators:

    • A change in background color, an underline, or a bold outline helps users quickly spot the focused item.
    • Make sure the color contrast meets accessibility guidelines. Avoid using color alone—some users might not see color differences clearly. An underline or border is a more reliable visual cue.

    Optimizing Screen Reader Support with ARIA

    Choosing the Right ARIA Roles

    Using role= "menu" for all navigation is a common mistake introduced in development. This role should only be used if your navigation behaves like a desktop application menu. For most website mega menus, it’s better to use simpler roles.

    Recommended roles and attributes:

    • role= "navigation": Declares that this section is a navigation landmark, which helps screen reader users quickly find or skip it.
    • role= "menuitem": If you have interactive items that function like menu items (though for basic links, standard <a> elements might be enough).
    • aria-haspopup= "true": Indicates that a button or link has a submenu.
    • aria-expanded= "false": Tells screen readers if a section is closed. Switch it to true when the submenu opens.

    Labeling and Describing Elements Properly

    Screen readers need helpful labels to convey what the link or button does. If your button opens a “Products” submenu, label it clearly:

    • Use aria-label= "Products Menu" or aria-labelledby=" [ID_of_label]" to associate a descriptive label with the menu.
    • Provide descriptive link text. Instead of “Click here,” use something like “View our latest products.” This helps all users know exactly where the link leads.

    Implementing Accessible Mega Menus with HTML, CSS, and JavaScript

    Using Semantic HTML for Proper Structure

    Below is a simple example showing how to structure an accessible mega menu:

    <nav aria-label= "Main Menu">
  <ul>
    <li><a href="#">Home</a></li>
    <li>
      <button aria-expanded="false" aria-haspopup="true">Products</button>
      <ul>
        <li><a href="#">Product 1</a></li>
        <li><a href="#">Product 2</a></li>
      </ul>
    </li>
  </ul>
</nav>

    Here’s why this works:

    • <nav aria-label= "Main Menu">: The <nav> element is a semantic way to mark the navigation area. The aria-label helps screen readers identify it.
    • <button> vs. <a>: Using a button for expandable menus is more accessible because it’s an interactive element by default and can easily handle the aria-expanded state.
    • aria-expanded: Indicates whether the submenu is open or closed (true or false).

    Styling Menus for Visibility & Interaction

    Accessible styling goes beyond making things “look nice.” It ensures that focus states are clear. For instance:

    nav button:focus {
  outline: 2px solid #005ea2;
  background-color: #f1f1f1;
}
nav ul ul {
  display: none;
}
nav button[aria-expanded="true"] + ul {
  display: block;
}
    • The outline property and background-color change help users see the focused button.
    • By default, submenus are hidden (display: none).
    • When aria-expanded= "true", the submenu appears (display: block).

    Enhancing Usability with JavaScript

    A small amount of JavaScript can make your menus more accessible. Here’s how you can toggle the aria-expanded attribute:

    document.querySelectorAll('nav button[aria-haspopup]').forEach(button => {
  button.addEventListener('click', () => {
    const expanded = button.getAttribute('aria-expanded') === 'true';
    button.setAttribute('aria-expanded', !expanded);
  });
});
    • This code finds every button with aria-haspopup.
    • When clicked, it checks if aria-expanded is currently true, then toggles it.
    • This prevents menus from randomly opening on hover and gives users control.

    Accessible Navigation Is an Ongoing Commitment

    Building an accessible mega menu isn’t a one-and-done project. It takes careful planning, coding, and constant testing to make sure all users can move through your site with ease. However, the payoff is huge: better usability for everyone, including people with temporary or permanent disabilities, and compliance with accessibility standards like WCAG.

    Remember, accessibility benefits everyone. Even a user with a short-term injury or someone on a small mobile device can benefit from keyboard-friendly and screen-reader-friendly menus. By making small changes to HTML, CSS, ARIA attributes, and JavaScript, you can open up your site to a larger audience and provide a smoother experience for all.

    If you need expert guidance on web accessibility or want a thorough audit of your online store, 216digital can help. We specialize in creating inclusive, user-friendly experiences that keep your customers coming back and keep your website on the cutting edge of accessibility best practices. Don’t let your mega menus become mega barriers—start making them accessible today!

    Greg McNeil

    March 11, 2025
    How-to Guides
    Accessibility, accessible code, How-to, mega menu, web developers, web development, Website Accessibility

  • 6 Ways to Improve Icon Accessibility in Web Design

    Icons are everywhere in web design—on navigation menus, buttons, and even instructional graphics. They help users navigate, take action, and understand content at a glance. But just because an icon looks great doesn’t mean it’s effective for everyone. When it comes to creating inclusive websites, icon accessibility is crucial. If an icon is confusing or too small, it can frustrate users, create barriers, and even cost you traffic or conversions. That’s why accessibility and usability should be top priorities.

    In this article, we’ll explore six actionable ways to improve icon design so that your icons are clear, usable, and accessible to all users, including those with disabilities. Whether you’re a website owner, content creator, or web developer, these tips will help ensure your icons work well for everyone, including people with visual, motor, or cognitive impairments.

    1. Make Your Icons Easy to See

    Contrast Matters

    When designing icons, it’s significant that they stand out from the background rather than blend in. The Web Content Accessibility Guidelines (WCAG) recommend a contrast ratio of at least 4.5:1 for text and images of text. Icons, especially those carrying critical information, should meet or exceed this contrast standard.

    Why It’s Important

    Low-contrast icons can be almost invisible to users with vision impairments, complicating navigating or completing tasks on your site.

    How To Do It

    Tools like the WebAIM Contrast Checker can help you confirm that your color choices meet accessibility guidelines. If your background is light, ensure your icons are noticeably darker, and vice versa.

    Size Counts

    Just as crucial as contrast is icon size. Small icons can be a nightmare for users with poor vision or those who rely on assistive technology like screen magnifiers. They can also pose a challenge for people with motor disabilities who struggle to tap or click small icons accurately.

    Recommended size

    Aim for an icon touch target of at least 44×44 pixels. This size gives enough space for a user’s finger or cursor to select the icon without accidentally triggering something else.

    Common pitfalls

    Anything smaller than 24×24 pixels is typically too small to be easily clicked or tapped. If you’re designing for mobile, remember that users’ fingers are bigger than a precise mouse pointer.

    2. Always Pair Icons with Text

    Relying solely on icons can create confusion, especially if your visitors aren’t familiar with certain symbols. A perfect example is the infamous “hamburger menu.” While common in modern design, not everyone recognizes what the three stacked lines represent. By adding a text label, you remove any guesswork.

    Why It’s Important

    Text labels make icons understandable for users who might not recognize specific symbols. They also provide additional context for screen readers, who may not interpret icons alone correctly.

    • Bad example: A search button that shows only a magnifying glass icon.
    • Good example: Pair the magnifying glass icon with the word “Search.” This ensures clarity for everyone.

    Including text labels is a simple but effective step toward better icon accessibility and can drastically improve user experience.

    3. Use Clear, Functional Alt Text

    Alt text (alternative text) plays a vital role in accessibility. It’s a description that screen readers read aloud for users who can’t see the images on a page. Regarding icons, the alt text should describe the icon’s function rather than its appearance.

    • Examples: Bad: alt= “Icon of a house”
    • Good: alt= “Go to homepage”

    If the icon is purely decorative and conveys no essential information, mark it as aria-hidden= "true" or use an empty alt="" to keep screen readers from reading irrelevant content.

    Use Proper Coding Techniques

    Depending on the format of your icon, there are slightly different approaches to ensure screen readers interpret them correctly:

    1. <img> elements → Use the alt attribute, like alt=”Search button”.
    2. SVG icons → Provide a <title> tag within the SVG file or inline code.
    3. Icon fonts → Sometimes, screen readers treat icon fonts as text characters. Use aria-hidden= "true" for the icon itself, and include hidden text (e.g., <span class= "visually-hidden">Search</span>) for accessibility.

    This attention to detail ensures that people using screen readers will know the icon’s function without having to interpret a cryptic or generic description.

    4. Be Consistent with Icons

    Consistency is key in web design, especially regarding icon accessibility. Each icon should have a clear meaning across your entire website or app.

    Why It’s Important

    If you use a magnifying glass icon to indicate “Search” in one area of your site, using the same symbol for “Zoom” somewhere else can confuse users. A confused user is more likely to leave your site or miss important content.

    Avoid Multiple Meanings

    Don’t use one icon to represent more than one function. This can break user trust and make them second-guess every click.

    By keeping your icons consistent, you help users develop familiarity with the symbols on your site. Reducing the cognitive load for everyone, including users with disabilities who rely on screen readers or keyboard navigation.

    5. Make Icons Keyboard & Assistive Tech Friendly

    Some users cannot use a mouse or touchpad and rely solely on their keyboard. Others use assistive technology like screen readers or voice control. Ensuring your icons work with these tools is essential for accessibility.

    Keyboard Navigation

    Every interactive icon should be reachable and operable using only a keyboard. Users should be able to tab to an icon and activate it with the Enter or Spacebar keys.

    • Tips: Use logical tab ordering in your HTML to ensure icons follow a coherent navigation sequence.
    • Ensure focus styles are visible (e.g., a visible outline or highlight around the icon when selected).

    Screen Reader Support

    Icons can easily confuse screen reader users if not labeled correctly. This is where ARIA labels or hidden text come into play. For instance, if an icon triggers a search action, you could include an ARIA label such as aria-label= "Search" on the button element, or you can nest a visually hidden <span> that says “Search.”

    Why It Matters

    Without ARIA labels or hidden text, a screen reader might read the icon as a “button” or, worse, give no information.

    How To Do It

    <button aria-label="Search">
  <svg aria-hidden="true"> ... </svg>
  <span class="visually-hidden">Search</span>
</button>

    Ensure keyboard and screen reader users have the proper context to interact with your icon.

    6. Choose the Right Icon Format

    Icons can be added to a webpage in several ways, but SVG and PNG are two of the most popular image formats. Alternatively, some designers opt for icon fonts. Each has its pros and cons when considering icon accessibility.

    SVG & PNG Are Your Friends

    SVG (Scalable Vector Graphics)

    • Pros: These files are resolution-independent, meaning they scale well to any size without losing quality. They can also be easily styled with CSS and annotated with titles or labels for accessibility.
    • Cons: If you’re unfamiliar with SVG syntax, the setup process can be more involved.

    PNG (Portable Network Graphics)

    • Pros: Excellent for icons that don’t need to scale up drastically. PNGs offer high-quality images with transparency.
    • Cons: They’re not always the best for large or small displays, as they can become pixelated or blurry when scaled.

    Beware of Icon Fonts

    Icon fonts replace letters with symbols, so the text “A” might visually display as a house icon. While this can be convenient, it can create issues for screen readers who might read the text as a letter rather than a graphic. If you use icon fonts:

    • ARIA: Add aria-hidden= "true" to ensure the screen reader ignores the font.
    • Hidden text: Include a visually hidden <span> with the function of the icon, such as “Home” or “Search.”

    By choosing the right format, you help ensure users can see or interact with the icon regardless of their device or abilities.

    Team Up with 216digital for Better Accessibility

    Mastering icon accessibility is more than just following guidelines; it’s about providing an inclusive experience for everyone who visits your website. Clear, intuitive icons can significantly improve your site’s usability, particularly for users who rely on assistive technologies.

    If you’re unsure where to begin or want to ensure accessibility experts handle every detail, consider partnering with 216digital. Our team has extensive experience creating accessible, user-friendly websites that work seamlessly across different devices and for people of all abilities. We’ll help you fine-tune every aspect of your icons, from contrast ratios and alt text to keyboard navigation and consistent design.

    Ready to level up your website’s accessibility? Contact us for a quick briefing and see how we can help strengthen your site’s icon design. Together, we can create a web experience that welcomes everyone, reflecting your brand values and maximizing your reach in a diverse online world.

    Greg McNeil

    February 14, 2025
    How-to Guides
    Accessibility, How-to, Icon Accessibility, web developers, web development, Website Accessibility

  • Creating Accessible Data for Charts and Graphs

    Data drives decisions. A clear and easy-to-understand chart can speak volumes whether you’re showing sales figures, survey results, or scientific findings. However, not everyone interprets visual elements the same way. People with low vision, color blindness, or who rely on screen readers may face serious barriers if your charts aren’t designed with accessibility in mind.

    Beyond inclusivity, legal standards exist like the Americans with Disabilities Act (ADA) and the Web Content Accessibility Guidelines (WCAG). In this post, we’ll explore why accessible data visualizations matter, review common accessibility mistakes, and share practical techniques you can use to ensure that all visitors can understand your charts and graphs.

    Designing for Visual Accessibility

    Color Contrast in Charts and Visualizations

    Color contrast plays a crucial role in readability, especially for users with visual impairments. According to WCAG SC 1.4.3: Contrast (Minimum, the standard text should have a contrast ratio of at least 4.5:1, while large text (18pt or 14pt bold) requires a minimum of 3:1. These guidelines also apply to key chart elements, including labels, axes, and text within visualizations, ensuring that information remains clear and accessible to all users.

    To check your color choices, use tools like WebAIM’s Contrast Checker or Chrome DevTools’ built-in accessibility features. If your text lacks sufficient contrast, consider adjusting to darker text on lighter backgrounds or using bolder, larger fonts. Prioritizing accessible data in your visualizations not only enhances clarity but also improves the user experience for a wider audience.

    Avoiding Color-Only Differentiation

    When a chart relies on color alone to show differences in categories—like red for “loss” and green for “gain”—users with color blindness might not be able to tell them apart. WCAG SC 1.4.1 (Use of Color) emphasizes that color can’t be the only method used to communicate information.

    To fix this, you can:

    • Use patterns or textures in bar charts or pie slices.
    • Add direct labels or annotations next to the data points.
    • Include icons or distinct shapes to differentiate data series.

    Scalability and Zoom Support

    Many people need to zoom in to read small text or fine details. According to WCAG SC 1.4.4(Resize Text), users should be able to zoom up to 200% without losing content or functionality. Test how your charts scale on both desktop and mobile screens. This may involve using scalable vector graphics (SVG) or ensuring your chart library supports responsive resizing.

    Providing Text Alternatives and Descriptive Labeling

    Alt Text for Simple Charts

    For simpler charts—like a basic bar chart comparing two or three items—brief alt text can be enough. This alt text should include the following:

    • The overall trend or purpose of the chart (e.g., “A bar chart comparing monthly sales in January and February…”).
    • Key numbers or comparisons (if they’re crucial to understanding the data).

    Avoid including every detail if it’s not necessary. Alt text is meant to be concise yet informative.

    Breaking Down Complex Data with Text Summaries

    If your chart is more detailed—perhaps showing multiple data series or a longer timeline—alt text alone won’t cover it. In that case, it’s better to provide a text summary that covers the main insights:

    • Describe what the chart is measuring (“Average temperature trends across five cities…”).
    • Highlight any interesting data points or outliers (“City A had a significantly higher temperature in July…”).
    • Provide overall conclusions that help readers understand key takeaways.

    Using ARIA for More Detailed Descriptions

    If a simple alt text or summary doesn’t do your data justice, you can use aria-describedby to link your chart to a more extended description elsewhere on the page. This approach ensures screen reader users have access to more in-depth data without crowding the main alt text.

    When writing these extended descriptions:

    • Keep your text organized with headings or bullet points.
    • Clearly label each section so users know what information they’re accessing.
    • Make sure screen readers can announce the description properly by placing it in a logical spot on the page or using hidden text if necessary.

    Structuring Data Tables for Screen Readers

    Another highly accessible way to present data is through tables. If you can’t convey the full meaning of a chart in alt text, consider adding a well-structured HTML table. Be sure to:

    • Use <th> elements for headers.
    • Include a <caption> that describes the table’s purpose.
    • Provide a summary if the table is complex.

    For example:

    <table>
  <caption>Monthly Sales for Q1</caption>
  <thead>
    <tr>
      <th scope="col">Month</th>
      <th scope="col">Sales ($)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">January</th>
      <td>10,000</td>
    </tr>
    <tr>
      <th scope="row">February</th>
      <td>12,000</td>
    </tr>
    <tr>
      <th scope="row">March</th>
      <td>9,500</td>
    </tr>
  </tbody>
</table>

    Well-coded tables help screen readers identify the rows, columns, and header relationships.

    Making Interactive Charts and Graphs Accessible

    Keyboard Navigation and Focus Management

    If your chart is interactive—allowing filters, tooltips, or zoom functions—it’s crucial that all features are accessible by keyboard alone. This means:

    • Users should be able to tab through each interactive element.
    • The focus order should make sense, moving in a logical sequence.
    • Dropdowns, sliders, or filters must also be operable without a mouse.

    By implementing these best practices, you can guarantee accessible data interactions for all users, including those who rely on keyboard navigation.

    Ensuring Tooltips and Popups are Accessible

    A big challenge is making sure that tooltips triggered by hovering can also be triggered by keyboard actions, like pressing the Enter or Space keys. Also, make sure each tooltip has an accessible name and description so screen readers can announce it properly. WAI-ARIA attributes like role= "tooltip" and aria-hidden= "false" (when the tooltip is visible) can help.

    Using Semantic HTML and ARIA Roles

    Use semantic HTML elements like <svg> for vector graphics where possible. If you’re using <canvas> or more complex libraries, add proper ARIA roles and states so screen readers know how to interpret them. Clear focus indicators are also important so users can see where they are when tabbing through interactive features.

    Choosing Static vs. Interactive Charts

    Interactive charts can be powerful, but they’re not always the best choice for every audience. Sometimes, a well-labeled static chart is more accessible data and easier to understand. If you have users who need data quickly and without extra steps, offering both a static image and an interactive version can meet multiple needs.

    Selecting and Adapting Chart Types for Accessibility

    Accessible Bar Charts

    Bar charts are among the easiest to make accessible, as long as you:

    • Clearly label each bar.
    • Use more than color to differentiate bars—consider patterns or direct labeling.
    • Provide a descriptive axis label so users know what each bar represents.

    Accessible Line Graphs

    Line graphs can be tricky for those with low vision. To improve accessibility:

    • Use different line styles (solid, dashed, dotted) to distinguish multiple data sets.
    • Add shape markers at each data point so color-blind users can still tell them apart.
    • Make sure your axes and legends are clear, with sufficient contrast.

    Accessible Pie Charts

    Pie charts can be confusing when there are too many slices. Limit your chart to a small number of slices and label each piece directly. Also, add patterns or textures if you use color coding. If your data is too complex, think about using a different format, like a table or bar chart.

    Handling Complex Data Visualizations

    If your data is large or contains many variables, consider breaking it down into smaller charts. This approach, called “small multiples,” allows users to compare data across several simpler charts rather than one overwhelming visualization. Include thorough text explanations and summaries to give context and help users understand the bigger picture.

    Advanced Accessibility Techniques for Charts and Data Displays

    Providing Multiple Data Views

    Not everyone can interpret data in the same way, so offering a toggle between a chart view and a table view can be extremely helpful. For example, you could have a button labeled “Show Data as Table” that, when clicked, reveals an accessible HTML table with the same information.

    Supporting Screen Readers with Data Annotations

    For charts that update in real-time—like stock price tickers—add announcements with ARIA live regions if something significant changes. This way, screen reader users will be notified when new data appears, but be careful not to overload them with constant updates.

    Making Dynamic and Real-Time Data Accessible

    Real-time data can be challenging because it often changes so frequently. Focus on essential changes and clearly label them. If you’re running live dashboards or analytics that refresh, allow users to control the refresh rate or pause the updates. This helps users keep track of what’s changed without confusion.

    Testing and Validating Chart Accessibility

    Manual Testing with Assistive Technologies

    Always test your charts using real assistive tools such as:

    • Screen readers like  NVDA, JAWS, or VoiceOver.
    • Keyboard-only navigation for all interactive elements.

    This hands-on testing helps you catch issues that automated checkers might miss, like poor focus order or unannounced chart labels.

    Automated Testing Tools

    Tools like WAVE Accessibility Checker and Lighthouse’s Accessibility Audit in Chrome can highlight potential problems. However, automated tools can only find about 30% of accessibility issues, so don’t rely on them alone.

    User Testing and Real-World Validation

    Finally, the best way to confirm that your data visualizations are truly accessible is to test them with actual users who rely on assistive technology. Gather feedback and be prepared to iterate on your design. Accessibility is an ongoing process that benefits greatly from real-world input.

    Creating Data-Driven Experiences for All Users

    Inclusive data visualizations aren’t just a courtesy—they’re the key to truly understanding and acting on the information that drives our businesses, classrooms, and communities. By deliberately designing charts and graphs that everyone can parse, you’re ensuring your message resonates with the widest possible audience. You’re also upholding the principles of equality, transparency, and innovation that propel the web forward.

    Start your journey toward full web accessibility today—reach out to 216digital using the form below! Our team of accessibility experts is ready to assess your site and provide tailored solutions to ensure that all visitors can easily access your content.Don’t let accessible data remain an afterthought—take the first step toward a more inclusive online presence now.

    Greg McNeil

    February 12, 2025
    How-to Guides
    Accessibility, Accessible Data, How-to, Web Accessibility, web developers, web development, Website Accessibility
Previous Page
1 2 3 4 5
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.