web developers Archives - Page 3 of 4/Tag

Email Accessibility: Why It Matters for Your Marketing
Did you know that many marketing emails are nearly impossible for some people to read? It’s true! People with disabilities, especially those who use screen readers, often struggle with text that isn’t coded properly or images that don’t have any descriptions. The good news is that email accessibility is simpler than you might think. In this article, we’ll explore why emails can be hard to read for people with disabilities, why you should care, and how you can start making changes today. Let’s dive in!

Why Accessibility in Emails Matters

You might be wondering, “Why should I think about email accessibility?” There are two big reasons:
1. Reach More Readers: Accessibility helps you connect with a larger audience, which means more potential customers.
2. It’s the Right Thing to Do: Many people rely on screen readers or special settings to read their messages, and they deserve the same great experience as everyone else.
Plus, consider this: There are about 61 million adults in the United States alone who have disabilities, and over one million of them are blind. Emails that aren’t accessible can stop them from reading newsletters, buying products, or joining your events. By focusing on accessibility, you’re ensuring everyone can connect with you.

The Business Case for Accessible Emails

You might ask, “Why should I spend my time on email accessibility?” Here are three compelling reasons:
1. Stay Legally Compliant: Laws like the Americans with Disabilities Act (ADA) may apply to online communication. Staying compliant avoids potential legal issues.
2. Expand Your Audience: People with disabilities make up a significant group. Including them ensures your message reaches more people.
3. Improve Content for Everyone: Accessible content benefits all users. For example, larger fonts are easier on the eyes, and descriptive link text helps people skimming emails on their phones.
In short, email accessibility isn’t just nice to have — it’s a smart move that can boost your brand and prevent legal headaches.

Why Marketing Emails Tend To Be Inaccessible

Let’s be honest: emails can be tricky. Here’s why:
- They Rely on Tables for Layout: Modern web pages use advanced CSS layouts, but many email clients don’t support them. This forces developers to use tables, which can confuse screen readers if not coded correctly.
- Limited Support for Buttons: Real <button> elements often aren’t supported. Replacing buttons with images can create accessibility issues if the images lack descriptions.
- Drag-and-Drop Tools Aren’t Perfect: Email builders like Mailchimp or HubSpot can generate messy or incomplete HTML code, leading to hidden accessibility problems.
These challenges make email accessibility tricky, but don’t worry. With a few simple steps, you can overcome these issues.

Building an Accessibility Checklist for Emails

Here’s a simple checklist to help you make your emails more accessible:

Template Setup (One-Time Fixes)
1. Add role=”presentation” to Tables: This attribute tells screen readers to ignore table structure, reducing confusion.
2. Underline Inline Links: Don’t rely on color alone to indicate links. Use underlines to make them easily identifiable.
3. Avoid Using One Big Image as Your Email: Screen readers can’t interpret a single large image. If images are disabled, subscribers will see an empty box instead of your content.
Campaign-Level Fixes
1. Add Alt Text to Every Image: Alt text provides descriptions for images. Keep it brief but clear (e.g., “Model wearing a red winter jacket”).
2. Use Semantic HTML Elements: Use <h1> for main headings, <h2> for subheadings, and <p> for paragraphs to help screen readers understand content structure.
3. Use Descriptive Links: Replace vague link text like “Click Here” with “View our winter jackets” to provide context.
Testing and QA for Your Accessible Emails

How can you ensure your emails are accessible? Test them!

Manual Testing

Use free screen readers like NVDA (Windows) or VoiceOver (Mac) to hear how your email sounds. Listening to your email read aloud is a great way to catch problems.

Automated Testing Tools

Use tools like Google Lighthouse or WAVE to scan your email’s web version for issues. Publish a temporary version, get the URL, and analyze it for errors.

A/B Testing

Test different versions of your accessible emails to see what resonates best with your audience. Compare engagement metrics to measure the impact of accessibility.

Accessibility Best Practices for Email Design

Here are additional tips for email accessibility:
1. Make It Mobile-Friendly: Ensure text, buttons, and layouts work well on smaller screens.
2. Choose Readable Fonts and Colors: Use high contrast (e.g., black text on a white background) and avoid tiny fonts.
3. Avoid Flashing or Moving Text: Fast-moving elements can be challenging for some users. Use animation sparingly.
Encouraging a Culture of Accessibility

Once you start focusing on accessibility, share your knowledge with your team:
1. Offer Mini-Trainings: Show marketing and design teams how to add alt text or check code for issues.
2. Collaborate with Developers: Work with your development team to address tricky code problems.
3. Celebrate Wins: Highlight successful accessible campaigns during team meetings to encourage continued focus.
Conclusion

Email accessibility matters because it helps people with disabilities, grows your audience, and enhances your brand’s reputation. The best part? It doesn’t have to be complicated. With simple steps like adding alt text, using descriptive links, and making your designs mobile-friendly, you can create emails that everyone can enjoy.

Take a moment to review your next email draft. Is there alt text? Are links descriptive? Are fonts readable? If so, you’re already ahead of many marketers. Keep going, and soon accessibility will become a natural part of your email marketing process, benefiting both your audience and your brand
Greg McNeil

January 3, 2025

How-to Guides, The Benefits of Web Accessibility

Accessibility, email accessibility, How-to, Web Accessibility, web developers
Making Hidden Content Accessible to Assistive Technologies
As a web developer, you want your website to be usable by everyone, including people who rely on assistive technologies. These technologies—such as screen readers, braille displays, and speech recognition software—can help individuals with disabilities navigate the web more easily. Sometimes, you may need to hide certain parts of your webpage visually without hiding them from these tools. However, doing this incorrectly can cause big accessibility issues.

In this article, we’ll explore how to effectively hide and manage hidden content for people using assistive technologies. We’ll discuss why display: none is problematic, how to use the clip pattern, and how attributes like aria-hidden and hidden can help. By the end, you’ll have a better understanding of how to ensure your website remains inclusive and user-friendly.

The Problem with display: none

When you use display: none in your CSS, you remove an element from the visual flow of the page. This means sighted users will not see it. But, it also means the element is completely invisible to assistive technologies such as screen readers. If you’ve hidden important text or controls this way, users who rely on assistive technologies might miss out on content or functionality that they need.

For example, imagine you have a button that visually looks like an icon, but you hide the text label using display: none. Now, people who can see the icon know what the button does, but people using assistive technologies hear nothing. This creates a poor user experience and makes your site less accessible.

The Clip Pattern: A Better Approach

