web development Archives - Page 4 of 6/Tag

Why Touch Targets Impacts Accessibility
Imagine this: a customer visits your website, excited to snag a deal on their holiday shopping list. They’re scrolling through your page on their phone, ready to click “add to cart,”—but then they hit a roadblock. The buttons are too small, links are crowded together, and navigating your site becomes a frustrating game of “tap and hope.” Now imagine if that customer has limited dexterity or relies on assistive technology. For them, those tiny buttons and cramped links aren’t just an inconvenience; they’re a barrier.

Accessibility issues like these don’t just affect your users’ experience—they impact your bottom line and even your legal compliance. Making sure your site’s touch targets are easy to interact with is one of the simplest yet most impactful changes you can make. In this guide, we’ll cover why large, accessible touch targets matter, how they boost usability for everyone, and what steps you can take to ensure your site is welcoming to all.

What Are Touch Targets and Why Are They Important?

Touch targets are interactive elements—such as buttons, links, and form controls—that users engage with as they navigate your website. The size and spacing of these elements can make or break the experience, especially for users on mobile devices or those with physical limitations. If touch targets are too small or closely spaced, users may struggle to click or tap accurately, leading to frustration and a poor experience. This can be particularly challenging for older adults and individuals with limited dexterity.

Making touch targets sufficiently large and spaced out allows everyone to navigate and interact with your site more easily, enhancing both usability and inclusivity. This is a foundational aspect of web accessibility that ensures your website works well for all.

WCAG Guidelines: Key Standards for Touch Target Size

To provide clear guidance on accessible touch target sizes, the Web Content Accessibility Guidelines (WCAG) have established several success criteria. WCAG 2.1 and the updated WCAG 2.2 outline standards to help developers make online content accessible, mainly through adequately sized touch targets.

Success Criterion 2.5.5 (Target Size)

In WCAG 2.1, Criterion 2.5.5 specifies that interactive elements should meet a minimum touch target size of 44×44 pixels, making it easier for users with limited motor skills or assistive technology to select the right element.

Success Criterion 2.5.8 (Target Size – Enhanced)

WCAG 2.2 expands on this with Criterion 2.5.8, recommending even larger touch targets when interactive elements are positioned close together. This helps users avoid accidentally tapping the wrong element, especially on mobile devices or when using screen readers.

These guidelines establish a foundation for accessible design, giving developers clear targets to create user-friendly, inclusive sites that reduce errors and improve the overall user experience.

Best Practices for Designing Accessible Touch Targets

With WCAG standards in mind, you can take steps to create touch targets that enhance usability. Here are some essential practices for implementing accessible interactive elements:

Use Adequate Padding and Margin

Padding and margins around buttons and links help ensure they meet minimum size requirements while maintaining a clean visual layout. For example:
```
button {
  padding: 12px 20px; /* Increases padding for larger touch target */
  font-size: 16px;
}
```
Ensure Minimum Width and Height

Using min-width and min-height properties guarantees that buttons and other elements stay at least 44×44 pixels, even when the element content is smaller. This maintains accessibility across different screen sizes.
```
button {
  min-width: 44px;
  min-height: 44px;
}
```
Space Out Interactive Elements

Placing enough space between buttons and links prevents mis-taps and ensures usability for all users, especially those on mobile devices or using assistive technologies.
```
button, a {
  margin: 10px;
}
```
Add ARIA Attributes for Enhanced Accessibility

ARIA attributes (Accessible Rich Internet Applications) add context to interactive elements for users relying on assistive devices. For instance, using aria-expanded or aria-haspopup on a menu button helps screen reader users understand its function.
```
<button aria-expanded="false" aria-haspopup="true">Menu</button>
```
Responsive Design: Ensure Touch Target Size Across Devices

Since many users rely on mobile devices for browsing, it’s essential to make touch targets easily accessible on smaller screens. Using responsive CSS ensures that touch targets adapt to various screen sizes:
```
@media (max-width: 600px) {
  button {
    padding: 15px 25px; /* Larger padding on smaller screens */
  }
}
```
Testing Touch Target Accessibility

Once you’ve optimized your touch targets, testing is essential to ensure they’re functional and accessible. Here are a few testing strategies to confirm usability:
- Manual Testing: Test your site on various devices (desktop, tablet, mobile) to ensure touch targets are easy to access and use.
- Accessibility Tools: Tools like Google Lighthouse or WAVE can check WCAG compliance, including touch target sizes.
- User Testing: Feedback from real users, particularly those with disabilities, is invaluable for assessing how accessible and user-friendly your touch targets are.
Wrapping Up

Improving touch target accessibility is just one of many steps toward making your website genuinely inclusive and user-friendly. By focusing on accessible design, you not only enhance the experience for users with mobility challenges and those using assistive technologies but also build a site that’s welcoming and intuitive for everyone. Following WCAG guidelines, using best coding practices, and regular testing are essential—but navigating these standards alone can be overwhelming.

If you’re ready to take accessibility seriously and want to ensure your site is fully ADA-compliant, consider scheduling an ADA briefing with 216digital. Our team of accessibility experts can help you identify potential compliance issues, create actionable solutions, and guide you through the process of building a more accessible and inclusive website. Reach out today to learn how we can help safeguard your site and open new opportunities with ADA compliance.
Greg McNeil

November 8, 2024

How-to Guides

