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
  • 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
  • Why No ARIA Is Better Than Bad ARIA

    It’s tempting to think of ARIA (Accessible Rich Internet Applications) as the one-stop solution for all your accessibility needs. After all, ARIA exists to help developers create web content that works better for people who use assistive technology, like screen readers. But here’s the catch: if you misuse ARIA—or in places where it isn’t needed—you can end up making your site less accessible, not more.

    This post will explain why semantic HTML should always be your go-to approach, when and why ARIA is beneficial, the most common ARIA mistakes, and best practices for getting it right. By the end, you’ll see how “less is more” often applies to ARIA and why sticking to native elements can save you—and your users—a lot of trouble.

    What Is ARIA (and Why Does It Matter)?

    ARIA stands for Web Accessibility Initiative – Accessible Rich Internet Applications. Created by the World Wide Web Consortium (W3C), ARIA provides a set of roles, states, and properties that help assistive technologies (like screen readers) understand the meaning and function of different elements on a webpage. It’s beneficial for complex or dynamic interfaces that native HTML elements don’t fully cover—such as custom sliders or tab interfaces.

    However, the real power of ARIA depends on how it’s used. Applying ARIA roles in the wrong places or mislabeling states can lead to confusion and errors. Users relying on screen readers might hear incorrect information about what’s on the page or even miss out on essential controls. If you’re not cautious, you could do more harm than good.

    Why Semantic HTML Should Be Your First Choice

    Before jumping into ARIA, remember that semantic HTML is the foundation of accessible web design. Native elements, like <header>, <nav>, <button>, and <footer>, come with many built-in features that screen readers and other assistive tools already understand.

    What is Semantic HTML?

    It refers to HTML elements that clearly describe their meaning. For instance, a <nav> element signals that it contains navigation links. A <button> says, “I’m something clickable!” to both users and screen readers.

    Why Does it Matter?

    When you use semantic elements, you’re using markup that browsers and screen readers know how to interpret. This often means you don’t need ARIA at all—because everything is already handled for you.

    Real-world Example

    If you need a button, just use <button> instead of a <div> with role= "button". Screen readers automatically identify a <button> as a button, while a <div> is just a generic container. Adding a role= "button" to that <div> can work, but it’s extra code and is often less reliable than using a <button> in the first place.

    By relying on these built-in elements, your code is simpler and more intuitive. You’re also less likely to cause confusion when you mix ARIA roles with native roles.

    When (and Why) ARIA Is Actually Needed

    So, if semantic HTML is so powerful, why do we have ARIA at all?

    Filling the Gaps

    HTML is great, but it’s not perfect. Some interactive elements—like complex sliders, tab panels, or sortable tables—aren’t natively supported (or are only partially supported) by standard HTML tags. ARIA helps fill in these gaps by providing additional metadata.

    Roles, States, and Properties

    ARIA is split into three main categories: roles (what is this thing?), states (what is its current condition?), and properties (how does it behave?). These allow screen readers to give users a clearer picture of what’s happening on the page.

    Example: Tabs and sliders

    If you’re building a tab interface from scratch, you might rely on a series of <div> elements. You’d need ARIA attributes like role= "tablist", role= "tab“, and role= "tabpanel", plus properties like aria-selected= "true" or aria-hidden= "true" to show which tab is active.

    Ultimately, ARIA becomes crucial when the default HTML elements don’t cover the level of interactivity or complexity you need. That might be a custom widget or a specialized interface that doesn’t map neatly to existing HTML tags.

    The Most Common ARIA Mistakes (and Why They’re a Problem)

    Misusing Roles

    Sometimes, developers add ARIA roles to elements out of habit, without stopping to see if the native element would have worked better. If you set role= "button" on a <div>, you must also manually manage keyboard interactions and focus states. If you don’t, assistive technology users may be unable to click or navigate to this “button” effectively.

    Example

    <!-- Not so good -->
    <div role="button" tabindex="0" onclick="doSomething()">
      Click me
    </div>
    
    <!-- Better -->
    <button onclick="doSomething()">Click me</button>

    Using a <button> means you get keyboard focus, click events, and screen reader recognition by default—no extra ARIA or scripting needed.

    Redundant or Conflicting Roles

    Many elements come with built-in roles. A <nav> element is understood as “navigation,” and a <ul> is understood as a list. If you add role= "navigation" to a <nav>, you’re restating something already known. In some cases, overriding a native role with a custom role can even interfere with how assistive technologies interpret the element.

    Example

    <!-- Not so good -->
    <nav role="navigation">
      <!-- Navigation links here -->
    </nav>
    
    <!-- Better -->
    <nav>
      <!-- Navigation links here -->
    </nav>

    Here, adding role= "navigation" is unnecessary and could create confusion in some tools.

    Incorrect State Management

    ARIA states, like aria-expanded or aria-checked, must accurately reflect the element’s real condition. If your dropdown menu is closed but you have aria-expanded= “true”, a screen reader user will hear that the menu is open—even though it isn’t. This mismatch can be very disorienting.

    Example

    <!-- Not so good: says it's expanded when it's actually closed -->
    <button aria-expanded="true" onclick="toggleMenu()">Menu</button>
    
    <!-- Better: toggle the value dynamically with JavaScript -->
    <button aria-expanded="false" onclick="toggleMenu()">Menu</button>

    Make sure your script updates aria-expanded to reflect the actual state of the menu (true when open, false when closed).

    ARIA Overload

    Adding too many ARIA attributes can clutter the information that screen readers must process. For instance, overusing aria-live regions can cause screen readers to constantly read out changes that might not be important. This can frustrate users and cause them to miss critical content.

    Example

    <!-- Not so good: multiple live regions announcing frequent updates -->
    <div aria-live="polite">Update 1</div>
    <div aria-live="polite">Update 2</div>
    <div aria-live="polite">Update 3</div>
    
    <!-- Better: only announce genuinely important changes -->
    <div aria-live="polite" id="importantUpdates"></div>
    

    If you really need to announce multiple updates, try grouping them or letting users opt-in.

    Misusing aria-hidden

    aria-hidden= "true" tells screen readers to ignore an element. If you add this attribute to interactive content—like a button, form field, or link—you’re effectively locking out users who rely on assistive tech.

    Important: Hiding something visually is not always the same as hiding it from screen readers. Don’t use aria-hidden if the content is still necessary for some users.

    Example

    <!-- Not so good: Interactive element is hidden from screen readers -->
    <button aria-hidden="true" onclick="doSomething()">Buy Now</button>
    
    <!-- Better: If you need to hide it visually for some reason, do so with CSS,
         but keep it accessible to screen readers. -->
    <button class="visually-hidden" onclick="doSomething()">Buy Now</button>

    (“Visually hidden” classes typically hide elements from sighted users but keep them available to assistive tech.)

    Why “No ARIA” is Often the Best Choice

    The golden rule is this: bad ARIA is worse than no ARIA at all. Why? Because at least with no ARIA, the user experience reverts to the default behaviors of native HTML, which assistive technologies are designed to understand. But if you add incorrect ARIA roles or states, you can mislead screen readers entirely.

    In many cases, the standard HTML element does everything you need. By default, a <button> is keyboard-accessible, announces itself as a button, and can have an accessible label. Adding role= "button" to a <div> only means more overhead for you and possibly less clarity for users.

    Best Practices for Using ARIA the Right Way

    Use Native HTML First

    Always check whether you can use a built-in HTML element. This approach is simpler to code, more reliable, and better for accessibility out of the gate.

    Example

    Instead of:

    <div role="button" tabindex="0">Submit</div>

    Use:

    <button>Submit</button>

    No extra attributes, no confusion—just a straightforward button.

    Be Precise with Roles and States

    If you must use ARIA, choose the exact role that matches the purpose of your element. Also, keep an eye on the current state—like aria-expanded, aria-checked, or aria-selected—and update it only when something changes.

    Example

    <button aria-expanded="false" aria-controls="menu" onclick="toggleMenu()">Menu</button>
    <ul id= "menu" hidden>
      <li>Home</li>
      <li>Services</li>
      <li>Contact</li>
    </ul>

    In this example, setting aria-expanded= "false" on the button shows it’s not expanded. When the user clicks, you can switch that to true in your JavaScript.

    Don’t Add ARIA Where It’s Not Needed

    If an element already serves a clear function, adding a role that duplicates it is just noise for screen readers.

    Example

    <!-- Not so good -->
    <ul role="list">
      <li>Item 1</li>
      <li>Item 2</li>
    </ul>
    
    <!-- Better -->
    <ul>
      <li>Item 1</li>
      <li>Item 2</li>
    </ul>

    A <ul> is already recognized as a list by assistive technology.

    Test with Real Assistive Tech

    Tools like automated accessibility checkers are helpful, but they can’t catch everything. The best way to confirm your site’s accessibility is to test it with screen readers (like NVDA, JAWS, or VoiceOver) and try navigating entirely with a keyboard. If you can, get feedback from people who actually use these tools every day—they can point out mistakes or obstacles you might miss otherwise.

    Conclusion

    Using ARIA incorrectly can do more harm than good. In fact, it can make websites less accessible and confusing for users who rely on screen readers. The first step to building an accessible website is to stick with semantic HTML wherever possible. If you need ARIA—especially for complex custom widgets—be sure to use it carefully, accurately reflecting each element’s true roles and states. Then, test your work with real users and assistive technologies to make sure you’re making things better, not worse.

    Following these guidelines helps create a smoother experience for every visitor, including those using assistive technology. Remember: if you can solve your problem with native HTML, do that first. If not, ARIA can be a fantastic tool—just be sure you’re using it correctly.

    Need Help with Web Accessibility?

    Making a website accessible can be tricky, especially when it comes to knowing how and when to use ARIA. 216digital specializes in web accessibility, from ARIA best practices to full WCAG compliance. If you’re ready to take the next step toward a more inclusive web experience, reach out to us today! Let’s work together to ensure your site remains welcoming—and functional—for every user.

    Greg McNeil

    February 4, 2025
    How-to Guides
    Accessibility, ARIA, How-to, WCAG, Web Accessibility, web developers, web development
  • How to Build Accessible React Applications

    Building an accessible React application means designing a site that everyone, including people with disabilities, can use and enjoy. Accessibility in web apps isn’t just a legal or ethical responsibility—it’s also a best practice that improves user experience for everyone. React, with its dynamic and component-based nature, offers much flexibility, but without careful planning, accessibility can fall through the cracks. This guide will walk you through critical practices to build a more accessible React app, covering essential tools, effective HTML and ARIA usage, keyboard accessibility, and screen reader management.

    Why Accessibility in React Matters

    An accessible React app does not create obstacles for people who rely on assistive technology like screen readers, keyboards, or other devices. According to Web Content Accessibility Guidelines (WCAG), making web content accessible means people of all abilities can navigate, understand, and interact with your content. With tools and techniques tailored for React, you can ensure that users with disabilities get the best experience possible.

    Setting Up an Accessibility-Friendly Development Environment

    Setting up your React environment to catch accessibility issues early is a powerful way to build accessible applications. A highly recommended tool for React is eslint-plugin-jsx-a11y, which catches JSX-specific accessibility issues directly in your code editor.

    Installing eslint-plugin-jsx-a11y

    Install the plugin:

    npm install eslint-plugin-jsx-a11y --save-dev

    Configure ESLint: Add the plugin to your ESLint configuration file.

    {
      "plugins": ["jsx-a11y"],
      "extends": [
        "eslint:recommended",
        "plugin:jsx-a11y/recommended"
      ]
    }

    This plugin identifies accessibility issues in JSX, such as missing ARIA roles, empty <alt> attributes on images, and improper keyboard handling.

    The Power of Semantic HTML in React

    When it comes to accessibility, semantic HTML is your best friend. Semantic elements like <button>, <header>, and <nav> are designed to convey meaning and functionality to both browsers and screen readers. This minimizes the need for ARIA roles and additional attributes, as semantic HTML elements come with built-in keyboard accessibility and screen reader support.

    Examples of Semantic HTML in React

    Using semantic elements directly in React makes components accessible by default. For example:

    import React from 'react';
    function AppHeader() {
      return (
        <header>
          <h1>Welcome to My Store</h1>
          <nav>
            <a href="#home">Home</a>
            <a href="#products">Products</a>
            <a href="#contact">Contact</a>
          </nav>
        </header>
      );
    }
    export default AppHeader;

    Avoid Using <div> and <span> for Interactive Elements

    Avoid using generic elements like <div> and <span> to create buttons or links, as these don’t include native keyboard or accessibility functionality. Instead, use <button> and <a> elements to ensure proper accessibility and functionality. For example:

    function IconButton() {
      return <button aria-label="Open settings" onClick={() => alert('Settings')}>⚙️</button>;
    }

    Enhancing Accessibility with ARIA Roles (But Use Them Wisely)

    ARIA (Accessible Rich Internet Applications) can make custom elements accessible when there’s no HTML equivalent. However, it’s essential to use ARIA roles to enhance existing semantic elements rather than replace them.

    Using aria-label for Accessibility

    Sometimes, buttons or icons need additional context for screen readers. The aria-label attribute provides descriptive text to communicate functionality.

    function IconButton() {
      return <button aria-label="Open settings" onClick={() => alert('Settings')}>⚙️</button>;
    }

    Dynamic Updates with aria-live

    React apps often have dynamic content. Use aria-live regions to notify screen readers about important changes.

    function AlertMessage({ message }) {
      return (
        <div aria-live="assertive">
          {message}
        </div>
      );
    }

    Keyboard Accessibility and Focus Management

    Keyboard accessibility ensures users can navigate your app without a mouse, which is crucial for many assistive technology users. In React, managing keyboard focus is straightforward with hooks like useRef and useEffect.

    Setting Focus with useRef and useEffect

    You can use useRef to target an element and useEffect to set focus when a component mounts. This is useful for elements like modals, which should receive focus when they appear.

    import React, { useRef, useEffect } from 'react';
    function Modal({ isOpen, onClose }) {
      const closeButtonRef = useRef(null);
      useEffect(() => {
        if (isOpen) {
          closeButtonRef.current.focus();
        }
      }, [isOpen]);
      return (
        isOpen && (
          <div role="dialog" aria-modal="true">
            <p>Modal content here</p>
            <button ref={closeButtonRef} onClick={onClose}>Close</button>
          </div>
        )
      );
    }

    In this example, the close button gains focus when the modal opens, making navigation intuitive for keyboard users.

    Avoiding Focus Traps

    Focus traps occur when users get “stuck” within an element, such as a modal, and can’t return to the main content. Ensure that focus can move freely between interactive elements and provide a way to close modals with the Escape key.

    Best Practices for Accessible Interactive Elements

    When building custom components, pay attention to how they’ll be used with a keyboard:

    Provide Clear Labels for Inputs

    Forms are essential in any application, and labeling form controls is critical for accessibility. Use labels effectively with inputs, either through <label> elements or aria-label attributes.

    function NameInput() {
      return (
        <label htmlFor="name">
          Name:
          <input type="text" id="name" aria-required="true" />
        </label>
      );
    }

    Accessible Modals

    For custom modal components, set the role= "dialog" and aria-modal= "true" attributes, which inform assistive technology that the content is a modal.

    Testing Focus

    After adding interactive elements, test that each one can be reached and activated using only the Tab, Enter, and Escape keys. This ensures full keyboard accessibility.

    Managing Screen Reader Navigation in SPAs

    Single Page Applications (SPAs) often update content dynamically without full page reloads, which can make it difficult for screen reader users to keep track of changes. When the main content area updates, shift focus to the new content or provide a way for screen readers to be alerted about the change.

    Example: Setting Focus on Page Updates

    import React, { useEffect, useRef } from 'react';
    function ContentArea({ content }) {
      const contentRef = useRef();
      useEffect(() => {
        contentRef.current.focus();
      }, [content]);
      return (
        <main tabIndex="-1" ref={contentRef}>
          {content}
        </main>
      );
    }

    Here, the main content area receives focus after each update, helping screen reader users navigate SPAs more easily.

    Testing Your React App for Accessibility

    Testing is crucial to ensure your React application meets accessibility standards. Here are some testing methods and tools:

    1. Manual Testing: Use keyboard-only navigation to interact with your app, checking that all elements are accessible and usable. Verify that custom elements respond to the Tab, Enter, and Escape keys.
    2. Screen Readers: Test with a screen reader like NVDA (for Windows) or VoiceOver (for macOS). Experience the app as a screen reader user to see how well content updates and ARIA roles are conveyed.
    3. Automated Tools: Tools like Google Lighthouse or WAVE identify many accessibility issues. They’re helpful for quickly checking common problems, although they don’t replace manual testing.

    Conclusion

    Building accessible React applications takes effort but is entirely achievable with the right techniques and tools. Start by setting up your development environment with eslint-plugin-jsx-a11y to catch common issues, and always prioritize semantic HTML elements for inherent accessibility. ARIA roles are powerful but should be used to enhance—not replace—standard HTML.

    Ensuring keyboard accessibility, managing focus in SPAs, and regularly testing for accessibility can make a world of difference for users. By following these practices, you’re not only meeting WCAG standards but also creating a better user experience for everyone.

    Need help?  Reach out to 216digital using the contact form below for a complimentary ADA briefing.

    Bobby

    November 6, 2024
    How-to Guides
    ARIA, How-to, React, web developers, web development
  • The Importance of Keyboard Accessibility & Why ARIA Widgets Don’t Work

    Keyboard accessibility is a fundamental part of creating an accessible web experience. For many people, including those with motor impairments, the ability to navigate a website using only a keyboard is essential. Unfortunately, not all website interactive elements are designed with keyboard users in mind. This is where ARIA (Accessible Rich Internet Applications) widgets often come into play—intended to improve accessibility but frequently falling short when misused.

    Understanding the principles of keyboard accessibility and the limitations of ARIA widgets can help website owners, developers, and content creators deliver a more inclusive user experience. Let’s explore the most common keyboard accessibility issues, why ARIA widgets often miss the mark, and how you can design your website to meet Web Content Accessibility Guidelines (WCAG) standards.

    Why Keyboard Accessibility Matters

    Keyboard accessibility ensures that all interactive elements on a website—like buttons, forms, links, and menus—are reachable and usable without needing a mouse. Many users, such as those with motor disabilities or vision impairments, rely on keyboards, screen readers, or other assistive devices to navigate web content.

    Without keyboard accessibility, people using assistive technology can encounter significant barriers, preventing them from completing tasks or navigating the site. For instance, a checkout form that only allows interaction through mouse clicks will stop a keyboard user in their tracks, impacting their ability to purchase a product or service.

    Common Barriers to Keyboard Accessibility

    Some of the most common obstacles that keyboard users face on websites include:

    Lack of Focus Indicators

    • Problem: Without visible focus indicators, keyboard users may not know where they are on the page. This becomes particularly frustrating when navigating forms or interactive menus.
    • Solution: Use CSS to style focus indicators and make them highly visible, such as by changing the border color, background, or outline. Here’s an example:
    button:focus, a:focus {
    	outline: 3px solid #005fcc;
    	background-color: #f0f8ff;
    }

    Improper Tab Order

    • Problem: Elements on a page need to logically match the visual layout. Without a logical tab order, users may be taken through an erratic sequence, which can lead to confusion and missed information.
    • Solution: Arrange your elements in HTML to follow the intended visual order and limit use of the tabindex attribute. By default, elements will follow the document’s source order, so it’s best to organize your code this way.

    Focus Traps

    • Problem: Focus traps occur when users can’t tab away from a particular element, like a popup or modal. Once they’re stuck, the rest of the page becomes inaccessible until they can close the focus-trapped section.
    • Solution: Ensure focus returns to the main content once the user dismisses the popup or modal, using JavaScript if necessary:
    // Example of returning focus after modal close
    document.getElementById("closeModalButton").addEventListener("click", function() {
      document.getElementById("mainContent").focus();
    });

    ARIA Widgets and Their Challenges

    ARIA (Accessible Rich Internet Applications) is a set of attributes that help improve the accessibility of web applications, particularly for screen readers. However, ARIA widgets—such as dropdowns, sliders, and modals—often don’t work as expected for keyboard users if not implemented carefully. ARIA can enhance accessibility, but it can’t “fix” poor coding practices or make non-native elements fully functional on its own.

    Why ARIA Widgets Often Fail

    ARIA widgets can be highly effective but only if they’re properly coded, tested, and consistently used with accessibility in mind. Here are some common pitfalls:

    Reliance on ARIA Without Semantic HTML

    ARIA is not a replacement for HTML5 elements; it’s meant to enhance them. Using ARIA on elements that don’t support native keyboard interactions (like <div> for a button) means the widget might lack inherent keyboard functionality.

    For example, instead of creating a clickable div with ARIA, use a <button> tag. Buttons come with native keyboard functionality and don’t require extra scripting or attributes to work as expected.

    Overuse of role and tabindex Attributes

    Misusing role attributes can disrupt how screen readers interact with elements. For instance, assigning a role= "button" to a div won’t make it work the same way as a real button.

    Similarly, improper use of tabindex can cause elements to jump around in an illogical order. Stick to the natural flow of the DOM, using tabindex= "0" only when absolutely necessary to keep the order in sync.

    JavaScript-Dependent Behavior

    ARIA widgets often rely on JavaScript to replicate native interactions, but these scripts must be meticulously coded and tested. A JavaScript error could render an entire widget inaccessible.

    Testing your scripts thoroughly with keyboard-only navigation is essential, especially for ARIA widgets. Missing key events like “Enter” or “Escape” can trap users in a widget or make it difficult to interact with.

    Best Practices for Creating Keyboard-Accessible Interactive Elements

    To avoid these pitfalls and ensure that your site is truly keyboard accessible, follow these best practices:

    Prioritize Native HTML Elements

    Whenever possible, use native HTML elements for interactivity (like <button>, <a>, <input>, and <select>). They come with built-in accessibility and keyboard support, reducing the need for complex ARIA attributes or custom JavaScript.

    Use ARIA Judiciously

    Use ARIA only when there’s no HTML equivalent, like custom dropdowns or sliders. And if you do need ARIA attributes, implement them carefully with an understanding of their purpose. For example, use aria-expanded to indicate the open or closed state of a dropdown menu:

    <button aria-expanded="false" aria-controls="menu">Menu</button>
    <ul id= "menu" hidden>
      <li><a href="#home">Home</a></li>
      <li><a href="#about">About</a></li>
    </ul>

    Enable Logical Focus Management

    Ensure that interactive elements maintain a logical and intuitive focus order. When creating modals or popups, use JavaScript to trap focus within the modal until it’s closed and then return focus to the last element interacted with:

    const modal = document.getElementById("modal");
    const lastFocus = document.activeElement;
    // Trap focus within modal
    modal.addEventListener("keydown", (e) => {
      if (e.key === "Tab") {
        // Logic to keep focus within modal
      }
    });
    // Restore focus after modal close
    modal.addEventListener("close", () => {
      lastFocus.focus();
    });

    Include Skip Links

    Skip links are simple yet effective. They allow keyboard users to jump directly to the main content, bypassing repetitive navigation menus. Add a skip link that appears when focused, like this:

    <a href="#mainContent" class="skip-link">Skip to main content</a>
    <main id="mainContent">
      <!-- Main content here -->
    </main>

    The Importance of Testing for Keyboard Accessibility

    Testing is critical to achieving real keyboard accessibility. Use keyboard-only navigation to interact with your site, ensuring that each element responds to the Tab, Enter, and Escape keys appropriately. Here are a few tips for testing:

    1. Turn Off Your Mouse: Try navigating your site using only the keyboard. See if you can reach every interactive element and complete all tasks.
    2. Use Assistive Technology Simulators: There are free screen readers (such as NVDA or VoiceOver) that let you experience your website as a keyboard-only user would.
    3. Run Accessibility Audits: Automated tools like Google Lighthouse or WAVE can catch many keyboard accessibility issues, but a manual review is still necessary.

    Conclusion

    Keyboard accessibility is a must for ensuring inclusivity on your website. By avoiding ARIA misuse and sticking to native HTML elements where possible, you’ll reduce barriers for keyboard users and create a smoother experience. Remember, ARIA attributes can enhance interactivity, but they aren’t a substitute for accessible design principles.

    Testing with keyboard-only navigation will confirm that your site meets WCAG standards and shows your commitment to creating a web experience that everyone can enjoy—just in time for all your visitors to get the most out of your content and promotions. Reach out to 216digital using the contact form below if you’re unsure if your website is keyboard navigable.

    Bobby

    October 29, 2024
    How-to Guides
    ARIA, How-to, keyboard accessibility, web developers, web development
  • How to Implement ARIA Landmarks and Roles for Better Accessibility

    For users of assistive technologies, accessing and interacting with websites can be difficult if the proper structure and cues aren’t in place. This is where ARIA (Accessible Rich Internet Applications) landmarks and roles come in handy. Implementing ARIA landmarks and roles can significantly improve your website’s accessibility, helping users navigate more easily and interact with web elements effectively. If you’re new to ARIA, don’t worry! This guide will walk you through ARIA landmarks and roles, why they matter, and how to implement them step-by-step.

    What Is ARIA and Why Is It Important?

    ARIA is a set of HTML attributes intended to make webpages easier to navigate for people who rely on assistive technology, such as screen reading software. These attributes help bridge gaps in standard HTML that might not convey sufficient meaning to people with disabilities.

    By using ARIA, developers can label, describe, and define the functionality of elements in ways that ensure everyone has a better user experience. Regarding web accessibility, ARIA attributes are recommended in some cases by the Web Content Accessibility Guidelines (WCAG), which provide standards to help websites comply with accessibility requirements.

    ARIA landmarks and roles are two essential aspects of making sure your website content is accessible for all users to understand and interact with.

    ARIA Landmarks: What Are They?

    ARIA landmarks are unique markers you can add to different sections of your webpage to make navigation easier for users with disabilities. These landmarks help people who use screen readers understand the structure of a webpage and quickly jump to different sections. Think of them as signposts, making it clear where key sections—like the header, main content, navigation, and footer—are located.

    The major ARIA landmarks include:

    • <header>: Identifies the top section of the webpage.
    • <main>: Indicates the main content of the page.
    • <nav>: Points to the area that contains navigational links.
    • <footer>: The bottom section of the webpage.

    Why Are ARIA Landmarks Important?

    ARIA landmarks are invaluable for users with visual or motor impairments who use the keyboard or screen reader to navigate the web. They allow users to skip repetitive elements (like navigation bars) and jump directly to the content they’re looking for. Without these landmarks, a user would have to listen to every single line of the page to figure out where the main content starts or how to get to the footer. Using ARIA landmarks ensures that your website is easy to navigate for everyone.

    How to Implement ARIA Landmarks Step-by-Step

    Now that you understand the importance of ARIA landmarks let’s look at how to implement them in your website’s code. The good news? Adding ARIA landmarks is simple and can be done using standard HTML elements.

    Adding the Header Landmark

    The <header> element is used to define the global top section of your page, which typically contains things like the website logo, title, or main navigation links. Here’s an example of the correct usage of the HTML5 <header> region:

    <header>

    <h1>My Cool Website</h1>
    <h1>My Cool Website</h1>
      <nav>
        <ul>
          <li><a href="/">Home</a></li>
          <li><a href="/about">About</a></li>
          <li><a href="/products">Products</a></li>
        </ul>
      </nav>
    </header>

    The Main Landmark

    The <main> element is crucial because it defines the primary content of the page. The <main> element, along with a skip link, can allow users of assistive technology to skip past repetitive content such as the navigation:

    <main role="main">
      <h2>Main Content</h2>
      <p>This is the most important part of the page.</p>
    </main>

    By using role=”main”, you’re ensuring that screen readers can quickly identify and jump to the core content of your page. Only one main landmark should be used per page.

    Using the Navigation Landmark

    The navigation area of your website should be easy to identify and skip if necessary. You can use the <nav> element or the ARIA role, but you do not need to use both:

    <nav>
      <ul>
        <li><a href="#section1">Section 1</a></li>
        <li><a href="#section2">Section 2</a></li>
      </ul>
    </nav>
    <div role="navigation">
      <ul>
        <li><a href="/products">Products</a></li>
        <li><a href="/about">About Us</a></li>
      </ul>
    </div>

    With the navigation region, you’re clearly marking the section of the page that contains links for navigating to other parts of the site.

    Adding the Footer Landmark

    Finally, the <footer> element typically contains secondary content, such as copyright information or additional links. Adding a landmark here helps screen reader users know when they’ve reached the end of the page:

    <footer role="contentinfo">
      <p>&copy; 2024 Your Company</p>
    </footer>

    In this case, role= "contentinfo" tells screen readers that this section provides supplementary information about the website.

    ARIA Roles: What Are They?

    ARIA roles go beyond marking sections of the page—they describe the functionality of specific elements. By using ARIA roles, you’re defining how an element should behave or be interacted with, especially when using assistive technologies.

    Some commonly used ARIA roles include:

    • “button”: Makes non-biased elements like <div> behave like a button.
    • “dialog”: Defines a pop-up dialog window.
    • “alert”: Marks an element as an important alert that needs immediate attention.

    Why Are ARIA Roles Important?

    ARIA roles give more meaning to non-standard HTML elements. For example, if you create a custom button using a <div> instead of the traditional <button> element, a screen reader might not recognize it as a button. By assigning it an ARIA role, you ensure it’s interpreted correctly, making the interaction more intuitive and accessible.

    How to Implement ARIA Roles Step-by-Step

    Let’s check out some examples of proper ARIA implementation.

    Creating a Custom Button

    If you have a custom button element (like a <div> styled as a button), you can add the role="button" to make sure it’s recognized as an interactive button by screen readers:

    <div role="button" tabindex="0" onclick="submitForm()">Submit</div>

    The ARIA role “button” tells assistive technology to announce this element as a button, and the “tabindex” attribute makes the element focusable via the keyboard. However, it’s always best to use the correct semantic HTML5 <button> tag whenever possible.

    Adding a Dialog Role

    For models or pop-up windows, you can use the role= "dialog" to make them accessible:

    <div role="dialog" aria-labelledby="dialogTitle" aria-describedby="dialogDescription">
      <h2 id="dialogTitle">Confirmation</h2>
      <p id="dialogDescription">Are you sure you want to delete this file?</p>
      <button onclick="closeDialog()">Cancel</button>
    </div>

    The aria-labelledby and aria-describedby attributes help give context to the dialog box for users relying on assistive technologies.

    Creating an Alert

    If you need to display important, time-sensitive information—like an error message or form feedback—you can use the role= "alert":

    <div role="alert">
      <p>Error: The "password" field is required.</p>
    </div>

    This role makes sure that screen readers announce the alert immediately, ensuring the user doesn’t miss critical information.

    Going Beyond ARIA: Continue Your Accessibility Journey

    The HTML markup of your website is far more critical than just defining the visual style of the site. It is used by screen reading software, assistive technologies, and keyboard navigation to ensure users have easy access to content. SEO crawlers also use it to determine the accuracy and relevance of your content.

    By adding landmarks like header, main, navigation, and footer, and using roles like button, dialog, and alert, you’ll not only meet the accessibility standards outlined by WCAG, but you’ll also create a more user-friendly website for everyone.However, this is just one piece of the web accessibility puzzle.

    Team Up with 216digital

    At 216digital, we understand that keeping up with ADA compliance and accessibility best practices can be challenging. That’s why we’re here to help. We specialize in helping businesses achieve and maintain ADA compliance with expert guidance and actionable strategies. Schedule an ADA briefing with our experts today to learn more about how we can guide you through the complexities of accessibility, ensuring your website meets legal standards and delivers a great experience for all users. 

    Let’s make the web more accessible, together—book your ADA briefing today!

    Bobby

    September 6, 2024
    How-to Guides
    Accessibility, ADA Compliance, ARIA, How-to, WCAG, Web Accessibility, web development
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.