To visually hide content while keeping it available to assistive technologies, the clip pattern is a popular solution. The idea is to position the element off-screen so sighted users don’t see it, but screen readers can still find it. Here’s an example:
```
.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  border: 0;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
}
```
By applying the .visually-hidden class to your element, you ensure it’s hidden visually but remains accessible to assistive technologies. This makes the content discoverable by screen readers, letting users who can’t see the screen still benefit from it.

Why the Clip Pattern Works

This pattern relies on moving the element so it’s not visible in the viewport and restricting its size to 1px by 1px. With clip: rect(0, 0, 0, 0); (or clip-path in modern CSS), the browser cuts off any visual display. Yet, the element remains in the Document Object Model (DOM), meaning assistive technologies can still access it. That’s the key difference between this and display: none.

Managing Visibility with aria-hidden and the hidden Attribute

Beyond CSS, there are HTML and ARIA (Accessible Rich Internet Applications) attributes that also control how content is shown to both users and assistive technologies. Two important attributes here are aria-hidden and the HTML5 hidden attribute.

aria-hidden="true"

When you add aria-hidden="true" to an element, you’re telling assistive technologies not to read or announce that element to users. This is handy for decorative images or redundant content. For instance, if you have a background image that doesn’t provide important information, you could mark it with aria-hidden="true" so screen readers ignore it.

But be cautious: if you need an element to be read by assistive technologies, do not use aria-hidden=”true”. This attribute will block that element from being announced entirely.
```
<div aria-hidden="true">
  <img src="decorative-image.jpg" alt=""/>
</div>
```
HTML5 hidden Attribute

The hidden attribute is another way to remove content from everyone—both sighted users and assistive technologies. When you use it, browsers typically hide the element. Screen readers will also skip it. This is good if the element is meant to be inaccessible to all users, like a form section that’s not yet relevant or a menu item that’s not available.
```
<div hidden>
  <p>This content is hidden from all users.</p>
</div>
```
Use hidden or aria-hidden when you truly want to exclude an element from assistive technologies. If you want it hidden visually but still available to screen readers, you should stick with the clip pattern or .visually-hidden approach.

Best Practices for Accessible, Visually-Hidden Content

1. Use Semantic HTML

Using proper semantic HTML elements (like <nav> for navigation, <main> for main content, or <section> for thematic grouping) is important for clear structure. It helps assistive technologies interpret your content correctly. Semantic HTML also reduces the need for extra attributes and complex styling, since the markup itself conveys meaning.

2. Avoid Hiding Focusable Elements

If an element can receive focus (like links, form inputs, or buttons), think carefully before hiding it. A hidden yet focusable element can be confusing for keyboard-only users, since it might get focus without being visible. If you must hide a focusable element, consider removing it from the tab order by using tabindex="-1" or ensuring it’s properly revealed at the right time.

For example, if you have a pop-up form that appears only after a button click, you can initially hide it with the clip pattern. Once the user clicks, you can remove the clip pattern or switch the CSS to show the content. This way, the form becomes available to both sighted users and people using assistive technologies at the same time.

3. Provide Context for Hidden Content

Sometimes you want to reveal hidden content dynamically (like a drop-down menu). In these cases, use ARIA attributes such as aria-expanded and aria-controls to inform assistive technologies that a certain part of the page is now visible or hidden. This can help screen reader users understand changes on the page.
```
<button aria-expanded="false" aria-controls="menu" id="menuButton">
  Toggle Menu
</button>

<nav id="menu" class="visually-hidden">
  
</nav>
```
When you click the button, you can toggle its aria-expanded value from false to true, and remove the .visually-hidden class from the menu. This ensures that both visual and non-visual users know the content has been revealed.

4. Test with Multiple Assistive Technologies

It’s important to test your website with different assistive technologies because each one may behave slightly differently. Popular screen readers include NVDA, JAWS, and VoiceOver. Don’t forget to check on both desktop and mobile devices. Regular testing can help you catch accessibility issues before your users do.

Handling Localization

If you’re translating your site into multiple languages, remember that hidden text might also need translation. For example, your .visually-hidden text for instructions or links should be available to screen readers in every supported language. Make sure your language attributes (like lang="en") are correct, and consider cultural differences that could impact how you label hidden elements.

For instance, if you have an English site and a Spanish site, your hidden instructions should be translated into Spanish on the Spanish version. This ensures that users relying on assistive technologies can access the content in the correct language.

Putting It All Together: A Quick Example

Let’s look at a simple example of an accessible button that has visually hidden text:
```
<button class="icon-button">
  <span class="visually-hidden">Submit Form</span>
  <img src="icon-submit.png" alt="" aria-hidden="true" />
</button>
```
- The .visually-hidden class hides the text “Submit Form” from sighted users, but screen readers can still read it.
- The <img> tag includes an empty alt attribute and aria-hidden="true", so assistive technologies ignore the image itself.
- Sighted users see only the icon, while screen reader users hear “Submit Form.”
This example keeps your content accessible to people using assistive technologies and also meets visual design needs.

Additional Resources
- Web Content Accessibility Guidelines (WCAG): A detailed guide on making web content accessible.
- WAI-ARIA Authoring Practices: Official tips on using ARIA roles, states, and properties.
- MDN Web Docs on ARIA: In-depth explanations of ARIA attributes and best practices.
Exploring these resources will help you master hiding content effectively, ensuring people who use assistive technologies can still access everything they need.

Conclusion

Hiding content from sighted users while keeping it accessible to assistive technologies is an essential skill for modern web developers. By avoiding display: none for important information, using the clip pattern for visually hidden content, and carefully leveraging aria-hidden or hidden, you can ensure everyone has a good experience on your site.

Remember to keep the following points in mind:
1. Use the clip pattern (.visually-hidden) to hide content from sighted users but keep it readable by assistive technologies.
2. Use aria-hidden and hidden only when you truly want to hide content from all users, including those using assistive technologies.
3. Pay attention to focusable elements, making sure you don’t accidentally trap keyboard users in hidden sections.
4. Test frequently with various tools and real users to ensure your hidden content behaves as you expect.
5. Localize your hidden text so that people using assistive technologies in other languages can also benefit.
By following these guidelines, you’ll be well on your way to building inclusive websites that work for everyone. Your careful attention to accessibility shows that you value all your users, regardless of their abilities or the assistive technologies they use. Embracing these practices will help ensure a positive, welcoming, and user-friendly experience across the board.
Greg McNeil

December 31, 2024

How-to Guides

Accessibility, assistive technology, How-to, web developers, web development, Website Accessibility
Play Your Part: Role-Based Advice for Web Accessibility

When you first dive into web accessibility, it’s completely normal to feel a bit overwhelmed—there are so many things to consider. But making sure your website works for everyone isn’t just a one-time fix; it’s a group effort that involves every role on your team. Developers, designers, content creators, marketers, and website owners all contribute their own strengths and insights. When everyone’s efforts line up, you create a smooth, inclusive experience for all your users.