Accessibility, How-to, touch targets, web developers, web development, Website Accessibility
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>
```
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
A Case for Starting Accessibility Early in Development
When you’re kicking off a new web project, it’s easy to focus on exciting features and visual design. But here’s something that often gets pushed aside until it’s almost too late: accessibility. The truth? Accessibility isn’t just a box to check off at the end of development; it’s a fundamental part of creating an inclusive, user-friendly experience from day one. To truly succeed, you need to start accessibility early.

Think about it: no one wants to realize their new website or app needs major tweaks just to be usable for everyone. Starting accessibility early not only benefits people with disabilities but boosts usability for all your users, saves you money, and keeps you in line with standards like Web Content Accessibility Guidelines (WCAG). And who doesn’t want to avoid headaches later on?

Let’s break down why embedding accessibility into your project from the very beginning is worth every bit of effort—and how to make it happen smoothly.

Why Start Accessibility Planning from the Beginning?

Making accessibility a priority from day one can feel like a big commitment, but here’s what you gain by choosing to start accessibility early:

Avoid Costly Retrofits

Fixing accessibility issues at the end of a project can mean reworking significant parts of your site—an expensive and time-consuming ordeal. Imagine designing your site, launching it, and then realizing it doesn’t meet accessibility standards. Adding features like keyboard navigation or fixing color contrast at that point can mean redoing large chunks of your design. Planning for these details early on keeps everything smoother (and kinder on your budget).

Enhance User Experience for All

When you start accessibility early, you set the stage for a user experience that is friendly and inclusive for everyone. Accessibility isn’t just for those with disabilities—it’s for everyone. Features like clear navigation, easy-to-read text, and well-labeled elements make browsing better for all users. Designing with accessibility in mind from the start ensures these benefits are baked in, rather than added later.

Stay Compliant and Avoid Legal Issues

Starting with WCAG standards and other accessibility guidelines from the get-go helps you avoid legal hiccups. These guidelines form the backbone of inclusive web design and ensure you’re in line with regulations like the Americans with Disabilities Act (ADA). Following these rules early on makes compliance one less thing to worry about.

How to Integrate Accessibility into Each Stage of Development

Accessibility can be woven into every phase of your project with just a bit of planning. Here are some actionable steps for developers and designers:

Design with Accessibility in Mind

From the beginning, designers play a critical role in accessibility by setting the structure and visual flow of a project. Here are a few accessibility best practices to incorporate during the design phase:

Color Contrast and Readability

Make sure your text is easy to read against its background. According to WCAG guidelines, regular text should have at least a 4.5:1 contrast ratio, while larger text should have a 3:1 contrast ratio. Testing tools like WebAIM’s Color Contrast Checker make this quick and easy to verify.

Intuitive Layout and Navigation

A clear, intuitive layout ensures all users can navigate your site. Place navigation elements consistently, keep forms simple, and use ample white space to make content easier to digest. These are just a few examples of how to start accessibility early in your design strategy.

Descriptive Text for Buttons and Links

Buttons and links should have descriptive text that tells the user exactly what will happen when they click. Instead of a vague “click here,” label it with “Learn More About Accessibility,” for example. Clear labels improve navigation for users and assistive technologies alike.

Use the Right HTML Tags

Developers can make a huge impact when they start accessibility early by using semantic HTML. Semantic HTML tags—like <header>, <main>, <nav>, and <footer>—convey the structure of your webpage to screen readers and other assistive devices, helping users navigate more effectively.

Proper HTML Markup

Use headings (<h1>, <h2>, etc.) in a logical order, and never skip heading levels. This creates a clear hierarchy for users relying on screen readers and assists everyone in navigating your content.

Descriptive Alt Text for Images

Screen readers rely on alternative text (alt text) to describe images to visually impaired users. Ensure every image with meaningful content has a description that conveys what’s in the image or its purpose. If the image is purely decorative, use an empty alt attribute (e.g., alt=" ") to signal to screen readers that it can be ignored.

ARIA Attributes

Accessible Rich Internet Applications (ARIA) roles and attributes provide additional context where HTML alone may fall short. For example, you can use aria-label to describe the function of a button or aria-live to notify screen readers of real-time changes, like alerts.

Test for Accessibility as You Go

Testing for accessibility throughout development lets you catch issues early before they become a headache to fix. Here’s how to implement regular accessibility checks:

Automated Accessibility Tools

Automated testing tools like Lighthouse and WAVE can detect many common accessibility issues, such as missing alt text or incorrect heading levels. However, keep in mind that while these tools are valuable, they’re not a complete solution.

Manual Testing and Keyboard Navigation

Not all accessibility features can be evaluated by automated tools, so manual testing is essential. Many users with disabilities rely on keyboards instead of a mouse, so test your site using keyboard navigation alone. Make sure users can access all interactive elements (like links, forms, and buttons) and follow a logical tab order.

Screen Reader Testing

Use screen readers like NVDA (for Windows) or VoiceOver (for Mac) to simulate how users with visual impairments experience your site. This will help you catch any missing descriptions, confusing elements, or awkward navigation.

Get Feedback from Users with Disabilities

Involving people with disabilities in testing phases offers invaluable insights. Real users bring unique perspectives that automated tools or simulated testing just can’t replicate.

Plan for Inclusive Testing

Recruit a diverse group of testers who use different assistive technologies, including screen readers, magnification software, and voice control. Their feedback can reveal practical challenges and usability issues you might not anticipate.

Iterate Based on Feedback

Make adjustments based on real-world experience and retest if needed. Accessibility is an ongoing process, and user feedback will help you understand where improvements are necessary.

Regularly Check Your Site

Keeping your site accessible isn’t a one-and-done task—it’s an ongoing process. Regular audits help ensure that your site or app stays up to date with accessibility standards as you make changes or add new features. These check-ups can catch any issues that might have been overlooked during development, or that pop up over time. But audits alone don’t cover everything; that’s where regular monitoring comes in.

Services like a11y.Radar makes a big difference by providing continuous monitoring to help keep your website accessible. With automated checks and detailed reports, a11y.Radar alerts you to potential issues early on so you can fix them before they turn into bigger problems. Plus, it helps you stay aligned with current WCAG guidelines, which are always evolving.

Combining regular audits with a monitoring service like a11y.Radar keeps your site running smoothly and ensures a user-friendly experience for everyone.

Building a Culture of Accessibility

Making accessibility a foundational part of your development culture is key to sustaining these practices long term. Here are some ideas to foster an accessibility-first mindset in your team:

Educate and Train Your Team

Provide training on accessibility guidelines and tools for all team members, from designers and developers to project managers and content creators. Workshops, webinars, and resources on WCAG standards and inclusive design can help create a shared understanding of accessibility’s importance.

Keep Accessibility Resources Available

Ensure your team has access to accessibility checklists, WCAG guidelines, and tool recommendations. Having these resources easily accessible means team members can refer to them at any stage of development.

Regularly Review and Share Accessibility Wins

Celebrate small successes, such as completing accessibility testing on a new feature or receiving positive feedback from an accessibility audit. Recognizing and sharing progress reinforces the importance of this work and motivates your team to continue prioritizing accessibility.

Helpful Tools for Accessibility

There are a variety of helpful tools for accessibility checks and improvements. Here are a few top options:
- WebAIM’s Color Contrast Checker: Verifies that contrast meets WCAG standards for readability.
- Lighthouse and WAVE: An open-source accessibility tool that runs quick checks on your web pages for WCAG compliance.
- Screen Readers: Test with NVDA (Windows), VoiceOver (Mac), and TalkBack (Android) to experience your site from the perspective of visually impaired users.
- ARIA Authoring Practices Guide: This guide provides information on implementing ARIA roles and attributes to enhance assistive technology compatibility.
Ready to Make Accessibility Part of Your Game Plan?

So, there you have it—starting accessibility early isn’t just a nice-to-have; it’s a win-win for everyone involved. By weaving accessibility into your project from day one, you’re not only sidestepping costly revisions but also crafting a better experience for all your users. Plus, you’re keeping things legally sound, which is always a good move.

But we get it—navigating the world of WCAG guidelines and accessibility best practices can feel a bit like decoding a secret language. If you’re ready to start accessibility early in your web development process without complicating your project, let’s talk. Schedule an ADA briefing with us at 216digital, and we’ll guide you through your journey in plain English (no tech jargon). Let’s work together to make the digital world a more inclusive place—one accessible website at a time.
Greg McNeil

October 28, 2024

Legal Compliance, The Benefits of Web Accessibility

Accessibility, Accessibility testing, ADA Compliance, UX, web development
5 Accessibility Mistakes to Dodge This Holiday Season
Many eCommerce businesses make most of their income during the holiday shopping season, so your website must perform to the best of its ability during the Black Friday and Cyber Monday promotions. Web Accessibility is probably the last thing on your mind when you’re already in a frenzy to ensure you’re maximizing every visit to your website. However, you may be leaving money on the table or making yourself vulnerable to expensive litigation if you don’t stay diligent with your digital inclusivity.

For many customers—especially those with disabilities—shopping online is their primary option. If your website isn’t accessible, you’re alienating a significant portion of your audience (up to 20%) and potentially violating the Americans with Disabilities Act (ADA).

To help you prepare for the holiday rush, let’s go over five common web accessibility mistakes businesses make during holiday promotions and how you can avoid them.

Insufficient Alt Text for Images

Holiday promotions often rely on eye-catching images, banners, and product displays. However, if those images lack appropriate alt text, customers using screen readers won’t be able to understand their content. Alt text (short for alternative text) provides a textual description of an image that’s accessible to screen reader users.

Why It Matters

Alt text is essential for individuals with visual impairments. If a visually impaired customer is browsing your site and encounters an image without a proper description, they’ll have no idea what’s being displayed. Imagine running a huge Black Friday sale, but your best deals are hidden from a portion of your audience simply because your images aren’t described.

How to Fix It

As you add promotional banners and products to the website, always make sure you’re adding alt text to the images. Here’s an example:
```
<img src=" winter-sale-banner.jpg" alt=" Banner for Winter Sale - Up to 50% off jackets and coats">
```
Do not use image file names or vague text such as “sale-img” or “Sale Image”. Make sure the alt text contains enough information that the user understands the purpose of the image and contains any words that appear on the image.

Poor Color Contrast

With holiday promotions comes festive design—bright colors, eye-catching buttons, and themed decorations. While these designs may look great, they often fail color contrast standards. Having adequate color contrast is not only good for color-blind users, but it also makes the website easier for everyone to navigate.

Why It Matters

According to WCAG, the minimum contrast ratio between text and background should be at least 4.5:1 for normal text and 3:1 for larger text. When the contrast is too low, customers with low vision or color blindness may struggle to read important information, such as product details or discount codes.

How to Fix It

Use tools like the WebAIM Contrast Checker to ensure your color choices meet the WCAG contrast ratio guidelines. For example, a light gray text on a white background will likely fail the contrast test, but switching to a darker gray or black can make a big difference.

Here’s an example of a common mistake and how to correct it:
```

