web developers Archives /Tag

Who Needs Web Accessibility Training?
Think about all the hands that shape a website before it goes live.

A designer sketches the layout. A content writer crafts the story. A developer brings it to life. A marketer promotes it. A project manager keeps the wheels turning. But if even one person in that chain doesn’t understand the basics of accessibility, the final experience can fall short for someone trying to navigate with a screen reader, keyboard, or other assistive tools.

Accessibility issues don’t usually happen because people don’t care—they happen because people don’t know what to look for. That’s why accessibility training isn’t just for developers or tech teams. It’s for everyone who shapes the digital experience—from strategy to support.

When teams understand their role, accessibility becomes part of the process—not a last-minute fix. And that’s when real progress begins.

Why Broader Accessibility Training Matters

Accessibility barriers often hide in plain sight. A confusing heading can trip up a screen reader. An auto‑playing video can trap a keyboard user. Each issue might start with a different team, so solving them requires shared awareness and a shared skill set.

When every role learns the basics, good habits form early. This lowers future repair costs, speeds up projects, and reduces legal risk. Just as important—it sends a clear message: “Our doors are open to everyone.”

Who Should Learn—and What They Need to Know

Here’s how accessibility training benefits each team involved in your digital presence.

1. Executives and Senior Leaders

What they do: Set vision, approve budgets, choose partners.

Why they train: Training helps leaders connect accessibility to results—larger audiences, stronger brand trust, and measurable ROI. They also learn how setting clear goals and timelines keeps inclusion on track.

2. Designers and UX Teams

What they do: Choose colors, type, layouts, and flows.

Why they train: Design choices determine whether text is readable, buttons are reachable, and flows make sense. Training covers contrast, consistent icon labels, logical headings, and visible focus indicators.

3. Developers and Engineers

What they do: Write and test code.

Why they train: Developers learn how to apply semantic HTML, ARIA roles, keyboard support, and accessible error handling. Even seasoned coders benefit from updated WCAG guidance and modern tooling.

4. Content Creators and Editors

What they do: Write blog posts, help articles, PDFs, and product pages.

Why they train: Clear headings, plain language, and helpful alt text transform raw info into inclusive content. Training includes quick checks for reading level, link clarity, and captioned media.

5. Marketers and Social Media Managers

What they do: Create campaigns, videos, landing pages, and emails.

Why they train: Marketing moves fast, and small oversights spread wide. Training ensures captions are added, visuals are described, and flashing graphics are avoided—protecting both reach and user safety.

6. Quality‑Assurance Testers

What they do: Validate features before launch.

Why they train: QA staff learn how to run both automated scans and manual checks with keyboards and screen readers. Catching issues here prevents costly post-launch fixes.

7. Product and Project Managers

What they do: Gather requirements, plan sprints, and manage scope.

Why they train: They learn to include accessibility in acceptance criteria and timelines, and track progress against WCAG standards—making sure nothing slips through.

8. Customer Support Teams

What they do: Handle questions and feedback.

Why they train: Support agents are often the first to hear about accessibility barriers. Training helps them log issues clearly, guiding meaningful improvements.

Building a Culture of Learning

Workshops are a great start—but lasting accessibility comes from weaving training into everyday workflows. Here’s how to keep that momentum alive:
- Start with a quick win: Host a one‑hour session on headings and alt text. Immediate impact builds confidence.
- Use role-based paths: Designers explore contrast and layout. Marketers focus on captions and social media accessibility.
- Pair training with checklists: A simple “before you publish” list—contrast, keyboard reach, captions—keeps lessons at the top of your mind.
- Bring in real users: Invite people with disabilities to demos. Live feedback drives empathy and makes the value of inclusive design unmistakable.
- Celebrate success: Recognize teams that close accessibility tickets or launch inclusive content.
Choosing the Right Accessibility Training Format

Not everyone learns the same way. Mix formats to meet your team’s needs:
- Live workshops: Great for Q&A and real-time practice.
- Short video modules: Ideal for busy schedules or quick refreshers.
- Office hours: Open sessions where experts answer questions from any team.
- Documentation hubs: Centralized space for checklists, coding samples, and brand guidelines.
Larger organizations may also benefit from certification tracks or external mentors to support deeper learning and audits.

Measuring Success

Track the impact of training to keep improving:
- Fewer accessibility issues during QA.
- Lower remediation costs thanks to early awareness.
- Positive user feedback from screen reader and caption users.
- Fewer legal notices or compliance complaints.
Quarterly progress reports help leadership see the value and maintain support.