This guide is for teams who are already working on—or are fully committed to—improving their websites. It’s packed with practical, role-specific tips to help you approach accessibility in a way that’s both strategic and effective. Whether you’re refining your code, fine-tuning your visuals, crafting inclusive content, or ensuring your brand message is accessible, you’ll find helpful, targeted advice for your particular responsibilities. Together, these steps ensure your site meets the needs of every user while staying on top of WCAG compliance. Let’s jump in and see how each role plays a part in building a more accessible web.

Developers: Building the Accessible Foundation

Developers form the core of any website—they’re the ones who take an idea and turn it into a working reality. When it comes to WCAG compliance, the quality of your code truly matters. By following accessibility best practices from the get-go, you help guarantee that everyone can use your site, right from the start.

Practical Tips for Developers

Semantic HTML and Proper Structure

Use semantic HTML elements like <header>, <nav>, <main>, and <footer> to support screen readers and other assistive tech. Keep headings and landmarks organized, so users can navigate your site with ease.

Keyboard Navigation

Make sure all interactive elements—buttons, links, and form fields—work smoothly using just a keyboard. This isn’t just about meeting standards; it’s also a big help to people with motor impairments who can’t rely on a mouse.

ARIA Attributes

ARIA (Accessible Rich Internet Applications) attributes can add valuable context, but use them wisely. Overdoing it can confuse rather than help.

Robust Error Handling

Provide clear, accessible error messages and confirmations for form submissions. When users understand what went wrong and how to fix it, they’re more likely to stay engaged.

By building accessibility directly into your code, you set a strong foundation for WCAG compliance and create a reliable platform that benefits every other role on your team.

Graphic Designers: Creating Inclusive Visuals

Graphic designers can help shape accessibility by making sure the website’s visual elements are both attractive and functional. You don’t have to sacrifice creativity for inclusivity—instead, design with everyone’s needs in mind.

Practical Tips for Graphic Designers

Color Contrast

Ensure there’s enough contrast between text and background elements. Check your color choices against WCAG guidelines so people with low vision or color blindness can still see everything clearly.

Scalable Designs

Plan for responsive and scalable design. Users who rely on screen magnification should still see a layout that’s visually appealing and makes sense.

Accessible Icons and Imagery

Give icons and images proper alt text, and avoid using color alone to convey meaning. This helps users who depend on screen readers understand your site’s visuals.

Consistent Design Patterns

Reusable design elements and predictable navigation make it easier for everyone, including those with disabilities, to find their way around.

By focusing on inclusive visuals, you ensure the site looks great and works smoothly—even for those using assistive technologies—moving you one step closer to WCAG compliance.

Content Creators: Writing for All Audiences

Your words matter. As a content creator, it’s your job to make sure the text on your website is clear, easy to understand, and accessible to everyone. Inclusive content goes beyond grammar and style; it also means structuring your writing to support people with different abilities.

Practical Tips for Content Creators

Plain Language

Keep your language simple and direct. Steer clear of jargon or overly complex sentences so users of all backgrounds and reading levels can follow along.

Heading Hierarchies and Lists

Break content into logical sections with headings, bullet points, and numbered lists. Many users rely on these elements to “jump” between sections and navigate quickly.

Descriptive Links

Swap out vague phrases like “click here” for links that clearly describe the destination. This small change can make a huge difference in accessibility.

Closed Captions and Transcripts

For videos and podcasts, always provide captions and transcripts. This ensures that users who are deaf or hard of hearing don’t miss out on any information.

By considering everyone’s needs when writing content, you help make your site more engaging, accessible, and in line with WCAG standards.

Marketers: Promoting Accessibility as a Brand Value

Marketers bridge the gap between the company and its audience. When you emphasize accessibility in your messaging, you’re not just showing you meet the guidelines—you’re proving you care. Highlighting your commitment to WCAG compliance can foster trust, build loyalty, and boost your brand’s reputation.

Practical Tips for Marketers

Inclusive Messaging

Talk openly about your brand’s dedication to accessibility. Use language that’s positive, empathetic, and respectful, making it clear that you value inclusivity.

Transparent Policies

Publish your accessibility statements and share your ongoing efforts. This honesty reassures people with disabilities and shows your brand is serious about doing the right thing.

Social Media and Email Marketing

Ensure your emails, ads, and social posts are accessible, too. Add alt text to images, use clear language, and include descriptive hashtags so everyone can participate.

Continuous Feedback

Invite users to share their thoughts on your site’s accessibility. By listening and improving, you show that your commitment to WCAG compliance isn’t just talk.

When marketers celebrate their brand’s accessibility journey, they create a positive narrative that resonates with a wide, diverse audience and strengthens brand loyalty.

Website Owners: Setting the Vision and Investing in Ongoing Compliance

As a website owner, you’re the one steering the ship in terms of resources, priorities, and long-term strategy. Achieving WCAG compliance isn’t something you do once and forget—it’s a continuous process. Owners need to keep accessibility front and center, provide the right tools, and foster a culture that values inclusive design.

Practical Tips for Website Owners

Leadership and Accountability

Make accessibility a non-negotiable core value. By setting clear expectations and holding everyone accountable, you empower each team member to do their part.

Budget for Accessibility

Invest in accessibility tools, auditing services, and training. Recognize that these efforts aren’t just expenses—they add value, protect you from legal risks, and improve user experience.

Regular Audits and Updates

Accessibility changes over time. Stay on top of it by revisiting your site regularly and making improvements as standards and user needs evolve.

Team Training

Tap into resources like 216digital’s web accessibility training to give your team the skills they need. By training developers, designers, content creators, and marketers, you ensure everyone’s working together toward WCAG compliance.

By providing clear leadership and long-term support, you set the stage for ongoing success. Accessibility becomes everyone’s priority, not just another item on a checklist.

Collaboration and Continuous Improvement

The journey to WCAG compliance isn’t a straight line—it’s a continuous loop of learning, adapting, and improving. When each person on your team understands their unique role and how it fits into the bigger picture, the result is a cohesive, user-friendly experience that truly works for everyone.

This is where a comprehensive training resource like the one from 216digital comes in handy. By investing in accessibility training that’s tailored to each role, you make sure every team member feels confident and supported. Developers learn best practices for semantic code, designers refine their approach to inclusive visuals, content creators craft language everyone can understand, and marketers become champions of accessibility. As a website owner, you can rest easy knowing your entire team is dedicated to meeting and maintaining WCAG compliance.