<p style="color: #cccccc; background-color: #ffffff;">50% off all products!</p>

<p style="color: #000000; background-color: #ffffff;">50% off all products!</p>
```
Pay attention to your text color, button colors, and even the contrast of smaller elements like icons.

InaccessibleNavigation and Controls

Most store owners don’t consider that some users do not navigate their website with a mouse. Even some users without disabilities prefer to use other input methods to quickly navigate some sections of your website.

Why It Matters

Blind and motor-impaired users rely on the keyboard, gestures, or voice commands to navigate your website. If your navigation, contact forms, category filters, and product pages are not properly coded to support these input methods, these users will be denied equal access to the website and may not be able to make a purchase with you at all, losing you a valuable customer and potentially damaging your reputation.

How to Fix It

Regularly test the functional portions of your website with a keyboard. Attempt to start at the homepage, navigate to a category page, use the category filters, add/remove product quantities, and select product options without your mouse. If you encounter a problem with an element, it’s likely not coded using the correct element. You can force an element to receive keyboard focus using the tabindex attribute. The role="button" attribute will help users navigating with assistive technology better understand the purpose of the control:
```
<span class="swatch-button" tabindex="0" role="button">Beige</span>
```
Better yet, use the correct semantic HTML tag to accomplish this:
```
<button class="swatch-button">Beige</button>
```
Semantic HTML helps users relying on assistive technology understand the purpose of controls and also helps Google better understand the structure of your website:
```
<nav>
	<a href="/products">All products</a>
	<a href="/products/sale">Sale products</a>
	<a href="/contact">Contact Us</a>
</nav>
```
Missing Captions on Promotional Videos

Videos are an excellent way to showcase products, promote deals, or explain services during the holiday season. However, many businesses forget to include captions, making the content inaccessible to users who are deaf or hard of hearing.

Why It Matters

Videos contain a lot of important information in the form of spoken words and visual cues. Both blind and deaf users rely on accessible closed captions (not just subtitles) to understand the content of the video. Also, some users may be in noisy environments and are unable to hear the video.

How to Fix It

Most popular video platforms have auto-captioning features, but these tend to just subtitle the video rather than create truly accessible closed captions. There are many cheap and easy closed captioning services, such as Rev.com, that have quick turnarounds.

Here’s how you implement closed captions from an external service:
```
 <video controls>
  <source src="promo-video.mp4" type="video/mp4">
  <track kind="captions" src="captions_en.vtt" srclang="en" label="English">
  Your browser does not support the video tag.
</video>
```
Always test the captions to make sure they sync properly with the video and cover both spoken dialogue and important sound effects.

Over-reliance on Automated Accessibility Overlays

It might seem tempting to use automated accessibility overlays, especially during the hectic holiday season. These are often marketed as one-click solutions to make your website accessible. The Department of Justice has issued clear guidance that these solutions are inadequate in addressing web accessibility, and they may get you targeted with litigation.

Why It Matters

Automated accessibility overlays claim to fix all accessibility issues on a website, but they usually fail to address the root problems. Blind users are outspoken that they dislike these solutions as they tend to interfere with the assistive technologies they’re already comfortable with. We’ve also seen these solutions specifically called out in lawsuits as a reason for being targeted.

How to Fix It

The best way to ensure your site is accessible is by addressing the core issues in your code and design. Automated tools can help identify problems, but manual reviews and fixes are essential. Invest in manual audits and focus on meeting the WCAG guidelines through thoughtful design and coding practices.

Here’s an example of using a reliable method instead of relying on an
```