Overcoming Common Roadblocks
- “We don’t have time.” Break accessibility training into 15-minute micro-lessons that fit between meetings.
- “We can’t teach everyone everything.” Focus on essentials for each role—developers need ARIA, executives don’t.
- “It sounds too technical.” Share real stories. A single form label can help both a low-vision user and someone filling it out in bright sunlight.
Getting Started: A Quick Action Plan
1. Audit your team’s skills. Survey knowledge gaps.
2. Create a roadmap. Start with high-impact roles.
3. Choose a learning partner. Consultant, online platform, or internal champion.
4. Launch a pilot session. Start with something approachable, like image alt text.
5. Review and refine. Gather feedback and evolve your approach.
When people know what to look for, accessibility becomes second nature—not a scramble.

Equip Your Team, Elevate Your Experience

A successful accessibility program isn’t powered by one expert—it’s built on shared understanding. The more your teams know, the more they can contribute to inclusive, compliant, user-friendly experiences from the very beginning.

Now’s the time to turn knowledge into action. Whether you’re setting strategy, designing experiences, writing content, or launching campaigns, accessibility training helps each role identify where inclusion starts—and how to make it stick.

Accessibility Training That Moves Teams Forward

At 216digital, we include complementary ADA training with every project because we believe that lasting accessibility starts with alignment. Our role-based approach ensures your team isn’t just meeting requirements—they’re embedding inclusion into design, development, and communication with confidence.

Ready to move forward? Schedule a personalized ADA briefing with us. We’ll help you map out your goals, identify key opportunities, and launch a training strategy that’s effective, affordable, and built to last.

The most accessible experiences are the ones designed with intention. Let’s help your team build them.
Greg McNeil

April 17, 2025

Web Accessibility Training

Accessibility, Accessibility Training, Marketer, Web Accessibility Training, web developers, 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
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
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
When Is a Skip Link Needed?
We’ve all been on websites that greet us with massive headers, menu bars crammed full of links, or flashy ads stretching across the top. With a mouse, you can scroll or click straight to the section you care about. But if you rely on a keyboard, you’re stuck tabbing through every link and button in that menu before you reach the main story. It can feel like trudging through a maze when you just want to dive into the content.

A skip link offers a simple shortcut: it lets keyboard users jump over that repeated stuff and land exactly where they need to be. In this article, we’ll explore how skip links fit into the Web Content Accessibility Guidelines (WCAG), why they matter for anyone who doesn’t browse with a mouse, and how they can make a site more enjoyable for all visitors—even the ones who love to scroll.

What Is WCAG’s Bypass Blocks Rule?

WCAG’s Success Criterion 2.4.1, known as “Bypass Blocks,” focuses on letting users skip past content that appears on every page, such as headers, navigation menus, and sidebars. These areas can become barriers for people who rely on keyboard navigation or use screen readers, since they have to listen to or Tab through every link each time they land on a new page.

Mouse users can ignore repeated elements by moving their cursor directly to the main section of the page. But if you are using a keyboard only, you have to press the Tab key multiple times to get beyond the menu or header. This extra effort can be frustrating. By contrast, a skip link makes it possible to jump straight to the main content with a single press of the Tab key and an Enter or Space to activate it. Cutting down on keystrokes is a big boost to usability and can remove physical strain for users with motor disabilities.

Do Landmarks and Headings Count as Bypass Tools?

Some people think that WCAG’s requirements force you to include a skip link no matter what. However, WCAG does not specifically demand that you place a “Skip to Main Content” link on your pages in every scenario. If you use proper HTML5 sectioning elements like <main> or set up ARIA landmarks with role= "main", you can fulfill the technical requirement.

When you use clear heading structures (<h1>, <h2>, etc.) and assign landmarks (role= "navigation", role= "banner") to your layout, many screen readers allow users to jump from one landmark or heading to another. This means they can skip large chunks of repeated content. However, there is a key drawback: these landmark shortcuts are tied to assistive technology. Keyboard-only users without a screen reader do not benefit from these features, because landmarks are not accessible through simple keystrokes like Tab. That is where a skip link proves especially helpful, providing an obvious and direct way to move focus into the main content.

Why a Skip Link Is Still Best Practice