Remember, accessibility isn’t a final destination—it’s an ongoing journey. Working together and following these role-specific tips will help you build sites that aren’t just legally compliant, but genuinely welcoming to every visitor. This approach enhances trust, expands your audience, and reinforces your brand’s good name.

Ready to take the next step? Schedule an ADA briefing with 216digital through the contact form below. Let’s join forces to create a web experience that’s truly inclusive for all.

Greg McNeil

December 19, 2024

WCAG Compliance

Accessibility, ADA Compliance, Graphic Designer, Marketer, Web Accessibility, web developers, Website Accessibility
How to Make Data Tables Accessible

Data tables are a powerful way to present structured information, but without proper attention to accessibility, they can exclude users with disabilities. Whether you’re a developer, content creator, or website owner, learning how to make your tables user-friendly for everyone is an essential skill.

Accessibility standards like WCAG (Web Content Accessibility Guidelines) provide the foundation for creating inclusive data tables. By following best practices such as structuring your tables properly, adding meaningful headers, and ensuring compatibility with assistive technologies, you can enhance usability while meeting legal and ethical standards.

Understanding the Basics of Accessible Tables

Before diving into the specifics, it’s important to understand what makes a table accessible. Accessible tables are designed to be navigable and understandable by all users, including those who rely on screen readers or keyboard navigation. This means paying attention to the structure, design, and additional information like captions and summaries.

The foundation of an accessible table lies in its structure. HTML provides semantic elements like <table>, <thead>, <tbody>, and <th> to organize your data logically. Using these elements correctly ensures that assistive technologies can interpret the table properly. For example, headers defined with <th> tags allow screen readers to associate data cells with their corresponding column or row, creating a more intuitive experience for users.

Adding Headers, Captions, and Summaries

Headers are one of the most critical components of an accessible table. They guide users in understanding what each data point represents. To define headers, use the <th> element, and consider including the scope attribute to indicate whether the header applies to a column, row, or group of columns and rows. For example, <th scope="col"> signals that the header applies to an entire column, while <th scope="row"> applies to a row.

Captions and summaries provide additional context for your table. A caption, placed within the <caption> tag, serves as a brief title or description of the table’s purpose. Summaries, while not an HTML element, can be included to provide a detailed explanation of the table’s content, especially if it’s complex. This can be added through the <summary> attribute or as part of surrounding content. These elements are particularly valuable for screen reader users, offering them a quick overview of what to expect.

Ensuring Compatibility with Screen Readers

Screen readers rely on well-structured and semantically correct HTML to interpret tables. To optimize compatibility, avoid using tables for layout purposes. While this practice was common in the past, it confuses screen readers by mixing presentational and data tables. Instead, use CSS for layout and reserve tables strictly for data.

Another crucial consideration is avoiding merged cells unless absolutely necessary. While colspan and rowspan attributes can be used to merge cells, they can make navigation more challenging for screen reader users. If your table requires merged cells, ensure that the relationships between headers and data are clearly defined with attributes like headers and id.

Making Tables Keyboard-Friendly

Keyboard accessibility is vital for users who cannot use a mouse. Accessible tables should allow users to navigate logically through rows and columns using only their keyboard. Test your table to ensure that tabbing through the data follows a predictable order.

One way to achieve this is by maintaining a logical document flow. Keep your table simple and organized to prevent users from getting lost. If the table is part of a larger webpage, include clear instructions and use skip links to help users bypass unrelated content.

Simplifying Complex Tables

Complex tables with nested headers or multi-level data can be difficult to navigate, even for experienced users. Simplifying these tables can go a long way toward improving accessibility. Consider breaking down large, complicated tables into smaller, more manageable ones. You can also use additional tools like expandable rows or columns to provide details without overwhelming the user.

For situations where simplifying isn’t feasible, invest extra effort in defining relationships between headers and data. Use the headers and id attributes to explicitly associate each cell with its relevant headers. This ensures that screen readers can convey the relationships accurately, even in intricate tables.

Improving Readability with Responsive Design and Contrast

Accessibility isn’t just about assistive technologies—it’s also about making content visually readable for users with low vision or cognitive challenges. Responsive design is essential for ensuring that your tables are accessible across devices. Use CSS to make your tables adapt to different screen sizes without losing clarity or functionality.

High contrast is another key factor. Choose colors that provide sufficient contrast between text and background. WCAG recommends a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Tools like WebAIM’s Contrast Checker can help you verify compliance.

Testing Your Tables for Accessibility

No matter how carefully you design your tables, testing is essential to identify and address potential issues. Start by using automated tools like the WAVE Web Accessibility Evaluation Tool to check for common errors. While these tools are helpful, they can’t catch everything, so manual testing is equally important.

Test your table using a screen reader like NVDA or JAWS to experience it as a user with visual impairments would. Pay attention to how headers, captions, and data are announced. Does the screen reader navigate the table logically? Are all elements correctly identified and described?

Keyboard testing is another critical step. Navigate through the table using only your keyboard to ensure that all interactive elements are accessible and functional.

Why Accessible Tables Matter

Accessible tables aren’t just about meeting legal requirements—they’re about creating a better user experience for everyone. By making your data tables accessible, you’re opening your content to a wider audience, including individuals with disabilities who rely on assistive technologies.

Moreover, accessibility enhances usability for all users, not just those with disabilities. Features like clear headers, logical navigation, and responsive design make tables easier to use for everyone, whether they’re on a desktop computer or a smartphone.

Conclusion

Creating accessible data tables might require extra effort, but the benefits are well worth it. By following best practices like using proper structure, adding descriptive headers and captions, and ensuring compatibility with assistive technologies, you can make your tables both compliant and user-friendly.

Remember, accessibility is an ongoing process. Stay informed about updates to guidelines like WCAG and continuously test your content to ensure it meets the highest standards. By prioritizing accessibility, you’re not just improving your website—you’re making the web a more inclusive space for all.

Ready to take the first step? Partner with the experts at 216digital, who understand accessibility inside and out. Together, we can create a web that works for everyone—and protect your business in the process. Schedule your complimentary ADA briefing today to start your journey toward an accessible and compliant future.

Greg McNeil

December 11, 2024

How-to Guides

Accessibility, Data tables, How-to, web developers, web development, Website Accessibility
Accessible Chatbots: Breaking Barriers in Support
Nowadays, customers have come to expect support and product help on-demand, 24 hours a day, 7 days a week. It is only possible for some businesses to provide human assistance at all times – that’s where chatbots come in. These tools can be invaluable to users and business owners alike, but it’s essential to ensure that people with disabilities can gain access to the same support. Let’s explore the concept of accessible chatbots.

Why Chatbot Accessibility Matters

Imagine trying to resolve an urgent issue on a website, only to find the chatbot—your primary source of help—completely unusable. For many people with disabilities, this scenario is all too common.