<img src= "holiday-product.jpg" alt= "Red winter coat with a 30% off discount tag">
```
Automated tools tend to use AI to label images and controls and often misrepresent content on the website, leading to a potentially overtly harmful experience.

Conclusion

As you gear up for holiday promotions, make sure accessibility is at the top of your checklist. By avoiding these common mistakes—insufficient alt text, poor color contrast, inaccessible navigation, missing captions, and over-reliance on automated tools—you’ll ensure that your website is welcoming and easy to use for everyone.

Not only does improving web accessibility help you reach a wider audience, but it also protects your business from legal risks and ensures compliance with WCAG and ADA standards. Taking the time to implement these changes now will pay off during the holiday rush and beyond.

If you’re unsure about the accessibility of your site, reach out to 216digital using the contact form below for a free evaluation.
Bobby

October 21, 2024

How-to Guides, Legal Compliance

holiday promotions, How-to, web development, Website Accessibility
How Semantic HTML Improves Your Accessibility & SEO
When creating a website, it’s easy to get caught up in how it looks and how it functions. But have you ever paused to think about how your website is structured behind the scenes? If you’re simply filling your code with <div> and <span> tags, you might be missing an opportunity to make your site better—not just for search engines, but for users, too.

Semantic HTML is more than just good coding practice; it’s a way to make your website more accessible and easier for search engines to understand. This isn’t just about technicalities—it’s about creating a smoother, more meaningful experience for your visitors. Whether you’re a seasoned developer or just starting out, understanding and implementing semantic HTML can make a real difference in how people interact with your site, especially those using assistive technologies.

In this article, we’ll explore what semantic HTML is, why it matters, and how it can improve both accessibility and SEO. We’ll also touch on practical tips, common mistakes to avoid, and how semantic HTML aligns with Web Content Accessibility Guidelines (WCAG) to make your site more inclusive.

What is Semantic HTML?

Let’s start with the basics. Semantic HTML refers to using HTML tags that have a specific meaning or role within the webpage. These elements are not just for visual structure; they provide information about the type of content within them, helping browsers and assistive technologies (like screen readers) better understand your webpage’s layout and content.

Here are some common semantic HTML tags:
- <header>: Represents the introductory content, often containing the website’s logo or navigation links.
- <nav>: Defines a set of navigation links that help users explore your site.
- <article>: Used for standalone content that could be reused or distributed, such as blog posts.
- <section>: Groups related content together thematically, often with its own heading.
By contrast, non-semantic elements like <div> and <span> don’t convey any meaning other than being containers. While they still have their place, relying solely on them can make your website harder to navigate for both users and search engines.

Why Semantic HTML is Critical for Accessibility

When we talk about accessibility, we’re referring to making sure that your website can be used by everyone, including people with disabilities. Many users rely on assistive technologies like screen readers, which read the content of a webpage out loud. Screen readers depend on the proper use of semantic HTML to interpret the structure of a page.

For example, a screen reader can easily understand what a <header> or <nav> tag is, allowing users to navigate your website more efficiently. If you use a <div> for everything, the screen reader has no idea whether it’s a section of text, a navigation menu, or a footer. This makes the browsing experience confusing and frustrating for users with disabilities.

Helping Screen Readers Navigate Your Website

One of the primary ways semantic HTML improves accessibility is by helping screen readers announce different sections of your website. For example, if you have a blog post wrapped in an <article> tag, the screen reader can announce to the user that they’re about to read an article.

Let’s compare:

Non-Semantic Example:
```
<div class="blog-post">My First Blog Post</div>
```
Semantic Example:
```
<article>My First Blog Post</article>
```
The second example clearly defines that the content is an article. Assistive technologies will pick up on this and offer better navigation and context for the user.

Structured Navigation for All Users

Another advantage of using semantic HTML is structured navigation. Tags like <nav>, <header>, and <footer> help screen readers understand the hierarchy of the page. When users rely on a screen reader to navigate, they can quickly jump to important sections like the navigation bar or the main content by skipping through these well-defined landmarks.

Imagine navigating a website by ear, trying to figure out where the navigation menu ends and where the main content begins—without semantic HTML, it’s a guessing game.

How Semantic HTML Improves SEO

The benefits of semantic HTML don’t stop at accessibility—it also plays a key role in your site’s search engine optimization (SEO). Google and other search engines rely on web crawlers to analyze your site, and these crawlers can better understand the context and structure of your content when you use semantic HTML.

Better Crawling and Indexing

Search engines are smart, but they can’t interpret your content as humans do. Using semantic HTML helps them figure out what each part of your page represents. For instance, wrapping your blog posts in <article> tags signals to search engines that this content is an article, making it easier for them to understand and categorize.

This is how semantic HTML can help with SEO:
- Improved Indexing: Using proper semantic tags can lead to better indexing, as search engines can more easily understand the structure of your content.
- Rich Snippets: Semantic HTML can improve the likelihood of your site showing up with rich snippets in search results, such as a featured article or recipe, depending on the content.
- Enhanced SEO Ranking: Google prioritizes websites that offer a good user experience. Since semantic HTML improves navigation for all users, including those using assistive technologies, your site is more likely to be seen as user-friendly, boosting your SEO.
Best Practices for Using Semantic HTML

Ready to start using semantic HTML? Here are some best practices to keep in mind:

Use the Right Tag for the Right Purpose

Each semantic HTML tag has a specific use, and you should apply them where they belong. For example:
- Use <header> for the top section of your page that contains headings or introductory content.
- Use <nav> for navigation links, not just random lists of links.
- Use <article> for blog posts or other standalone content.
- Use <section> to group related content, and <footer> for the bottom of your page.
Avoid Overusing <div> and <span>

While <div> and <span> are useful for general-purpose containers, overusing them can result in a loss of meaning in your page structure. Whenever possible, replace them with more descriptive elements like <section>, <aside>, or <figure>.

Combine Semantic HTML with ARIA Roles

In some cases, ARIA (Accessible Rich Internet Applications) roles can complement semantic HTML by providing additional context. For example, adding role="navigation" to a <nav> element makes it even clearer that the content is meant for navigation. Just be careful not to rely on ARIA roles as a substitute for semantic HTML—they should be used to enhance, not replace.

Align with WCAG Guidelines

WCAG offer clear recommendations on how to make your content accessible. One of their core principles is ensuring that content is perceivable and navigable by assistive technologies, which is where semantic HTML shines.
- WCAG 1.3.1 (Info and Relationships): This guideline emphasizes the importance of using semantic elements so that content can be understood by assistive technologies.
- WCAG 2.4.1 (Bypass Blocks): Using semantic HTML makes it easier for users with disabilities to bypass repetitive content and jump straight to the main sections, such as navigation menus or headers.
Common Mistakes to Avoid

While semantic HTML is straightforward, there are a few common mistakes that developers often make. Avoid these pitfalls to ensure your content is both accessible and SEO-friendly:
- Overuse of <div> and <span>: These tags should be used sparingly and only when no other semantic element fits. Overloading your page with <div> tags makes it hard for search engines and screen readers to understand your content.
- Forgetting to Add Alt Text: While it’s not directly related to semantic HTML, always remember to add alt attributes to your images. This ensures that screen readers can describe your images to visually impaired users, further enhancing accessibility.
- Misusing ARIA: ARIA attributes are great when used correctly, but they should only be applied when there’s no semantic HTML option available. Overusing or misapplying ARIA can lead to confusion and even reduce accessibility.
Examples of Effective and Ineffective Link Text

Semantic HTML also plays a role in creating meaningful link text, which is crucial for both accessibility and SEO. Here are some examples:

Ineffective Link Text
```
<a href="https://example.com">Click here</a>
```
This link doesn’t tell the user what they’re clicking on, which is confusing for screen readers and doesn’t provide context for search engines.

Effective Link Text
```
<a href="https://example.com">Read our guide on semantic HTML</a>
```
This example clearly indicates the content of the linked page, which is helpful for screen readers and improves SEO.

Conclusion

Semantic HTML isn’t just a coding technique—it’s a way to make the web more understandable, usable, and welcoming for everyone. By using the right tags, you’re not just making your site easier to navigate for search engines; you’re improving the experience for people who rely on assistive technologies. The impact goes beyond lines of code—it’s about making the web a better place for all users.

If you’re looking to enhance your site’s accessibility or simply want a clearer path to SEO success, start by rethinking your HTML structure. It’s a small change that can make a big difference. And if you’re unsure where to begin, 216digital can help. Schedule an ADA briefing with us to see how better accessibility can turn into a real opportunity for your business.
Greg McNeil

October 18, 2024

How-to Guides

How-to, HTML, semantic HTML, WCAG, Web Accessibility, web development
The Dos and Don’ts of Using Tabindex
Running a website, whether for an online store or a blog, means thinking about your users—including making your site accessible to everyone. You want as many people as possible to engage with your site, and that includes those who rely on keyboard navigation or assistive technologies.

One minor but powerful way to improve web accessibility is by using the tabindex attribute. Let’s take a closer look at the tabindex attribute, how it works, and why it’s essential for making your website more user-friendly and accessible.

What Is the Tabindex Attribute?

The tabindex attribute is an HTML attribute that helps control the order in which users can move between interactive elements—like links, buttons, and form fields—using just the keyboard. For users who either can’t or prefer not to use a mouse, the ability to navigate a site using the “Tab” key is essential. This group includes people with motor disabilities, vision impairments, or even people using devices where a mouse isn’t an option.

When you press the Tab key, your focus (i.e., where your keyboard inputs go) jumps to the next interactive element on the page. By default, browsers follow a logical order based on the structure of the page’s HTML, starting from the top of the page and moving down. But sometimes, you’ll want to fine-tune that order, and this is where the tabindex attribute comes into play.

How Does Tabindex Work?

There are a few different values you can assign to the tabindex attribute, each of which affects how elements are navigated:
- tabindex= "0": This means the element will follow the natural tab order as defined by the document’s structure, but it ensures that the element is focusable.
- tabindex= "-1": This removes an element from the tab order, making it not focusable via the keyboard, but it can still be focused by other methods (like using JavaScript). This is useful for things like modal windows, which you only want to be accessible in specific scenarios.
- Positive tabindex values (e.g., tabindex= "1" ): Using positive values lets you create a custom tab order. Only use positive tabindex values if you know what you’re doing!
Best Practices for Using Tabindex

If you’re new to using the tabindex attribute, it might seem simple at first glance, but there are a few essential best practices to follow. These will help you avoid common pitfalls and ensure your site remains accessible and easy to navigate.

Stick to tabindex= "0" for Most Cases

When you want to make an element focusable, it’s almost always best to use tabindex= "0". This keeps the element in the natural tab order, ensuring users can move through the page logically. Using higher positive values to create a custom order can confuse users, especially those using assistive technologies like screen readers.

Here’s an example of how to use tabindex= “0”:
```
<div role="button" tabindex="0">Submit</div>
<a tabindex="0">Learn more</a>
```
Use tabindex= "-1" for Hidden or Conditional Elements

Some elements shouldn’t be part of the regular tab order until they’re needed. For example, if you have a modal that opens up after a button is clicked, it doesn’t make sense for a modal to be focusable before it’s visible. This is where tabindex= "-1" is useful.

Here’s how you might use it for a modal:
```
<div id="myModal" tabindex="-1">
  <p>This is a modal window.</p>
  <button>Close</button>