Even if you are technically compliant with WCAG, many experts still recommend a skip link. Here’s why:
1. Keyboard-Only Users: Landmarks may help screen reader users, but they are not available to someone who only has a keyboard. A skip link is the only direct and reliable way to jump over repetitive elements.
2. Users with Motor Disabilities: Each extra keystroke can cause strain. Reducing the need to press Tab repeatedly makes it easier for people with limited mobility to explore your site.
3. Users with Cognitive Disabilities: Repeated menus and banners can be visually overwhelming and distracting. A skip link streamlines the experience by letting users focus on the main content faster.
Other Tools That Help With Page Navigation
- Provide a Skip Link: A short text-based link such as “Skip to Main Content” at the top of the page is a universal solution.
- Use HTML Sectioning Elements: Properly labeling <header>, <main>, and <footer> can help screen reader users identify page sections.
- Implement a Logical Heading Structure: When headings form a clear outline, it is easier for people to scan or jump to key areas, especially when assistive technology is involved.
Alternative Navigation Aids

While a skip link is vital, it’s not the only accessibility tool you can use. ARIA landmarks, for example, let you define elements like role= "navigation", role= "banner", or role= "main". Screen readers can use these roles to move focus to each region. Another strategy is to include access keys, which assign keyboard shortcuts to major parts of your site. Yet, these approaches are typically helpful only to those who know how to use them and have compatible assistive technology. For most keyboard users, a skip link remains the clearest and simplest tool.

How to Add a Skip Link the Right Way

A skip link should do more than just jump down the page; it needs to work with the keyboard in a smooth way. Here’s how:

Position the Link as the First Focusable Element

The best practice is to place the skip link at the very top of your page. This ensures it is the first element that gets focus when someone tabs through the page. A common method is to link to the main content area, marked by an ID like id= "main-content".

Ensure Proper Keyboard Functionality

When users activate the skip link, focus should land right on the main content area. For this to happen, that target element must be focusable. If <main> or the first heading is not normally focusable, you can add tabindex= "-1" to make it work. This step also helps users who use screen magnifiers, because the focus moves right to the main section visually.

Example:
```
<a href="#main-content">Skip to Main Content</a>


<main id="main-content" tabindex="-1">
    
</main>
Or, if you want to move focus to the first heading:
<a href="#first-heading">Skip to Main Content</a>


<h1 id="first-heading" tabindex="-1">Welcome to Our Site</h1>

```
Ensure the Skip Link Is Visible When Focused

Many designers hide the skip link until it gains focus. While this can keep the page looking tidy, it’s important that the link is fully visible and noticeable the moment someone tabs onto it. This visibility ensures that keyboard users know there is a helpful tool available. In some designs, leaving the skip link in plain sight all the time may be the best approach.

Mistakes to Avoid With Skip Links

Even if you add a skip link, a few errors can stop it from working as intended:
- Improper Hiding Techniques: If you use display: none; or visibility: hidden;, screen readers will not detect the link at all. Instead, use off-screen positioning so it remains accessible.
- Non-Focusable Targets: Forgetting to add tabindex= "-1" to the target means the user might land near the content but not actually focus on it. This can confuse people using screen readers or screen magnifiers.
- Skipping Too Much Content: Your skip link should jump over repeated menus, but it should not force users to skip crucial information, like an important heading that explains the page’s purpose.
Check That Your Skip Link Actually Works

Testing makes sure your skip link works well:
1. Keyboard Testing: Turn off your mouse and try to navigate the site by tapping through. Watch for the link to show up, and check that it drops you into the main area.
2. Assistive Technology Testing: Use a screen reader to confirm that your skip link is announced and that it moves focus correctly.
3. Cross-Browser Compatibility: Test in different browsers (Chrome, Firefox, Safari, Edge) to confirm that the skip link behaves the same everywhere.
Make Navigation Easy for Everyone with 216digital

Including semantic elements and ARIA landmarks can make your site meet the minimum requirements of WCAG, but offering a dedicated skip link goes a step further by improving usability for keyboard-only users, people with motor disabilities, and users who may become overwhelmed by repeated menus. Rather than viewing accessibility as a set of rules to follow, think of it as a way to create a smoother, more welcoming experience for all.

If you want a site that not only checks the compliance box but also feels inclusive to every visitor, consider working with a partner who understands the importance of thoughtful navigation. At 216digital, we specialize in designing web experiences that work for everyone. A skip link may seem like a small touch, but it can make a world of difference for those who need it. Let’s make the web more inclusive together.
Greg McNeil