Accessible chatbots aren’t just about meeting legal requirements like ADA (Americans with Disabilities Act) compliance or adhering to WCAG (Web Content Accessibility Guidelines) standards; they’re about creating a seamless experience for everyone. When designed thoughtfully, chatbots can be a powerful tool for inclusivity. But when accessibility is overlooked, they can alienate an entire segment of your audience.

Common Barriers in AI Chatbots

Incompatible with Screen Readers

Many chatbots need more critical semantic HTML features like landmarks and incorrectly use HTML tags, causing a confusing or frustrating experience.

Keyboard Navigation Failures

Chatbots often lack keyboard support, requiring mouse clicks to open or interact. Users with disabilities rely on the ability to navigate content and functionality with alternative input methods like keyboards, voice commands, and gestures.

Unclear or Missing Focus Indicators

Focus indicators—the visual cues showing where a user is on a page—are often missing in chatbots. Without these, keyboard users may lose track of where they are in the conversation flow.

Overly Complex or Jumbled Responses

Chatbots tend to present information in long blocks of text or overly complicated formats. For users with cognitive disabilities, this can be overwhelming and hard to follow.

Time Constraints

Some chatbots automatically close after a period of inactivity, which can disadvantage users who need more time to read or type responses.

Lack of Alternative Communication Options

Chatbots often act as the sole method of contact, leaving users without alternative ways to reach support if they can’t use the chatbot.

How to Build an Accessible Chatbot

Making your chatbot accessible doesn’t have to be daunting. By following WCAG guidelines and implementing these best practices, you can create a more inclusive experience:

Use Semantic HTML for Chatbot Elements

Building an accessible chatbot does not require any specialized experience – you can apply the same general best practices to achieve accessible elements. Use the correct semantic HTML tags for each component you create, such as button or input elements.

Here’s an example of an accessible chatbot button:
```
<button aria-label="Open chatbot" id="chatbot-open-button">  
  Chat with us  
</button>
```
The aria-label ensures that screen readers convey the button’s purpose to users.

Support Keyboard Navigation

Your chatbot should be fully functional with just a keyboard. Test whether users can open, navigate, and interact with the chatbot using the Tab and arrow keys.

For example, ensure focus moves logically through the chatbot interface:
```
document.querySelector('#chatbot-input').focus();  
```
Provide Descriptive ARIA Labels

ARIA (Accessible Rich Internet Applications) roles and attributes can bridge gaps in accessibility, but they must be used carefully. Assign roles like aria-live to update users on dynamic content.
```
<div role="alert" aria-live="polite" id="chatbot-messages">  
  Welcome! How can I assist you today?  
</div>  
```
Using aria-live ensures that screen readers announce new messages in real time.

Design with Simplicity in Mind

Avoid overwhelming users with large blocks of text. Break responses into smaller chunks and provide clear, concise answers.

Allow for Adjustable Timing

Let users control the session duration. If the chatbot times out, allow them to restart the session without losing previous messages.
```
setTimeout(() => {  
  alert('The chatbot session has timed out. Click to resume.');  
}, 300000);   
```
Include Accessible Focus Indicators

Make sure users can see which element is currently focused. Use CSS to style focus indicators:
```
button:focus {  
  outline: 2px solid #005fcc;  
  outline-offset: 2px;  
}  
```
Provide Alternatives to Chatbots

Not everyone can—or wants to—use a chatbot. Always include alternative ways to contact your business, like email or phone.

Testing Chatbot Accessibility

Testing is critical for identifying and fixing accessibility issues. Here are some methods to ensure your chatbot meets accessibility standards:

Manual Testing with Screen Readers

Test the chatbot using screen readers like NVDA or JAWS. Check if labels, navigation, and dynamic updates work as intended.

Keyboard Navigation Tests

Navigate the entire chatbot interface using only a keyboard. Make sure the focus moves logically, and that all interactions are possible.

Automated Tools

Use tools like Lighthouse to identify accessibility issues in your chatbot’s code.

User Feedback

Invite users with disabilities to test the chatbot and provide feedback. Their real-world experiences will highlight areas you may have missed.

Meeting WCAG Standards for Chatbots

The Web Content Accessibility Guidelines (WCAG) provide a roadmap for making chatbots more inclusive. Key criteria to consider include:
- 1.3.1: Info and Relationships
- Ensure that chatbot components are semantically structured and that relationships between elements are apparent.
- 2.1.1: Keyboard Accessibility
- All chatbot functions must be accessible via keyboard.
- 2.4.7: Focus Visible
- Ensure users can see where they are within the chatbot interface.
- 4.1.2: Name, Role, Value
- Use ARIA roles and labels to make interactive elements understandable to assistive technologies.
Wrapping Up

All the functionality on your website is helpful in some way to your users, or else you wouldn’t include it on your site. All functionality on your website should be accessible to everyone, especially chatbots.

Remember to test your chatbot with screen readers, ensure keyboard compatibility, and always provide alternative ways to connect. Inclusive design benefits your business by reaching a broader audience and creating a better user experience for all.

If you’re unsure if your chatbot is accessible to everyone, reach out to 216digital using the contact form below.
Greg McNeil

November 22, 2024

How-to Guides

Accessibility, Chatbots, web developers, web development, Website Accessibility
Skip Links: Improve Web Accessibility & Navigation
More and more, digital accessibility has become a major talking point when browsing the web. One of the key components that improve accessibility for users with disabilities is something many users might not even notice: skip links.

These simple yet powerful tools can make a huge difference in the web experience for individuals relying on keyboard-only interaction, screen readers, or other assistive technologies. In this article, we’ll explore the importance of skip links, their technical mechanics, and how you can implement them effectively on your website.

What Are Skip Links and Why Are They Important?

Skip links are navigational links that allow users to skip over repetitive content such as headers, navigation menus, or other elements they’ve already seen. For users relying on assistive technologies like screen readers, keyboard navigation, or switch devices, skip links enable them to jump directly to the main content of the page.

When navigating a website using a keyboard (by pressing the Tab key), users typically encounter all of the page’s links and elements in a set order. This often means they have to cycle through the same menus, headers, and other repetitive content every time they visit a new page or reload an existing one. Skip links solve this problem by providing an easy way to bypass these elements, saving time and frustration for those who need alternative navigation methods.

For example, imagine you’re using a screen reader to navigate a website. Without skip links, you might be forced to listen to the same navigation menu and header over and over again, even though you’re only trying to get to the main body of the page. Skip links allow you to bypass this content, going straight to the part of the page you want.

The Key Benefits of Skip Links

Improved Navigation for Keyboard-Only Users