</div>
```
When the modal is triggered (through JavaScript), you can set focus to it programmatically:
```
document.getElementById('myModal').focus();
```
This ensures the modal is accessible when needed without cluttering the tab order when it’s not.

Test Your Website with Keyboard-Only Navigation

A simple but effective way to check if your tabindex usage is on point is to navigate your site using only the keyboard. Press the Tab key to move forward through the interactive elements, and use Shift+Tab to go backward. Does everything flow smoothly? If you find yourself jumping around the page or missing critical elements, it might be time to revisit your tab order.

Common Mistakes to Avoid

While the tabindex attribute is incredibly useful, it’s also easy to misuse. Here are some common mistakes you’ll want to steer clear of:

Overusing Positive Tabindex Values

It might be tempting to assign custom tab orders everywhere, but overdoing it can lead to a confusing and inconsistent experience. Stick with the natural tab order unless you have a compelling reason to change it.

Skipping Interactive Elements

Make sure that all essential interactive elements—like buttons, form fields, and links—are keyboard-focusable. You don’t want users who rely on keyboard navigation to miss important parts of your site because they’ve been removed from the tab order.

Using Tabindex Instead of Proper HTML

It’s always best to use semantic HTML first. Instead of creating a clickable div with a tabindex= "0", use an actual <button> or <a> element. Not only does this help with accessibility, but it also provides better browser support and consistency across devices.

How Does Tabindex Relate to Web Accessibility Guidelines?

You’ve probably heard of the Web Content Accessibility Guidelines (WCAG) if you’ve been reading up on accessibility. These guidelines are designed to make web content more accessible to people with disabilities, and they’re the foundation of legal requirements like the Americans with Disabilities Act (ADA).

When it comes to keyboard navigation, WCAG has some specific guidelines that tabindex helps address:
- WCAG 2.1.1 Keyboard: All site functionality should be operable through a keyboard interface.
- WCAG 2.4.3 Focus Order: Navigating through content should follow a logical order that doesn’t confuse the user.
Using tabindex correctly is a step toward ensuring that your website meets these standards, helping you create a more inclusive and legally compliant experience.

Tabbing It All Together

The tabindex attribute is a powerful yet often overlooked tool in web accessibility. When used correctly, it not only aids users with visual or motor impairments but also enhances the overall user experience for everyone navigating your site. Ensuring that your website is accessible isn’t just about compliance with standards like WCAG and ADA—it’s about making your content reachable and usable for all.

Ready to make your website more inclusive and user-friendly? Schedule an ADA briefing with 216digital today. Our team of experts will guide you through the nuances of web accessibility, helping you implement best practices like proper tabindex usage. Let us help you create a more inclusive and legally compliant digital space.
Bobby

October 15, 2024

How-to Guides

Accessibility, ADA Compliance, How-to, tabindex, WCAG, web development
Web Accessibility Tips for Restaurants in 2024
As a restaurant owner, creating an accessible and welcoming environment doesn’t just apply to your physical space—it’s equally important online. In 2024, web accessibility is no longer optional. With more diners relying on digital services like online menus and reservation systems, it’s crucial that everyone, regardless of ability, can easily navigate and interact with your website. This guide will walk you through some key ways to make your restaurant’s digital experience accessible for all, including compliance with the latest Web Content Accessibility Guidelines (WCAG).

What is Web Accessibility?

Web accessibility is the practice of creating digital content that can be easily used by individuals with disabilities. This means ensuring that people with visual, auditory, motor, or cognitive disabilities can easily access and interact with your content.

For restaurants, this means making sure that your digital menu and reservation systems are easy to use for everyone, whether they navigate with a mouse, keyboard, or screen reader. But making your website accessible isn’t just about being inclusive—it also helps you meet legal requirements like the Americans with Disabilities Act (ADA).

WCAG Guidelines for Restaurants

WCAG is the global standard for web accessibility. To ensure your restaurant’s website is accessible, you should aim for compliance with WCAG 2.1 at Level AA. Some of the key WCAG principles to keep in mind include:
- Perceivable: Users must be able to experience content, whether through text, images, or other formats like captions.
- Operable: Users should be able to navigate the site with a mouse, keyboard, or voice commands.
- Understandable: The site’s information and operations should be clear and easy to use.
- Robust: The site should work with current and future assistive technologies.
Let’s break down how these principles apply to specific elements of your restaurant’s website, such as menus and reservation systems.

How to Share Your Menu Accessibly

Your menu is the core of your restaurant’s website, and making it accessible can open up your business to more customers. Start by ensuring that your menu is coded properly so that all users can access it. Avoid using PDF formats, which can be difficult for screen readers to interpret.

Use Semantic HTML

Semantic HTML is the building blocks for an accessible website. By using proper HTML tags, you provide structure and meaning to your content, making it easier for users to understand the structure of your content. For a menu, you can use <div> to separate menu items and <span> or <p> for the item’s name, price, and description.

Here’s a sample code snippet for a restaurant menu using semantic HTML:
```
<div class="menu-item-text">
   <h3 class="menu-item-heading">
      <span class="menu-item-name">Bruschetta</span>
      <span class="menu-item-price">$12.90</span>
   </h3>
   <p class= "menu-item-desc">Crispy toasted bread topped with fresh tomatoes, garlic, basil, and a drizzle of balsamic glaze.
   </p>