March 21, 2025

How-to Guides

skip link, WCAG, WCAG conformance, web developers, web development
Getting Focused: Why Focus Order Matters for Web Accessibility
Most people never think about what it would be like to navigate a website without using their mouse. This is a reality for many users with visual or motor impairments. They rely on using other input modalities, such as the keyboard or gestures, to navigate a web page. This is where focus order comes into play.

In this post, we’ll look at what focus order is, why it’s so important, how it connects to the Web Content Accessibility Guidelines (WCAG), and the most common issues you’ll want to fix. Then, we’ll share a few tips on how to test and improve it on your own site.

Life Without a Mouse

Picture going through your favorite website using only your keyboard. You press Tab to jump from one link or button to another. If the focus order is set up right, you’ll move through the page in a smooth, logical sequence, usually from top to bottom. But if it’s not, you could land somewhere unexpected or miss entirely essential parts of the page.

For anyone who can’t use a mouse, a messed-up focus order often leads to frustration. Improper focus order can lead to the cursor jumping around the page illogically or preventing them from using necessary functionality.

Avoiding Common Pitfalls
1. Skipping Interactive Elements: If a link or button is not coded using the proper semantic HTML tag or does not have the correct attributes, it will not be focusable at all, and users who can’t use a mouse will be unable to interact with the element.
2. Jumping in Strange Ways: If you rely on random tabindex values or a messy HTML structure, the focus may go from the header to a random footer link before bouncing back up. That’s tough to follow.
3. Getting Trapped: Pop-ups, modals, and iframes can trap keyboard users if the code doesn’t let them tab out. People might get stuck until they refresh the page.
4. Invisible Focus: Many designers, developers, or store owners choose to hide the focus outlines for aesthetic purposes without realizing how many people rely on them to navigate the site. Without visible focus outlines, motor-impaired users have no idea which element is currently focused on or selected.
The WCAG Connection

Focus order plays a key role in meeting the standards laid out in WCAG. Some of the main ones include:
- 2.4.3 (Focus Order, Level A): Content should follow a logical order when tabbing through the page.
- 2.1.1 (Keyboard, Level A): All site functions should work with only a keyboard.
- 2.4.7 (Focus Visible, Level AA): People should see which element is active at all times.
- 2.4.11 & 2.4.12 (Focus Not Obscured, WCAG 2.2, Levels AA & AAA): The focused element has to remain visible instead of scrolling off-screen.
Meeting these criteria helps make sure your site is accessible and much easier to navigate.

Simple Tips to Get It Right
- Use the DOM Order: Write your HTML in the order you want people to move through the page. That way, you don’t have to force things with unique attributes.
- Use Correct Elements: If you have something clickable, make it a <button> or <a>. This makes it automatically focusable without extra work.
- Be Careful With tabindex: tabindex= “0” can help include an element in the natural focus sequence. tabindex= “-1” keeps something out of the normal flow but still lets you focus there with scripts. High or random values can create chaos.
- Manage Modals Properly: When a modal pops up, focus should jump into it. People should be able to tab around inside and close it without getting stuck. Once it’s closed, the focus should return to the element that opened it.
- Keep Focus Visible: If your brand style doesn’t match the default outline, customize it with a high-contrast border or box-shadow. Whatever you do, make sure people can still see where they are on the page.
Testing and Tweaking Your Site
1. Manual Testing – Put your mouse away and try tabbing through the page. Ask yourself if the order makes sense and if you can reach everything you need.
2. Browser Tools – Chrome DevTools and Firefox Accessibility Inspector can show you how each element appears in the accessibility tree, which can help you spot weird focus flows.
3. Automated Tests – Tools like WAVE and Lighthouse are helpful for flagging fundamental problems, though they won’t catch everything.
4. Real Users – If possible, ask people who rely on keyboard navigation to test your site. They’ll be the quickest to notice focus issues you might miss.
Wrapping Up

Focus order might sound like a small detail, but it’s a massive deal for those who rely on the keyboard to get around. A logical, precise tab sequence helps keep your site user-friendly, no matter who’s visiting. If you’re worried about your site’s accessibility, it’s never too late to run an audit or refresh your code.

Need extra help? Contact 216digital, where we specialize in creating accessible websites that work well for everyone. Whether you just need a quick review or a complete accessibility plan, we’re here to make your site feel welcoming for all kinds of users.
Greg McNeil

March 19, 2025