Many people with disabilities, including those with limited mobility or dexterity, use keyboards or alternative input devices to navigate the web. Skip links let users quickly navigate to the main content, bypassing headers, footers, and menus that they may have already accessed.

Enhanced Experience for Screen Reader Users

Screen readers announce every element on a webpage in the order they are tabbed through. Without skip links, users would have to hear the same menus and links repeatedly, making navigation time-consuming and tedious. Skip links streamline the experience by providing a shortcut to the main content.

Better Usability for Assistive Technologies

Skip links are a simple yet effective tool that benefits various assistive technologies, enhancing the overall usability of your website for a wide range of users.

Increased Accessibility Compliance

Many countries and regions have laws requiring websites to be accessible. For example, in the United States, the Americans with Disabilities Act (ADA) mandates that websites must be accessible to all users, including those with disabilities. Implementing skip links helps ensure your website is compliant with accessibility guidelines like Web Content Accessibility Guidelines (WCAG).

How Do Skip Links Work?

Skip links work by creating a link that, when activated, allows the user to bypass parts of the webpage and move directly to a more relevant section. These links are typically placed at the top of the page, visible only when the user navigates using the keyboard (by pressing the Tab key). The link itself usually says something like “Skip to main content,” “Skip to navigation,” or “Skip to footer,” depending on which section the user wants to bypass.

The Technical Mechanics of Skip Links

To create a skip link, you use basic HTML along with some helpful attributes to control the behavior and accessibility of the link. Here’s an overview of the technical aspects of skip links:

HTML Structure with <a href> Tags

The primary way to implement skip links is with the <a> (anchor) tag, which creates hyperlinks. These links should point to specific elements within the webpage, often with id attributes to mark the sections users can skip to.

tabindex Attribute

The tabindex attribute is used to control the tab order of elements. By default, links and form controls are included in the tab order. However, for skip links to work properly, they need to be made focusable before other content is tabbed through.

aria-label and aria-hidden Attributes

The aria-label attribute can be used to provide screen readers with a more descriptive label for the skip link. For example, you can use it to define a more readable label like “Skip to main content,” ensuring that screen readers announce the skip link’s purpose clearly. On the other hand, the aria-hidden attribute can be used to hide elements from assistive technologies when needed.

A Simple Skip Link Example

Here’s a simple HTML example of a skip link that allows users to skip directly to the main content of a webpage:
```
<a href="#main-content" class="skip-link" tabindex="0" aria-label="Skip to main content">Skip to main content</a>
<header>
<nav>  </nav>
</header>
<main id="main-content">
<h1>Welcome to Our Website</h1>
<p>This is the main content of the page...</p>
</main>
```
In this example:
- The skip link (<a href="#main-content">) is placed at the top of the page and links to the main-content section identified by the id="main-content".
- The tabindex="0" ensures that the skip link is focusable and can be reached when using the Tab key.
- The aria-label="Skip to main content" helps screen reader users understand what the link does.
Styling Skip Links

While skip links are crucial for accessibility, they’re not always visually appealing by default. To make skip links blend in with your design, you’ll likely want to hide them until they’re needed and style them for better usability. Here’s how you can style skip links using CSS:
```
.skip-link {
position: absolute;
top: -40px; /* Hide the link off-screen */
left: 0;
background-color: #000;
color: #fff;
padding: 10px;
z-index: 100;
}
.skip-link:focus {
top: 10px; /* Bring the link into view when focused */
}
```
In this example:
- The .skip-link class hides the skip link off-screen with top: -40px until it’s needed.
- When the link is focused (i.e., when the user tabs to it), it becomes visible by setting top: 10px.
- You can customize the background color, text color, padding, and positioning to match your website’s design.
JavaScript for Enhanced Skip Link Functionality

In some cases, you may want to enhance the behavior of your skip link using JavaScript. For example, you might want to automatically focus the main content once the skip link is activated. Here’s how you can do that:
```
document.querySelector('.skip-link').addEventListener('click', function(e) {
e.preventDefault();
document.querySelector('#main-content').focus();
});
```
This script listens for a click on the skip link and prevents the default action (i.e., jumping to the href target). Instead, it uses JavaScript to focus on the main content section, making it even easier for users to access.

Testing Skip Links for Accessibility

Once you’ve implemented skip links, it’s essential to test them to ensure they’re working as expected. Here are a few key tips for testing your skip links:
1. Keyboard Navigation: Use the Tab key to cycle through the elements on your page. Ensure the skip link is the first item that can be focused and that it jumps you to the main content.
2. Screen Reader Testing: Test your skip links with a screen reader (such as NVDA or VoiceOver) to ensure the skip links are announced correctly and work as expected.
3. Cross-Browser Compatibility: Make sure your skip links work across different browsers and devices. Some older browsers might have quirks that affect the behavior of tabindex or CSS styling, so testing across multiple platforms is critical.
4. Accessibility Tools: Use automated accessibility tools like Lighthouse to check for accessibility issues on your website. These tools can help identify missing or misused attributes related to skip links.
Challenges with Skip Links

While skip links are an essential tool for accessibility, there are some challenges you might encounter when implementing them:
- Browser Inconsistencies: Different browsers and devices may render skip links or handle focus management differently. It’s important to test across various platforms to ensure consistent behavior.
- Visibility and Styling: Skip links should be visible when needed but unobtrusive when not. Ensuring they are easily accessible but don’t clutter the design can require some careful styling.
- Managing Focus Order: If your page has dynamic content (like modals or sticky headers), you may need to adjust the focus order or ensure that skip links still work as expected when these elements are present.
Skip Ahead to Success

Skip links are a simple but vital tool in improving the accessibility of your website. They help keyboard-only users, screen reader users, and others navigate your site more efficiently by skipping over repetitive content and jumping straight to the main sections of the page. By implementing skip links with proper HTML, CSS, and JavaScript, you can enhance the user experience for a wider audience, making your site more inclusive and accessible.

If you’re ready to make your website ADA-compliant and accessible to everyone, schedule an ADA briefing with 216digital. Our team of experts will walk you through the process, address any questions, and help you create an inclusive, compliant, and user-friendly web experience. Don’t wait—take the first step toward a more accessible digital presence today.
Greg McNeil

November 21, 2024

How-to Guides

Accessibility, How-to, skip link, Web Accessibility, web developers, web development
Should Designers Hit Pause on Animation?
Animation can bring a website to life, but have you ever considered how it impacts all users? While animations and gifs can make a site feel more dynamic, they can also cause some visitors discomfort—or worse—. Let’s explore why animations can be tricky from an accessibility standpoint and how you can design them to be both engaging and inclusive.

Why Animation Can Be Problematic