</div>
```
Provide Text Alternatives for Images

If your menu includes images of dishes, be sure to include alternative text (alt attributes) to describe them. Screen readers use this alt text to inform users what is in the image.

For example:
```
<img src= "grilled-salmon.jpg" alt= "Grilled salmon with mashed potatoes and steamed vegetables"/>
```
Alt text should describe the content of the image in a way that makes sense contextually. In this case, it’s about what the dish looks like and what ingredients are included.

How to Describe Your Menu Items

When writing descriptions for menu items, keep in mind that clear, concise descriptions benefit everyone, especially people with cognitive disabilities. Use simple language and avoid jargon or overly complex phrases. If you have menu items that cater to specific dietary restrictions (e.g., gluten-free or vegan options), make sure these are clearly labeled.

You could add a label like this:
```
<p><strong>Gluten-Free:</strong> Yes</p>
<p><strong>Vegan:</strong> No</p>
```
By making your menu easy to read and accessible, you’re not only helping users with disabilities but also improving the overall user experience.

How to Improve Reservation Booking Accessibility

Online reservations are convenient for both customers and restaurants, but it’s important to make sure your booking system is accessible to all users. Whether you’re using a third-party booking platform or a custom-built system, accessibility should be a top priority.

Use Accessible Form Controls

Forms are a key part of most reservation systems, and making sure these are accessible is essential. First, ensure that every form element has an associated <label> tag. This allows screen readers to correctly identify form fields.

Here’s an example:
```
<label for="name">Name:</label>
<input type="text" id="name" name="name" required>
```
Also, be sure that all form controls can be navigated using only a keyboard. According to WCAG, all interactive elements should be operable through keyboard commands alone. This is important for people with mobility impairments who may not use a mouse.

ARIA Roles and Live Regions

Accessible Rich Internet Applications (ARIA) roles help make dynamic content more accessible. For example, you can use ARIA attributes to alert users of changes in the reservation system, such as confirming their booking.

Here’s an example of using ARIA for a live region that confirms a reservation:
```
<div aria-live="polite" id="confirmation-message">
  Your reservation has been confirmed.
</div>
```
The aria-live= “polite” attribute ensures that screen readers announce updates to the user without disrupting the current interaction.

Timeouts and Error Handling

When implementing a reservation system, make sure that users are given enough time to complete their forms. WCAG 2.1 guidelines recommend providing a way to extend time limits if necessary.

Additionally, clear and helpful error messages should be provided when users make mistakes while filling out forms. Use ARIA to ensure that these messages are communicated to users with assistive technology:
```
<div aria-live="assertive" class="error-message">
  Please enter a valid phone number.