How-to Guides, WCAG Compliance

focus order, WCAG, WCAG conformance, web developers, web development
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
Keyboard Accessibility: A Guide for Web Developers
Think about the last time you visited a website with a complex menu or a long list of links. If you tried navigating without a mouse—maybe because you found it faster to use the Tab key—you might have encountered invisible outlines, a random tab order, or even getting stuck in a popup with no clear way out. These problems highlight why keyboard accessibility is essential.

When websites are built so that every button, link, and form field is accessible via keyboard, it becomes easier for everyone to navigate and complete tasks.

What Is Keyboard Accessibility?

At its core, keyboard accessibility ensures that everything on a website can be reached and used without a mouse. This is crucial for people with motor impairments who rely on keyboards or assistive devices, as well as users with visual impairments who navigate with screen readers. Even power users benefit, often finding keyboard shortcuts and navigation faster than using a mouse.

Beyond improving usability, proper keyboard accessibility leads to better-organized code and a more logical page structure—benefits that search engines reward with better SEO rankings. Simply put, improving keyboard accessibility benefits both users and website owners. However, achieving it comes with challenges.

Common Keyboard Accessibility Challenges

Despite its importance, keyboard accessibility is often overlooked. Many websites suffer from poor focus visibility, illogical tab orders, and keyboard traps that frustrate users. Addressing these pitfalls is key to creating a smooth, user-friendly experience.

Below are three of the most common keyboard accessibility issues—and how to fix them.

1. Designing Effective Focus Indicators

Focus indicators visually highlight which element is currently selected when navigating with a keyboard. They help users track their position as they move through a webpage using the Tab key.

Why Focus Indicators Matter

Imagine navigating a website solely by keyboard. If you press Tab but can’t see where you are because the focus highlight is too faint—or missing altogether—you’re left guessing. This creates confusion and frustration. Clear, high-contrast focus indicators ensure users always know where they are on the page.

Best Practices for Focus Indicators
- Outline thickness: At least 2 CSS pixels
- Outline offset: Keep at least 2 CSS pixels between the outline and the element’s edge
- Contrast ratio: A minimum of 3:1 between the focus indicator and the background
Understanding the :focus-visible Pseudo-Class

The :focus selector applies styles whenever an element gains focus, including when it’s clicked with a mouse. But :focus-visible applies focus styles only when an element is navigated via keyboard, keeping the interface clean for mouse users while ensuring keyboard users get clear visual cues.

Example:
```
*:focus-visible {
  border: 2px solid black; /* Ensure noticeable contrast */
  outline-offset: 2px;
}
```
2. Maintaining a Logical Navigation Order

Users navigate websites sequentially using the Tab key. The focus order should match the visual layout to avoid confusion. A mismatch disrupts the browsing experience, making it difficult for users to predict what comes next.

Tips for Logical Navigation
- Use proper HTML structure: Semantic elements like headers (<h1> – <h6>), lists, and landmarks guide screen readers and browsers to interpret content correctly.
- Avoid positive tabindex values: Manually setting a positive tabindex can force elements into an unnatural order, leading to confusion.
- Provide “Skip to Main Content” links: These allow users to bypass repetitive navigation and jump straight to the main content.
- Beware of keyboard traps: Ensure users can always navigate away from popups, modals, or embedded elements using only the keyboard.
3. Proper tabindex Implementation

The tabindex attribute controls how elements receive focus. While useful in some cases, it’s often misused.

What tabindex Does
- tabindex="0": Inserts the element into the default tab order based on its position in the DOM. Ideal for custom interactive elements like <div> buttons.
- tabindex="-1": Removes an element from sequential keyboard navigation but allows focus via scripting. Useful for modals or hidden elements.
- Positive values (e.g., tabindex="1"): Best avoided, as forcing a custom order can break the expected tab sequence and frustrate users.
Best Practices
- Use semantic HTML (<button>, <a>), which is naturally keyboard-accessible.
- Avoid adding tabindex to non-interactive elements like text or static images.
- Use negative tabindex for hidden or modal content that should only receive focus under certain conditions.
- Stick to the natural tab order whenever possible—custom focus orders should be a last resort.
Testing Your Website’s Keyboard Accessibility

Even with best practices in place, testing is essential to catch issues before they impact users. A combination of manual and automated testing provides the most reliable results.