Animations aren’t just flashy extras—they can deeply affect how users experience your website, and not always in a good way.
- Motion Sensitivity: Some people have vestibular disorders that make them sensitive to movement on screens. Animations like parallax scrolling or sliding elements can trigger dizziness, vertigo, or nausea.
- Seizures: Flashing lights or strobing effects can be dangerous for users with photosensitive epilepsy. Even subtle flickers can cause issues.
- Cognitive Overload: Busy or overly complex animations can overwhelm users with cognitive impairments, making it hard for them to focus or understand the content.
- Assistive Technology Interference: Screen readers and other tools can struggle with animations that change content dynamically, leading to confusion.
These challenges highlight why designers need to think critically about when and how they use animations.

Does Your Design Really Need Animation?

Not every project calls for animation. Before you add that fancy effect, ask yourself:
- Does it serve a purpose?
- Will it help users navigate or understand the site?
- Could it distract or overwhelm someone?
Animations should always have a clear function, like drawing attention to a call-to-action or giving feedback on an interaction. If the animation doesn’t improve usability, it might be best to skip it.

Making Animations Accessible

If you must use an animation, here are some tips to ensure it doesn’t cause issues for people with cognitive or visual impairments:
1. Keep It Simple: Avoid overly elaborate or decorative effects. Subtle transitions or fades can be just as effective without being overwhelming.
2. Mind the Timing: Speed matters. Too fast, and users might get lost; too slow, and they could grow impatient. Aim for a balance that feels natural.
3. Give Users Control: All animations should have visual and accessible controls to pause and play the animation. Always respect the prefers-reduced-motion media query.
4. Focus on Purpose: Every animation should add value. Whether it’s guiding users or making content clearer, make sure it serves a meaningful purpose.
A Quick Fix with prefers-reduced-motion

One of the easiest ways to address motion sensitivity is by using the prefers-reduced-motion media query. This CSS feature checks if a user has reduced motion enabled on their device and adjusts animations accordingly.

Here’s how you can tone down animations for users who prefer less motion:
```
@media (prefers-reduced-motion: reduce) {  
  .animated-element {  
    animation: none;  
    transition: none;  
  }  
}  
```
Want to simplify rather than completely disable? Try this:
```
@media (prefers-reduced-motion: reduce) {  
  .fade-in {  
    animation: fade-in 0.5s linear;  
  }  
}  
@keyframes fade-in {  
  from { opacity: 0; }  
  to { opacity: 1; }  
}  
```
This approach keeps your design functional while reducing the risk of discomfort for sensitive users.

What Does WCAG Say About Animation?

The Web Content Accessibility Guidelines (WCAG) offer clear rules about animations. Two of the most relevant criteria are:
- 2.3.1: Three Flashes or Below Threshold
- Avoid animations that flash more than three times per second. It’s a crucial step in reducing the risk of seizures.
- 2.3.3: Animation from Interactions
- If animations are triggered by user actions, make sure they can be disabled without affecting functionality.
Following these guidelines helps ensure your site is usable for everyone.

Testing Your Animations

Testing is an essential part of designing accessible animations. Here’s how to do it effectively:
- Check Motion Settings: Turn on the “reduce motion” setting on your device (available on macOS, Windows, iOS, and Android) and see how your site responds.
- Try Keyboard Navigation: Ensure animations don’t interfere with keyboard functionality. Can users still tab through links and buttons smoothly?
- Use Automated Tools: Tools like Lighthouse can catch accessibility issues related to animations.
- Gather Feedback: Get input from real users, especially those with disabilities. They’ll provide insights you might not have considered.
Accessible Animation with JavaScript

Sometimes, you’ll need JavaScript to handle animations. You can still make them accessible by pairing JavaScript with prefers-reduced-motion.

Here’s a quick example:
```
const reduceMotion = window.matchMedia('(prefers-reduced-motion: reduce)');  
if (reduceMotion.matches) {  
  // Turn off animations for users who prefer reduced motion  
  document.querySelector('.animated-element').style.animation = 'none';  
} else {  
  // Keep animations for everyone else  
  document.querySelector('.animated-element').classList.add('run-animation');  
}   
```
This snippet ensures your animations adapt to user preferences without requiring manual toggles.

Wrapping It Up

Animations can be a powerful tool for creating engaging, interactive websites—but they should never come at the expense of accessibility. By keeping animations simple, purposeful, and user-controlled, you can deliver a better experience for all your visitors.

Don’t forget to test your designs with real users and tools, and make use of features like prefers-reduced-motion to accommodate different needs. Thoughtful design is inclusive design, and accessible animations are a small change that can make a big difference. If you’re unsure if the animations on your website are accessible or would like an expert partner to help you get started, reach out to 216digital using the contact form below.
Bobby

November 14, 2024

How-to Guides

Accessibility, animation, How-to, web developers, web development, Website Accessibility
Understanding Focus Outlines for Web Accessibility
Have you ever tried navigating a website without a mouse, relying only on your keyboard? It might seem unusual, but for many people with motor disabilities or visual impairments, this is their everyday reality. Focus outlines—the visual markers that highlight where you are on a page—are essential tools that make this possible.

Unfortunately, these outlines often get overlooked or even removed during web design, leaving a significant number of users struggling to navigate sites effectively. Let’s break down what focus outlines are, why they matter, and how you can implement them to make your website more inclusive.

What Is a Focus Outline?

A focus outline is a visual indicator, often a highlighted border or underline, that appears around a web element when it gains keyboard focus. This outline helps users understand which interactive element they are currently on, whether it’s a link, button, form field, or other focusable component. For example, when a user tabs through a webpage, the focus outline moves from one element to the next, providing a visual cue about their current location on the page.

This feedback is essential for users who cannot use a mouse and instead navigate by pressing the “Tab” key to move forward and “Shift + Tab” to move backward. For those relying on screen readers, focus outlines further aid in understanding the structure of a page, confirming the position on the screen, and reducing the cognitive load required to navigate the web effectively.

Why Focus Outlines Matter for Accessibility

Focus outlines aren’t just nice to have—they’re a must-have for accessibility. According to the Web Content Accessibility Guidelines (WCAG), specifically criterion 2.4.7: Focus Visible, mandate that any keyboard-operable interface must have a visible focus indicator. This ensures that users relying on keyboard navigation always know where they are on the page.

Who Benefits from Focus Outlines?

For users with motor disabilities, such as those who have difficulty controlling fine motor movements or are unable to use a mouse, keyboard navigation is a primary means of interacting with digital content. The focus outline serves as a reliable marker of where they are on the page, making navigation smooth and efficient. People with low vision or visual impairments who use high-contrast settings also rely on focus outlines for an additional layer of navigation support, enabling them to visually follow along.