</div>
```
By following these steps, you make it easier for all customers to book a table at your restaurant, ensuring they have a positive experience.

Keyboard Navigation

Make sure that all interactive elements, like buttons and links, can be accessed using a keyboard. This is crucial for people with mobility issues. A logical tab order should guide users through your site efficiently, moving from the main content areas to interactive elements like forms and buttons.

To test this, try navigating your site using only the “Tab” key and see if you can access all functions.

Accessible Calendar Widgets

If your reservation system includes a date picker, make sure it is keyboard-accessible. Some date pickers are difficult to navigate with a keyboard or screen reader, so consider providing users with an accessible alternative, like allowing manual date entry in addition to the calendar.

Here’s an example of a keyboard-friendly date input:
```
<input type="date" id="reservation-date" name="reservation-date">
```
Going Beyond Compliance: User Experience Matters

Meeting WCAG standards is important, but don’t stop there. Think about the overall user experience. For instance, ensuring text contrast is high enough for readability, using large touch targets for buttons, and testing your website on multiple devices can significantly improve accessibility.

An accessible website isn’t just for compliance—it’s a way to expand your customer base and create a better experience for everyone.

A Taste of Accessibility

Web accessibility is the secret ingredient to running a successful restaurant in 2024. By aligning your website with WCAG guidelines, you can ensure that everyone—from loyal customers to new diners—enjoys a smooth and inclusive experience, whether they’re browsing your menu or making a reservation. Beyond just compliance, an accessible site reflects your commitment to every guest, enhancing your reputation and widening your customer base.

At 216digital, we can help you navigate the world of web accessibility, from ADA compliance to optimizing your user experience. Schedule a free ADA briefing with us today and discover how your restaurant’s website can cater to every customer, no matter their abilities. Let’s make your digital presence as inviting as your dining room!
Greg McNeil

October 9, 2024

How-to Guides

ADA Website Compliance, How-to, Restaurants, WCAG, WCAG Compliance, web development, Website Accessibility
The Hidden Accessibility Barriers in Popular Plugins

Plugins offer an easy way for blogs or e-commerce websites to add helpful functionality like newsletter signups, product filters, or bundles to their website without paying costly development fees. But while these popular plugins promise seamless user experiences, many hide serious accessibility barriers that can exclude people with disabilities from entirely using your site.

Even if you follow accessibility guidelines and best practices throughout your site, plugin vendors may not do the same, which causes your website to become non-conformant despite your excellent work. Understanding how plugins can impact web accessibility is essential to maintaining an accessible website, even if you install them to accomplish simple tasks.

Let’s explore the common accessibility pitfalls of plugins and what you can do to avoid introducing accessibility errors on your website when utilizing them.

What Are Plugins, and Why Do They Matter for Accessibility?

Plugins are pre-built software modules you can add to your website to perform specific tasks. Whether improving SEO, adding an image slider, or embedding a social media feed, plugins extend your website’s features without needing custom development.

However, plugins don’t always come with accessibility in mind. Many developers focus on functionality and design, overlooking essential elements that make their plugins usable for all, especially people with disabilities who use assistive technology.

Plugins become a problem when they introduce barriers that prevent users from navigating or interacting with your site. Even if the rest of your website is built according to accessibility standards, a plugin can break that accessibility with one update or feature.

Common Accessibility Barriers in Popular Plugins

So, what does an inaccessible plugin look like? These issues can be subtle and not immediately apparent to someone without accessibility experience. Here are a few common barriers often found in popular plugins:

1. Poor Keyboard Navigation

Many users with mobility impairments or visual disabilities rely on a keyboard to navigate a website. A plugin that lacks proper keyboard navigation can make it impossible for these users to interact with your site. For example, sliders, pop-up forms, or dropdown menus in some plugins may trap keyboard users, preventing them from moving between page elements using the Tab key.

One primary culprit is the “tabindex” attribute, which allows developers to control the order in which interactive elements are focused. Some plugins misuse this attribute, causing the focus to jump around illogically, making navigation difficult or impossible.

2. Lack of ARIA Landmarks and Roles

ARIA (Accessible Rich Internet Applications) roles and landmarks are essential for users who navigate using screen readers. These assistive technologies rely on ARIA to communicate the structure and purpose of elements on the page. When plugins don’t correctly implement ARIA roles—such as mislabeling buttons or failing to designate headings—it becomes harder for users to understand the content.

For instance, a popular image gallery plugin may not correctly assign ARIA roles to buttons for navigating between photos. To a screen reader user, those buttons may be entirely invisible, making the gallery feature inaccessible.

3. Inconsistent Focus Indicators

Focus indicators are visual cues that help users see which element on the page is currently selected, such as a glowing outline around a button. These indicators are crucial for keyboard users, but many plugins either remove or don’t include focus indicators at all, leaving users stranded without knowing where they are on the page.

A typical example is sliders that fail to highlight which slide is active or forms where the submit button doesn’t show any visual indication of focus.

4. Non-Semantic HTML and Improper Heading Structure

Semantic HTML, which uses elements like <nav>, <article>, and proper headings (<h1>, <h2>), helps assistive technologies interpret content. Unfortunately, some plugins rely on non-semantic HTML—like using <div> or <span> elements for interactive content or headings—which screen readers may not understand as intended.

For example, a form plugin that uses <div> for form fields instead of <label> elements makes it difficult for screen readers to identify the label of each field, leading to confusion for the user.

5. Missing or Incorrect Alt Text

Images used in plugins, especially image-heavy ones like sliders or galleries, often lack alternative text. Alt text is essential for visually impaired users who rely on screen readers to describe the content of images. Without it, users are left in the dark about the purpose of the images in the plugin.

Some plugins automatically generate alt text, but they may do so incorrectly—using file names or generic labels like “image123,” which provide no meaningful information to users.

WCAG Guidelines: How Plugins Often Fall Short

The Web Content Accessibility Guidelines (WCAG) are the gold standard when it comes to web accessibility, but many plugins fail to meet these guidelines. Here’s how:

Perceivable

Plugins often fail to provide text alternatives for non-text content, like images and icons. This makes it impossible for screen readers to convey the content to users who are blind or have low vision.

Operable

As mentioned, poor keyboard navigation is a major issue with plugins. Any plugin that doesn’t allow users to operate all of its functions via keyboard alone falls short of this WCAG principle.

Understandable

Plugins that misuse ARIA roles or use non-semantic HTML can create confusion for users of assistive technology, making the content harder to understand.

Robust

Many plugins don’t integrate well with assistive technologies. A plugin that only works in one browser or on certain screen readers is not robust enough to be considered accessible.

How to Handle Inaccessible Plugins

So, what should you do if you suspect that a plugin on your site is inaccessible? Here are a few practical tips:

1. Evaluate the Plugin for Accessibility Barriers

First, you’ll want to check to see if the plugin vendor has any posted policies or guidance regarding web accessibility. After that, you can install the plugin in a test environment and use standard evaluation tools such as WAVE or Google Lighthouse to determine if any issues appear.

2. Consider Replacing the Plugin with an Accessible Alternative

If you find that a plugin is inaccessible, consider replacing it with a more accessible competitor. For example, there are many form, slider, and gallery plugins designed with accessibility in mind. These often prioritize compliance with WCAG guidelines, making it easier for your site to remain accessible.

3. Reach Out to Plugin Developers

If you’re committed to a specific plugin that has accessibility issues, don’t hesitate to reach out to the developer. Politely inform them of the barriers their plugin creates and ask if they have plans to address accessibility in future updates. Many developers are open to feedback and may not be aware of the issues until they are brought to their attention.

4. Use ARIA Landmarks and Roles to Improve Plugin Accessibility

If you have some technical knowledge, you can manually add ARIA roles or improve the HTML structure of the plugin elements. While this is a more advanced solution, it can be effective in making a plugin more accessible.

5. Test Regularly with Accessibility Tools

Tools like WAVE or Lighthouse can help you assess the accessibility of your entire site, including any plugins you’ve added. Regular testing can ensure that your site remains accessible as plugins update and evolve over time.

Plugins Are Powerful—But Watch Out for Hidden Barriers

Plugins are a fantastic way to improve your website’s functionality, but they can also introduce hidden accessibility barriers if you’re not careful. As a website owner or developer, it’s your responsibility to ensure that every part of your site, including third-party plugins, is accessible to all users.

By being proactive—whether through testing, replacing, or communicating with developers—you can avoid the common pitfalls of inaccessible plugins and keep your site welcoming and functional for everyone. Remember, it’s not just about compliance; it’s about creating an inclusive experience that ensures all users can access and interact with your content.

So, next time you’re about to install that flashy new plugin, pause for a second and ask yourself: Is this accessible?

Ready to get started? Schedule a personalized ADA briefing with 216digital and get expert guidance tailored to your needs.

Greg McNeil

October 7, 2024

How-to Guides, Legal Compliance

ADA Compliance, plugins, Web Accessibility, web development, website plugins
What is Keyboard Navigation?
Have you ever tried navigating a website without a mouse, using only your keyboard? If not, it’s an eye-opening experience. For many users with disabilities, keyboard navigation isn’t just an option—it’s essential. Keyboard accessibility ensures that users who rely on keyboards can interact with your website effectively. Let’s dive into what keyboard accessibility is, why it matters, and how you can implement it on your website.

What is Keyboard Navigation?

Keyboard navigation allows users to interact with a website without the need for a mouse. Instead of pointing and clicking, users rely on keyboard keys—like the Tab, Enter, and arrow keys—to move through web content. This form of navigation is vital for individuals with mobility impairments, vision impairments, or anyone who cannot use a mouse due to injury or physical limitations.

For example, users can move from one link or button to the next using the Tab key and activate the selected item with Enter or Space. Think of it as a roadmap through your website, where each interactive element is a stop along the way. If your site isn’t set up for proper keyboard navigation, some users may get lost or, worse, be unable to use your site altogether.

Why Keyboard Accessibility is Important

Keyboard accessibility plays a crucial role in web usability, particularly for people with disabilities. Here’s why:
1. For Users with Disabilities: Many individuals rely on assistive technologies, like screen readers or alternative input devices, to access websites. These technologies are often keyboard-based. Without proper keyboard navigation, these users may be blocked from interacting with your site.
2. WCAG Guidelines: The Web Content Accessibility Guidelines (WCAG), which serve as the global standard for web accessibility, emphasize the need for keyboard accessibility. WCAG 2.1, for example, highlights explicitly that all functionality should be operable through a keyboard interface (SC 2.1.1 – Keyboard).
3. Compliance with Laws: In the U.S., legal frameworks like the Americans with Disabilities Act (ADA) can hold websites accountable for not being accessible to people with disabilities. Making your site accessible isn’t just good for your users—it can also help you avoid legal trouble.
Implementing Proper Keyboard Navigation

Keyboard navigation isn’t just about letting users “tab” through your site. It’s about ensuring a smooth, logical, and functional user experience. Let’s look at some key steps to making your site keyboard-friendly.

Make All Interactive Elements Accessible

Every element that a user can interact with—like buttons, links, forms, and dropdown menus—should be accessible by the keyboard. This means ensuring that as a user “tabs” through the page, they can reach these elements and activate them without needing a mouse.

Here are a few ways to achieve this:
- Use semantic HTML: Elements like <button>, <a>, and <input> are inherently keyboard-accessible. If you create custom interactive elements with <div> or <span>, ensure they are accessible by adding tabindex= "0" and using JavaScript to handle key events like pressing “Enter” or “Space” to activate them.
- Avoid tabindex misuse: While tabindex= "0” ensures elements are focusable in the tab order, using tabindex values other than 0 can cause issues with navigation. Elements should appear in the tab order based on their natural position in the document flow.
Example:
```