Manual Testing
- Navigate using only a keyboard: Use the Tab key to move through all interactive elements. Press Enter (or Space) to activate buttons and links.
- Check focus visibility: Ensure focus indicators are always clear and meet contrast requirements.
- Verify logical tab order: Does the sequence make sense based on how someone would naturally read or navigate your page?
- Watch for keyboard traps: Ensure modals, dropdowns, and embedded content allow users to navigate away freely.
Automated Testing Tools

Browser-Based Tools
- Firefox Accessibility Inspector: Displays how the browser interprets focusable elements.
- Chrome DevTools (Accessibility Panel): Helps analyze the site’s structure.
- WAVE Evaluation Tool: Flags potential accessibility issues directly in the browser.
While these tools are powerful, nothing replaces real user feedback. Testing with people who rely on keyboard navigation often reveals hidden issues automated tools miss.

Conclusion

Keyboard accessibility is a fundamental part of inclusive web design. Making sure users can navigate your site without a mouse ensures better usability for everyone—including people with disabilities who rely on keyboard navigation. Plus, it improves SEO, usability, and compliance, making it a win-win for both users and businesses.

The best practices covered here—such as customizing focus indicators, maintaining a logical tab order, and using tabindex responsibly—are essential steps toward a more accessible website. Regular testing, both manual and automated, helps ensure your site meets WCAG guidelines and delivers a smooth experience for all users.

For expert guidance, consider working with accessibility professionals like 216digital. Specialists can help you implement strategies that go beyond basic compliance, ensuring long-term usability and inclusivity. When you prioritize keyboard accessibility, you create a more welcoming web for everyone—and that’s a goal worth striving for.
Greg McNeil

March 13, 2025

How-to Guides

Accessibility, keyboard accessibility, Keyboard Navigation, tabindex, Web Accessibility, 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

Why Broader Accessibility Training Matters

Who Should Learn—and What They Need to Know

1. Executives and Senior Leaders

2. Designers and UX Teams

3. Developers and Engineers

4. Content Creators and Editors

5. Marketers and Social Media Managers

6. Quality‑Assurance Testers

7. Product and Project Managers

8. Customer Support Teams

Building a Culture of Learning

Choosing the Right Accessibility Training Format

Measuring Success

Overcoming Common Roadblocks

Getting Started: A Quick Action Plan

Equip Your Team, Elevate Your Experience

Accessibility Training That Moves Teams Forward

Unpacking aria-describedby

Why It’s Important

When Should You Use aria-describedby?

When Not to Use It

Code Walkthroughs: Real-World Examples

Form Fields

Password Requirements

Error Messages

Multiple Descriptions

Buttons

Destructive Action Explanation

Dialogs and Modals

Accessible Dialog

Tooltips and Live Regions

Accessible Tooltip

Status Messages

Common Mistakes to Avoid

Best Practices for Effective Implementation

Beyond the Code: Organizational Tips

Accessible Descriptions, Better UX

Why Accessibility Matters in E-Commerce

Making Your Shopping Cart Work for Everyone

Add Clear Labels (Yes, Even for Buttons)

Let People Update Cart Items Without Guesswork

Show Helpful Feedback When Things Go Wrong

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

Use Straightforward, Consistent Labels

Make Sure Users Can Tab Through Fields Logically

Show Errors Clearly and Offer Suggestions

Designing a Payment Flow That’s Smooth and Inclusive

Offer More Than One Way to Pay

If You Use CAPTCHAs, Make Them Accessible

Choose Accessible Payment Gateways

Don’t Let Product Filters Be a Barrier

Make Filters Keyboard-Friendly

Let Users Know What Filters Are Applied

Stick to Native HTML Controls When Possible

Testing and Validating Your Work

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

Test Manually with Real Assistive Tech

Get Feedback from Real Users

Small Fixes, Big Impact

Why Accordion Accessibility Matters

The Building Blocks of an Accordion Accessibility-Friendly Component

1. Structure: Header and Panel

Header (Trigger)

Panel (Content)

2. Keyboard Navigation

3. Use Semantic HTML

Best Practices for Accordion Accessibility

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

4. Implementing ARIA Attributes

ARIA Attributes for Accordion Accessibility

Implementation Examples

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

Pros

Cons

Option 2: Custom JavaScript Accordion with ARIA

HTML Structure

JavaScript snippet

Best Practices to Keep in Mind

Testing Accessibility

Final Thoughts

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

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

Understanding the `:focus-visible` Pseudo-Class

3. Proper `tabindex` Implementation