Legal and Ethical Responsibilities

Beyond enhancing the user experience, implementing visible focus outlines is a legal and ethical responsibility for organizations. Without them, websites may fail to meet accessibility standards, putting them at risk of non-compliance with the WCAG guidelines. For organizations, following WCAG isn’t just about adhering to regulations; it’s about creating an inclusive experience that all users can navigate.

How to Create Accessible Focus Outlines

Making focus outlines accessible and noticeable is all about ensuring they stand out. Here are some tips:
- Use Sufficient Color Contrast: Choose colors that contrast well with both the element and the background.
- Choose a Noticeable Style: Solid, dotted, or dashed lines can all work, as long as they’re easily visible.
- Adjust Thickness: A thicker outline can be more eye-catching and easier to see.
How to Style Focus States Using CSS

Outlines can be solid, dotted, or dashed lines, as long as they are visible. Adjusting the thickness can also make the outline more noticeable.

Example: Basic Focus Outline with CSS
```
button:focus,
a:focus {
  outline: 3px solid #007acc;
}
```
In this example, we’ve applied a 3-pixel solid blue outline to buttons and links when they’re focused. Before finalizing colors, use tools like the WebAIM Contrast Checker to ensure they meet the recommended contrast ratio of at least 3:1 for user interface components.

Add Background Effects

For a more custom look, consider adding a background color or shadow effect:
```
button:focus {
  outline: none;
  box-shadow: 0 0 5px 2px rgba(0, 122, 204, 0.8);
}
```
This replaces the default outline with a subtle glow, making the focused element stand out without clashing with your design. Just remember to test these styles to ensure they’re visible to everyone, including users with visual impairments.

Avoiding Common Mistakes with Focus Outlines

One of the most common pitfalls in web design is removing focus outlines entirely. Designers sometimes find default focus outlines unattractive and may remove them without providing a suitable replacement. While this might make the site look cleaner, it creates significant accessibility barriers for users relying on keyboard navigation. WCAG guideline 2.4.7 requires focus indicators for compliance, so removing focus outlines can result in a failure to meet accessibility standards.

If you’re tempted to hide the default outline, remember that it’s better to customize it than to remove it. Replacing the outline with a custom design can enhance the aesthetics of your website without sacrificing accessibility. Just ensure that your custom design maintains a strong visual presence and sufficient color contrast.

Another common mistake is creating focus outlines that blend too closely with the background. This can happen when designers use colors that don’t contrast well with surrounding elements or backgrounds. Remember, users with low vision may struggle to differentiate between similar shades, so it’s essential to test the visibility of focus outlines across various screens and devices.

Testing Focus Visibility

Testing is a crucial step to ensure your focus outlines are effective:
1. Navigate Your Site Using Only the Keyboard: Press the “Tab” key to move through interactive elements and observe the focus outline.
2. Check Every Interactive Element: Ensure that links, buttons, form fields, and other focusable components have a visible focus state.
3. Assess Visibility and Consistency: The focus outline should be easily noticeable and consistent across your site.
4. Accessibility Tools: Tools like Google Lighthouse or WAVE can check WCAG compliance, including focus outlines.
Make Focus Outlines a Priority

Focus outlines aren’t just a design detail—they’re a vital part of creating an inclusive web experience. By ensuring your site has clear and consistent focus indicators, you can make your website more accessible for everyone. So, take action today to ensure your website is accessible. Your customers—and your bottom line—will thank you!

For personalized guidance on making your website ADA compliant, reach out to 216digital for an ADA briefing. Our experts are here to help you navigate the complexities of web accessibility and secure your business against potential legal risks.
Kayla Laganiere

November 13, 2024

How-to Guides

Accessibility, focus outlines, How-to, web developers, web development, Website Accessibility
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

Why Accessibility in Emails Matters

The Business Case for Accessible Emails

Why Marketing Emails Tend To Be Inaccessible

Building an Accessibility Checklist for Emails

Template Setup (One-Time Fixes)

Campaign-Level Fixes

Testing and QA for Your Accessible Emails

Manual Testing

Automated Testing Tools

A/B Testing

Accessibility Best Practices for Email Design

Encouraging a Culture of Accessibility

Conclusion

The Problem with display: none

The Clip Pattern: A Better Approach

Why the Clip Pattern Works

Managing Visibility with aria-hidden and the hidden Attribute

aria-hidden="true"

HTML5 hidden Attribute

Best Practices for Accessible, Visually-Hidden Content

1. Use Semantic HTML

2. Avoid Hiding Focusable Elements

3. Provide Context for Hidden Content

4. Test with Multiple Assistive Technologies

Handling Localization

Putting It All Together: A Quick Example

Additional Resources

Conclusion

Developers: Building the Accessible Foundation

Practical Tips for Developers

Semantic HTML and Proper Structure

ARIA Attributes

Robust Error Handling

Graphic Designers: Creating Inclusive Visuals

Practical Tips for Graphic Designers

Color Contrast

Scalable Designs

Accessible Icons and Imagery

Consistent Design Patterns

Content Creators: Writing for All Audiences

Practical Tips for Content Creators

Plain Language

Heading Hierarchies and Lists

Descriptive Links

Closed Captions and Transcripts

Marketers: Promoting Accessibility as a Brand Value

Practical Tips for Marketers

Inclusive Messaging

Transparent Policies

Social Media and Email Marketing

Continuous Feedback

Website Owners: Setting the Vision and Investing in Ongoing Compliance

Practical Tips for Website Owners

Leadership and Accountability

Budget for Accessibility

Regular Audits and Updates

Team Training

Collaboration and Continuous Improvement

Understanding the Basics of Accessible Tables

Adding Headers, Captions, and Summaries

Ensuring Compatibility with Screen Readers

Making Tables Keyboard-Friendly

Simplifying Complex Tables

Improving Readability with Responsive Design and Contrast

Testing Your Tables for Accessibility

Why Accessible Tables Matter

Conclusion

Why Chatbot Accessibility Matters

Common Barriers in AI Chatbots

Incompatible with Screen Readers

Keyboard Navigation Failures

Unclear or Missing Focus Indicators

Overly Complex or Jumbled Responses

Time Constraints

Lack of Alternative Communication Options

How to Build an Accessible Chatbot

Use Semantic HTML for Chatbot Elements

Support Keyboard Navigation

Provide Descriptive ARIA Labels

Design with Simplicity in Mind

The Problem with `display: none`

Managing Visibility with `aria-hidden` and the `hidden` Attribute

`aria-hidden="true"`

HTML Structure with `<a href>` Tags

`tabindex` Attribute

`aria-lab`el and `aria-hidde`n Attributes