<button>Submit</button>
<a href="contact.html">Contact Us</a>

<div role="button" tabindex="0" onclick="alert('Button clicked')">Click me</div>
```
Ensure Logical Tab Order

When users navigate your website using the Tab key, they should move through the content in a logical order. If the tab order is confusing, users can miss important information or interactive elements. The order should generally follow the visual structure of the page, moving left to right and top to bottom.

Best Practices for Logical Tab Order:
- Check the natural tab order: Test your site by navigating with the Tab key. Does it follow the expected order? Are there elements that seem out of place or skipped entirely?
- Avoid skipping key elements: Ensure that every interactive element is included in the tab order. Hidden or inactive elements should not be focusable until they are visible or active.
Use Clear Focus Indicators

When a user navigates with their keyboard, they rely on focus indicators to know where they are on the page. Without a clear visual indicator, users may become lost.

What’s a Focus Indicator?

The focus indicator is a visible outline or highlight that shows which element is currently selected. For example, by default, most browsers add a visible outline to buttons, links, and form fields when they are focused.

Best Practices for Focus Indicators:
- Don’t disable default focus outlines: Some designers remove these outlines for aesthetic reasons, but this is a big no-no for accessibility.
- Customize focus styles: If the default outline doesn’t fit your design, you can customize it. Just make sure the indicator is clear and easy to see.
Example:
```
/* Customize focus outline */
button: focus, a: focus {
    outline: 2px solid #007BFF; /* High contrast color */
}
```
Avoid Keyboard Traps

A keyboard trap occurs when a user navigates into a section of the page but can’t get out using the keyboard. This can happen if a dialog box or modal window doesn’t allow the user to tab away or close it using keyboard commands.

Best Practices to Avoid Keyboard Traps:
- Ensure users can tab away: If a modal or popup appears, users should be able to close it or continue navigating the rest of the site with the Tab key.
- Provide a clear way to exit: Offer an accessible “Close” button or an “Esc” key option to dismiss popups.
Example:
```

<div role="dialog" aria-labelledby="modal-title" aria-describedby="modal-description">
    <h2 id="modal-title">Modal Title</h2>
    <p id= "modal-description">This is a description of the modal.</p>
    <button onclick="closeModal()">Close</button>
</div>
```
Referencing WCAG Guidelines

To meet web accessibility standards, your site should align with the WCAG guidelines, particularly the following:
- WCAG 2.1.1 – Keyboard: Ensure all content and functionality can be accessed using a keyboard.
- WCAG 2.4.3 – Focus Order: Make sure users can navigate through the page in a logical sequence.
- WCAG 2.4.7 – Focus Visible: Provide a clear indicator of focus when keyboard navigation is used.
These guidelines are vital for ensuring that your site is accessible to all users, including those who depend on keyboard navigation.

Making Your Website Accessible for All

Keyboard navigation is not just about compliance—it’s about ensuring that every visitor can use your site, regardless of their physical abilities. By focusing on proper keyboard navigation, logical tab order, clear focus indicators, and avoiding keyboard traps, you’re creating an inclusive experience that benefits all users. Whether it’s improving the experience for users with disabilities or meeting the legal requirements of the ADA, the rewards of accessibility are significant.

Implementing these changes might feel overwhelming, but you don’t have to go it alone. 216digital specializes in making websites accessible, ensuring they meet WCAG standards and ADA compliance. Our human-centered approach focuses on both the user experience and reducing legal risks.

Ready to make your site accessible? Schedule an ADA compliance briefing with 216digital today, and let us guide you through the process of creating a website that’s usable for everyone.
Greg McNeil

October 4, 2024

How-to Guides

Accessibility, How-to, Keyboard Navigation, WCAG, WCAG Compliance, Web Accessibility, web development

What Are Touch Targets and Why Are They Important?

WCAG Guidelines: Key Standards for Touch Target Size

Success Criterion 2.5.5 (Target Size)

Success Criterion 2.5.8 (Target Size – Enhanced)

Best Practices for Designing Accessible Touch Targets

Use Adequate Padding and Margin

Ensure Minimum Width and Height

Space Out Interactive Elements

Add ARIA Attributes for Enhanced Accessibility

Responsive Design: Ensure Touch Target Size Across Devices

Testing Touch Target Accessibility

Wrapping Up

Why Accessibility in React Matters

Setting Up an Accessibility-Friendly Development Environment

Installing eslint-plugin-jsx-a11y

The Power of Semantic HTML in React

Examples of Semantic HTML in React

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

Enhancing Accessibility with ARIA Roles (But Use Them Wisely)

Using aria-label for Accessibility

Dynamic Updates with aria-live

Keyboard Accessibility and Focus Management

Setting Focus with useRef and useEffect

Avoiding Focus Traps

Best Practices for Accessible Interactive Elements

Provide Clear Labels for Inputs

Accessible Modals

Testing Focus

Managing Screen Reader Navigation in SPAs

Example: Setting Focus on Page Updates

Testing Your React App for Accessibility

Conclusion

Why Keyboard Accessibility Matters

Common Barriers to Keyboard Accessibility

Lack of Focus Indicators

Improper Tab Order

Focus Traps

ARIA Widgets and Their Challenges

Why ARIA Widgets Often Fail

Reliance on ARIA Without Semantic HTML

Overuse of role and tabindex Attributes

JavaScript-Dependent Behavior

Best Practices for Creating Keyboard-Accessible Interactive Elements

Prioritize Native HTML Elements

Use ARIA Judiciously

Enable Logical Focus Management

Include Skip Links

The Importance of Testing for Keyboard Accessibility

Conclusion

Why Start Accessibility Planning from the Beginning?

Avoid Costly Retrofits

Enhance User Experience for All

Stay Compliant and Avoid Legal Issues

How to Integrate Accessibility into Each Stage of Development

Design with Accessibility in Mind

Color Contrast and Readability

Intuitive Layout and Navigation

Descriptive Text for Buttons and Links

Use the Right HTML Tags

Proper HTML Markup

Descriptive Alt Text for Images

ARIA Attributes

Test for Accessibility as You Go

Automated Accessibility Tools

Manual Testing and Keyboard Navigation

Screen Reader Testing

Get Feedback from Users with Disabilities

Plan for Inclusive Testing

Iterate Based on Feedback

Regularly Check Your Site

Building a Culture of Accessibility

Educate and Train Your Team

Keep Accessibility Resources Available

Regularly Review and Share Accessibility Wins

Helpful Tools for Accessibility

Ready to Make Accessibility Part of Your Game Plan?

Insufficient Alt Text for Images

Why It Matters

How to Fix It

Poor Color Contrast

Installing `eslint-plugin-jsx-a11y`

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

Using `aria-label` for Accessibility

Dynamic Updates with `aria-live`

Avoid Overusing `<div>` and `<span>`

Stick to `tabindex= "0"` for Most Cases

Use `tabindex= "-1"` for Hidden or Conditional Elements