web developers Archives - Page 3 of 4/Tag

Accessibility Barriers: The Problem with Placeholders

Form design might seem simple at first. You add text fields, maybe a dropdown or two, and call it a day. But when it comes to guiding users, many designers rely on placeholders to show instructions or examples inside the input fields. On the surface, this seems like a neat way to save space and keep the layout clean. However, those same placeholders can create big usability and accessibility issues.

If you’ve been counting on placeholders to label your form fields, it might be time to rethink your approach. In this article, we’ll explore why placeholders cause problems, especially for people with disabilities, and how you can design forms that are clearer and easier for everyone to use.

Why Placeholders Cause Problems in Forms

1. They Disappear When Users Start Typing

Picture this: a user clicks on a field that says “Enter your phone number,” the moment they begin typing, that instruction vanishes. If they suddenly forget the exact format or details required, they have to either clear the field to see the placeholder again or guess what was there in the first place. This can be annoying in simple fields, but it becomes a real headache in longer or more complex forms. Each additional step or moment of confusion can lead to higher drop-off rates and reduced accuracy.

2. Not All Browsers Support Them

Although modern browsers generally display placeholders, some older or less common browsers may not. When these browsers skip placeholders altogether, the user has zero guidance or instruction for the field. If your form is already barebones—meaning you’ve omitted labels or separate hint text—people on unsupported browsers are left to figure it out on their own. This can be especially problematic when international or low-tech audiences may rely on older systems.

3. Once Filled, Fields Lose Context

After a user inputs data into a field, the purpose of that field may not be obvious. This is especially true for details like phone numbers, ZIP codes, or other specialized information. Without visible labels, users who step away from their screens or return later might forget the exact context for each field and whether it requires a specific format (e.g., whether to include country codes or parentheses for phone numbers).

4. Reviewing Answers Becomes a Hassle

Many people like to review their answers before hitting the Submit button. However, if placeholder text disappears once the user types something in, they can’t quickly verify whether their entry meets the field’s requirements. This can lead to overlooked mistakes—like mixing up month and day in date fields or forgetting to include a state abbreviation in an address.

5. Fixing Errors Gets Confusing

When a form returns an error message, it often refers to a specific label or hint. Without a visible label, a user might only see a generic error message like “Invalid entry” without knowing how to fix it. They’re left guessing whether they must add a certain number of characters, switch from text to numbers, or follow a specific pattern. This guesswork can be frustrating and lead to abandoned forms.

6. Some Browsers Hide Placeholders When the Field Is Focused

In certain older browsers, clicking or tabbing into an input field removes the placeholder immediately. Suppose a user didn’t fully absorb the instructions beforehand. In that case, they’ll have to navigate out of the field and back in, or potentially delete any typed text, to see the placeholder again. It’s a minor issue but yet another piece of friction.

7. They Can Be Mistaken for an Actual Answer

Placeholder text usually has a lighter contrast to differentiate it from actual user input, but the difference can be subtle. Some users might assume the placeholder is pre-filled data and skip the field altogether. Or they might try to erase the text, only to realize it’s a placeholder, not a typed entry.

8. Low Contrast Makes Them Hard to Read

One frequent design choice is to make placeholders light gray. This aesthetic might look sleek but can be challenging to read for people with visual impairments or even those using a device in bright sunlight. Low contrast is a direct accessibility barrier and may violate the Web Content Accessibility Guidelines (WCAG) guidelines, which recommend sufficient contrast between text and background.

9. Some Screen Readers Don’t Read Placeholder Text

Screen reader support for placeholders is inconsistent. Some devices or assistive tools ignore placeholders entirely, leaving users no context. If you rely on placeholders to communicate critical instructions, this group of users may miss out on the information they need.

10. Smaller Clickable Area Without Labels

When you have a label element associated with a form field, clicking the label sets focus on that field. This feature is handy, especially for people with motor impairments who benefit from a larger clickable target. Without a proper label, users might have to click precisely on the field, which can be more complicated.

11. Placeholder Text Gets Cut Off

Long placeholder text often doesn’t fit in the space provided, so it gets truncated. If the most crucial part of the instruction is at the end—like a date format or suffix—it may not be visible. Mobile users, in particular, have limited screen space, making it even more likely that critical instructions get chopped.

12. Some Browsers Don’t Translate Placeholders

If you depend on browser-based translation (like Google Translate in Chrome), remember that these tools don’t always translate placeholder text. International users might see fields with instructions in a language they don’t understand, putting them at a disadvantage.

13. Auto-Complete Can Mess Things Up

Browsers often auto-fill fields such as name or email based on saved user information. When that happens, the placeholder text is never shown. If the user doesn’t recall the exact format needed—like whether the phone number should include a dash or parentheses—they might submit the wrong thing without even realizing it.

14. High Contrast Mode Makes Placeholders Look Like User Input

High Contrast Mode in Windows can shift placeholder text to the same color as regular text. In that situation, a placeholder might appear identical to actual input, confusing users who think the field is already filled in or assume it’s a default value.

What You Should Do Instead

Rather than relying on placeholders, consider these best practices:

Use a Visible Label

Make sure every form field has a label that stays on the screen. Labels tell users—sighted, low vision, or blind—what the field is for. They also help screen reader users navigate more easily.

Put Hint Text Below the Label

If you need to offer more guidance, place this text below or next to the label. This way, the hint stays visible all the time. It won’t disappear once someone starts typing.

Provide Clear Formatting Instructions

Instead of relying on placeholders, add clear examples outside the input field. For instance, you could show “MM/DD/YYYY” under the “Date of Birth” label. Users can see the format without losing the prompt.

Test for Accessibility

Test your forms with screen readers and try them in high-contrast mode. Check that the labels are clear, that hint text stands out, and that the form works well even if placeholders don’t show up at all. Tools like WAVE or Google Lighthouse can help identify accessibility barriers.

Consider Better UX Patterns

Inline validation, tooltips, or progressive disclosure can guide users in a more reliable way. These methods let users see error messages or instructions at just the right time, without losing any important label text.

Clear Forms, Better Experiences

Using placeholders might seem like a clean and modern design choice, but it often causes more trouble than it’s worth. From disappearing instructions to accessibility issues, placeholders can leave users frustrated and unsure. Instead of relying on placeholders, give each field a clear label and keep helpful guidance visible. By doing so, you’ll create a smoother, more inclusive experience for everyone who visits your site.

Need help making sure your forms are user-friendly and accessible? 216digital specializes in improving digital experiences for all users. Reach out to us today to learn how we can help you design better, more inclusive forms—no placeholders needed.

Greg McNeil

February 6, 2025

How-to Guides

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

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

What Is ARIA (and Why Does It Matter)?

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

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

Why Semantic HTML Should Be Your First Choice

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

What is Semantic HTML?

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

Why Does it Matter?

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

Real-world Example

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

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

When (and Why) ARIA Is Actually Needed

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

Filling the Gaps

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

Roles, States, and Properties

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

Example: Tabs and sliders

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

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

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

Misusing Roles

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

Example
```

<div role="button" tabindex="0" onclick="doSomething()">
  Click me
</div>


<button onclick="doSomething()">Click me</button>
```
Using a <button> means you get keyboard focus, click events, and screen reader recognition by default—no extra ARIA or scripting needed.

Redundant or Conflicting Roles

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

Example
```

<nav role="navigation">
  
</nav>


<nav>
  
</nav>
```
Here, adding role= "navigation" is unnecessary and could create confusion in some tools.

Incorrect State Management

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

Example
```

<button aria-expanded="true" onclick="toggleMenu()">Menu</button>


<button aria-expanded="false" onclick="toggleMenu()">Menu</button>
```
Make sure your script updates aria-expanded to reflect the actual state of the menu (true when open, false when closed).

ARIA Overload

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

Example
```

<div aria-live="polite">Update 1</div>
<div aria-live="polite">Update 2</div>
<div aria-live="polite">Update 3</div>


<div aria-live="polite" id="importantUpdates"></div>
```
If you really need to announce multiple updates, try grouping them or letting users opt-in.

Misusing aria-hidden

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

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

Example
```

<button aria-hidden="true" onclick="doSomething()">Buy Now</button>


<button class="visually-hidden" onclick="doSomething()">Buy Now</button>
```
(“Visually hidden” classes typically hide elements from sighted users but keep them available to assistive tech.)

Why “No ARIA” is Often the Best Choice

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

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

Best Practices for Using ARIA the Right Way

Use Native HTML First

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

Example

Instead of:

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

Use:

<button>Submit</button>

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

Be Precise with Roles and States

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

Example
```
<button aria-expanded="false" aria-controls="menu" onclick="toggleMenu()">Menu</button>
<ul id= "menu" hidden>
  <li>Home</li>
  <li>Services</li>
  <li>Contact</li>
</ul>
```
In this example, setting aria-expanded= "false" on the button shows it’s not expanded. When the user clicks, you can switch that to true in your JavaScript.

Don’t Add ARIA Where It’s Not Needed

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

Example
```

<ul role="list">
  <li>Item 1</li>
  <li>Item 2</li>
</ul>


<ul>
  <li>Item 1</li>
  <li>Item 2</li>
</ul>
```
A <ul> is already recognized as a list by assistive technology.

Test with Real Assistive Tech

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

Conclusion

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

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

Need Help with Web Accessibility?

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

February 4, 2025

How-to Guides

Accessibility, ARIA, How-to, WCAG, Web Accessibility, web developers, web development
Web Accessibility: Making Drop-Down Menus User-Friendly
Drop-down menus are a staple in website navigation, offering a compact way to organize and access multiple links. But while they streamline user experience, they can also create significant barriers if not designed with accessibility in mind. For users who rely on screen readers, keyboard navigation, or other assistive technologies, a poorly implemented menu can turn a simple browsing experience into a frustrating ordeal.

This article will guide website owners, developers, and content creators on how to create accessible drop-down menus that enhance usability for all users. We’ll cover foundational accessibility principles, best coding practices, and testing methods to ensure your menus are inclusive and user-friendly.

Foundational Accessibility Principles for Drop-Down Menus

To build accessible drop-down menus, start by understanding core web accessibility principles. Here are the three most critical aspects:

1. Use Semantic HTML

Semantic HTML ensures that content is meaningful and properly interpreted by assistive technologies. Instead of using <div> or <span> elements for interactive components, use appropriate HTML elements like:
- <nav> for navigation sections
- <ul> and <li> for menu structures
- <button> to toggle drop-down visibility
For example:
```
<nav>
  <button aria-haspopup="true" aria-expanded="false" id="menuButton">Menu</button>
  <ul id="menu" hidden>
    <li><a href="#">Home</a></li>
    <li><a href="#">About</a></li>
    <li><a href="#">Services</a></li>
    <li><a href="#">Contact</a></li>
  </ul>
</nav>
```
2. Ensure Keyboard Navigation

Users who navigate via keyboard should be able to open, close, and move through the menu using the Tab and arrow keys. Ensure the following behaviors:
- The menu should open with Enter or Space when focused on the toggle button.
- The Esc key should close the menu.
- Arrow keys should allow navigation within the menu items.
3. Use ARIA Roles and Attributes Wisely

ARIA (Accessible Rich Internet Applications) attributes help convey additional information to screen readers. However, improper use can create confusion. Apply ARIA roles correctly:
- aria-haspopup="true" indicates that a button controls a drop-down menu.
- aria-expanded="false" updates dynamically when the menu is opened or closed.
- role="menu" and role="menuitem" clarify the structure.
Example implementation:
```
<button aria-haspopup="true" aria-expanded="false" id="menuButton">Menu</button>
<ul id="menu" role="menu" hidden>
  <li role="menuitem"><a href="#">Home</a></li>
  <li role="menuitem"><a href="#">About</a></li>
  <li role="menuitem"><a href="#">Services</a></li>
</ul>
```
Structuring Accessible Drop-Down Menus

Now that we’ve covered the principles, let’s implement an accessible drop-down menu using HTML, CSS, and JavaScript.

1. Toggling Visibility

A menu should only be visible when needed. Use JavaScript to control visibility:
```
const menuButton = document.getElementById('menuButton');
const menu = document.getElementById('menu');
menuButton.addEventListener('click', () => {
  const expanded = menuButton.getAttribute('aria-expanded') === 'true';
  menuButton.setAttribute('aria-expanded', !expanded);
  menu.hidden = expanded;
});
```
2. Managing Focus for Keyboard Users

When a menu opens, focus should shift inside it. When it closes, focus should return to the toggle button:
```
toggle button:
menuButton.addEventListener('click', () => {
  menu.hidden = !menu.hidden;
  menu.hidden ? menuButton.focus() : menu.querySelector('a').focus();
});
```
3. Enabling Smooth Keyboard Interactions

To navigate the menu with arrow keys, use this approach:
```
menu.addEventListener('keydown', (event) => {
  const items = [...menu.querySelectorAll('a')];
  let index = items.indexOf(document.activeElement);
  
  if (event.key === 'ArrowDown') {
    event.preventDefault();
    index = (index + 1) % items.length;
    items[index].focus();
  } else if (event.key === 'ArrowUp') {
    event.preventDefault();
    index = (index - 1 + items.length) % items.length;
    items[index].focus();
  } else if (event.key === 'Escape') {
    menu.hidden = true;
    menuButton.focus();
  }
});
```
Testing Your Drop-Down Menus for Accessibility

1. Screen Reader Testing

Use a screen reader like NVDA (Windows), VoiceOver (Mac), or JAWS to ensure:
- Menus are announced properly.
- aria-expanded updates correctly.
- Navigation follows expected patterns.
2. Keyboard Testing

Try navigating your menu using only the keyboard. Ensure:
- Tab reaches the menu.
- Enter or Space opens the menu.
- Arrow keys move between items.
- Esc closes the menu.
3. Contrast and Readability

Ensure proper color contrast between text and background. Use tools like the WebAIM Contrast Checker to verify compliance with WCAG 2.1 standards.

Best Practices for Creating Intuitive Menus
- Keep It Simple: Avoid deep nesting that makes menus cumbersome.
- Ensure Mobile Friendliness: Use larger touch targets for better usability.
- Avoid Hover-Only Menus: They exclude keyboard users and some assistive technology users.
- Provide Visual Indicators: Show clear changes when menus expand or collapse.
Conclusion

By using semantic HTML, managing focus properly, implementing ARIA roles correctly, and rigorously testing your menus, you can ensure they work for all users, regardless of ability.

Accessible drop-down menus not only improve usability but also make your site more welcoming to all visitors. Implement these best practices today and make your navigation barrier-free!

If you’re ready to take the next step toward digital inclusion, reach out to 216digital to schedule an ADA briefing. We’ll help you assess your website, develop a tailored plan, and guide you through the process of building an online presence that works for everyone. Don’t wait—contact us today and let’s make the internet a more accessible place together.
Greg McNeil

January 24, 2025

How-to Guides

Accessibility, drop-down menus, How-to, WCAG, Web Accessibility, web developers, web development
Accessibility in JavaScript: A Developer’s Guide
JavaScript has revolutionized web development, enabling developers to create interactive and dynamic websites. However, these enhancements can also introduce significant accessibility barriers if not implemented thoughtfully. For web developers and eCommerce managers, ensuring that JavaScript-powered features are accessible isn’t just about compliance—it’s about creating an inclusive experience for all users.

This guide explores the essential techniques, testing methods, and best practices to ensure that JavaScript features meet accessibility standards and improve usability for everyone.

Why Accessibility in JavaScript Matters

Interactive JavaScript elements, such as modals, dropdown menus, and dynamic content updates, can be challenging for users with disabilities. Poorly implemented JavaScript can break keyboard navigation, confuse screen readers, or cause focus management issues, creating barriers that exclude a portion of your audience.

By prioritizing accessibility, developers can:
- Meet Web Content Accessibility Guidelines (WCAG).
- Improve user experience for everyone, including users with disabilities.
- Reduce the risk of legal action related to accessibility non-compliance.
- Expand your website’s audience and customer base.
Common Accessibility Barriers in JavaScript

Before diving into solutions, let’s examine some common accessibility pitfalls associated with JavaScript:
1. Keyboard Inaccessibility: Many JavaScript features rely on mouse interactions, neglecting users who navigate with a keyboard.
2. Focus Management Issues: Improper handling of focus can disorient users, especially when triggering modals, popups, or dynamic content.
3. Unlabeled ARIA Roles: Dynamic elements without proper ARIA roles and attributes can confuse screen readers.
4. Non-Compliant Custom Widgets: Custom components like sliders, tabs, or accordions often fail to replicate the functionality of their native HTML counterparts.
5. Content Updates Without Notifications: Dynamic content changes that are not announced to assistive technologies leave users unaware of critical updates.
Best Practices for Accessible JavaScript

To make your JavaScript-powered features inclusive, follow these best practices:

1. Ensure Keyboard Accessibility

All interactive elements must be operable using only a keyboard. Consider the following:
- Use semantic HTML elements like <button>, <a>, and <input>, which have built-in keyboard support.
- Add tabindex= "0" to custom elements to make them focusable.
- Avoid tabindex values greater than 0, which can disrupt the natural tabbing order.
- Implement custom keyboard interactions for widgets like dropdowns and modals. For example, allow users to close a modal with the Escape key.
2. Manage Focus Properly

Focus management is critical when working with dynamic content. Here’s how to handle it:
- Set Initial Focus: When opening a modal, move focus to the first interactive element within it.
- Trap Focus: Prevent users from tabbing out of an open modal.
- Restore Focus: Return focus to the triggering element when the modal is closed.
- Avoid Focus Loss: Ensure that dynamically added content doesn’t cause focus to disappear.
3. Use ARIA Responsibly

Accessible Rich Internet Applications (ARIA) can enhance screen reader compatibility, but misuse can lead to confusion. Follow these guidelines:
- Use ARIA Roles: Assign roles like role= "dialog" for modals or role= "menu" for dropdowns.
- Add ARIA States: Use attributes like aria-expanded, aria-hidden, and aria-live to convey element states to assistive technologies.
- Don’t Overuse ARIA: Avoid using ARIA when semantic HTML can achieve the same result.
4. Announce Dynamic Content Updates

For screen reader users, dynamically updated content must be announced clearly:
- Use aria-live regions to alert users to changes in content.
- Set the aria-live attribute to “polite” for non-urgent updates or “assertive” for critical changes.
- Avoid excessive announcements, which can overwhelm users.
5. Test Custom Widgets Thoroughly

If you create custom widgets, ensure they mimic the behavior of native elements:
- Use the WAI-ARIA Authoring Practices Guide as a reference.
- Make widgets focusable, operable via keyboard, and compatible with screen readers.
- Test with multiple assistive technologies and devices to ensure broad accessibility.
Testing JavaScript for Accessibility

Accessibility testing is an essential part of development. Use the following tools and methods to identify and address accessibility issues:

Automated Tools
1. Lighthouse (built into Chrome DevTools): Provides a quick audit of accessibility issues.
2. WAVE: Highlights accessibility problems directly on your webpage.
Manual Testing

Automated tools can’t catch every issue, so manual testing is critical:
- Keyboard Navigation: Ensure all interactive elements are focusable and operable with the Tab and Enter keys.
- Screen Readers: Test your website with screen readers like NVDA, JAWS, or VoiceOver.
- Focus Indicators: Verify that focus indicators are visible and intuitive.
Real-World Scenarios

Test your website with users who rely on assistive technologies. User feedback can uncover issues that developers might overlook.

Meeting WCAG Requirements

To comply with WCAG, focus on these key guidelines:

Perceivable
- Ensure text alternatives for images and icons.
- Provide captions for video content.
Operable
- Make all functionality available via a keyboard.
- Avoid content that flashes more than three times per second.
Understandable
- Use clear labels and instructions.
- Ensure consistent navigation and predictable interactions.
Robust
- Use valid HTML and ARIA attributes to ensure compatibility with assistive technologies.
Benefits of Accessible JavaScript

Implementing accessible JavaScript goes beyond compliance. It delivers tangible benefits, such as:
- Improved User Experience: Accessible features make your website easier to use for everyone.
- Increased Market Reach: Approximately 16% of the world’s population lives with some form of disability. Accessibility ensures they can engage with your website.
- Better SEO: Many accessibility improvements, like proper headings and alt text, also enhance search engine rankings.
- Legal Compliance: Meeting accessibility standards helps protect your business from lawsuits and reputational damage.
Conclusion

It is far easier to create accessible JavaScript from the onset rather than trying to fix it as an afterthought if you are armed with the proper knowledge.

Stay informed about evolving standards like WCAG and remain proactive in integrating accessibility into your development workflow. If you’re unsure if your JavaScript is accessible or are looking for an implementation partner who is focused on accessibility, reach out to 216digital using the contact form below.
Greg McNeil

January 17, 2025

How-to Guides

Accessibility, How-to, JavaScript, Web Accessibility, web developers, Website Accessibility
Writing Code for Web Accessibility: A Guide for Developers
Coding often feels like speaking a secret language—it’s complex, intricate, and incredibly rewarding. Including web accessibility in your workflow isn’t about reinventing the wheel; it’s about refining your craft to ensure your work reaches everyone. Accessible code builds on the practices you already know, with small adjustments that make a significant impact. In this guide, we’ll explore actionable steps to help you create accessible, user-friendly websites that leave no user behind.

What Is Accessible Code?

Accessible code ensures everyone can interact with your website, regardless of ability. Following standards like the Web Content Accessibility Guidelines (WCAG) helps create an inclusive space for all users. By integrating accessibility, you’re not just meeting legal requirements but building a better, more welcoming web experience.

Accessibility encompasses several aspects, including:
- Visual Accessibility: Making visual content perceivable by users with visual impairments, often through tools like screen readers.
- Interactive Usability: Ensuring interactive elements work seamlessly with keyboards, touchscreens, or voice commands.
- Content Clarity: Structuring information logically to assist users with cognitive impairments.
- Compatibility: Writing robust code that works with assistive technologies and adapts to future updates.
The Four Golden Rules of Accessibility: POUR

The foundation of accessible code is rooted in WCAG’s four guiding principles: Perceivable, Operable, Understandable, and Robust (POUR). These principles ensure your website is usable for everyone. Let’s break them down:
- Perceivable: Users must be able to see or hear content.
  - Provide text alternatives for non-text content like images (e.g., alt text).
  - Use captions and transcripts for multimedia content.
- Operable: Interactive elements must be usable with any input device.
  - Ensure keyboard navigation works for all features.
  - Include features like skip-to-content links to improve navigation.
- Understandable: Content and interfaces should be easy to comprehend.
  - Label forms clearly and provide concise instructions.
  - Write meaningful error messages that guide users in resolving issues.
- Robust: Code should be compatible with a wide range of assistive technologies.
  - Use valid, semantic HTML to ensure content is interpretable.
  - Test compatibility with assistive technologies like screen readers.
Adhering to these principles ensures compliance with accessibility standards while enhancing usability for everyone.

Best Practices for Writing Accessible Code

Here’s how to apply accessibility principles to your code:

1. Use Semantic HTML

Semantic HTML provides structure and meaning to your content. Elements like <header>, <nav>, <main>, and <footer> improve navigation for screen readers and other assistive technologies.

Instead of:
```
<div onclick="doSomething()">Click me</div>
```
Use:
```
<button onclick="doSomething()">Click me</button>
```
Semantic tags enhance usability and reduce the need for ARIA roles, ensuring better compatibility.

2. Make Forms Accessible

Forms are a common source of frustration for users with disabilities. Pair input fields with <label> tags to provide clear context:
```
<label for="email">Email:</label>
<input type="email" id="email" name="email">
```
For added guidance, use aria-describedby for hints:
```
<p id= "emailHint"> We'll never share your email.</p>
<input type="email" id="email" aria-describedby="emailHint">
```
Additionally:
- Group related fields with <fieldset> and <legend>.
- Include real-time error validation with accessible alerts.
3. Ensure Keyboard Navigation

Interactive elements should be operable using a keyboard. Use logical HTML structures and the tabindex attribute sparingly to create a natural focus order.

Example:
```
<button tabindex="0">Focus me</button>
```
Avoid negative tabindex values unless necessary, as they can disrupt navigation.

4. Add Alt Text to Images

Alt text makes images accessible to screen readers. Describe the content succinctly:
```
<img src= "puppy.jpg" alt= "A golden retriever puppy playing with a ball">
```
If an image is decorative, use an empty alt attribute (alt= "") to skip it for screen readers.

5. Mind Your Colors

Color contrast impacts readability. Use tools like Contrast Checker to verify that text is legible. Avoid using color as the sole means of conveying information. For example:
```
<span style="color: red;">Required field</span>
```
Should also include:
```
<span class="required" aria-label="Required field">*</span>
```
6. Use ARIA Wisely

Accessible Rich Internet Applications (ARIA) roles can enhance functionality but should be used sparingly. Stick to semantic HTML whenever possible. Common ARIA roles include:
- role= "alert" for dynamic notifications.
- aria-expanded for collapsible menus.
- aria-live for real-time updates.
7. Don’t Forget Multimedia

Provide captions for videos and transcripts for audio content. Respect user preferences for reduced motion by using the prefers-reduced-motion media query:
```
@media (prefers-reduced-motion: reduce) {
  animation: none;
}
```
Testing Your Accessible Code

Even the best code needs testing. Use these methods:
- Automated Testing: Tools like Google Lighthouse or WAVE can identify common issues.
- Manual Testing: Navigate your site using only a keyboard or a screen reader (e.g., NVDA, VoiceOver).
- User Testing: Get feedback from users with disabilities to uncover real-world issues.
Testing should be an ongoing part of your development process to catch and fix issues early.

Challenges Developers Face—and How to Overcome Them

Challenge: Understanding WCAG Guidelines Can Be Intimidating

Solution: Start with the essentials. Focus on foundational elements like semantic HTML, alt text, and keyboard navigation. Once these are second nature, dive deeper into more complex guidelines—one step at a time.

Challenge: Debugging ARIA Roles Can Be Tricky

Solution: ARIA can feel like uncharted territory, but tools like ARIA Authoring Practices and automated testing tools (e.g., Google Lighthouse or WAVE) make it manageable. Stick to semantic HTML where possible to minimize the need for custom roles.

Challenge: Maintaining Accessibility During Updates

Solution: Accessibility isn’t a one-and-done task; it’s an ongoing commitment. Make accessibility checks part of your QA process and leverage tools like WAVE to identify issues after every update. Document accessibility practices in your team’s workflow to keep everyone aligned.

Challenge: Balancing Deadlines with Accessibility Goals

Solution: Tight deadlines can pressure teams to deprioritize accessibility. Combat this by integrating accessibility from the start of a project rather than treating it as an add-on. Small, consistent efforts save time in the long run and prevent last-minute fixes.

By acknowledging these challenges and embracing practical solutions, developers can turn obstacles into opportunities to create better, more inclusive websites.

Keep Learning and Building Accessible Code

Web accessibility is a continuous journey—and an exciting one. As developers, we thrive on solving problems and improving our craft, and accessibility is no different. By staying updated with trusted resources like WebAIM, MDN Web Docs, and the A11y Project, you can keep sharpening your skills and pushing the boundaries of what’s possible. Engage with communities, take courses, and embrace every opportunity to learn. Every small step you take makes the web a more inclusive place for everyone.

Writing accessible code is about thoughtful, inclusive choices that enhance user experiences. Start with the basics, make accessibility an integral part of your workflow, and let learning drive your improvements. The impact of your efforts extends far beyond compliance; it creates meaningful connections and opens your work to all users, regardless of ability.

Ready to take your commitment further? Schedule an ADA briefing with 216digital. Our team specializes in tailored web accessibility solutions, helping you mitigate risks and create a more inclusive online presence. Let’s build a better web—together.
Greg McNeil

January 9, 2025

How-to Guides

accessible code, ADA Compliance, How-to, WCAG, web developers, web development
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

Why Placeholders Cause Problems in Forms

1. They Disappear When Users Start Typing

2. Not All Browsers Support Them

3. Once Filled, Fields Lose Context

4. Reviewing Answers Becomes a Hassle

5. Fixing Errors Gets Confusing

6. Some Browsers Hide Placeholders When the Field Is Focused

7. They Can Be Mistaken for an Actual Answer

8. Low Contrast Makes Them Hard to Read

9. Some Screen Readers Don’t Read Placeholder Text

10. Smaller Clickable Area Without Labels

11. Placeholder Text Gets Cut Off

12. Some Browsers Don’t Translate Placeholders

13. Auto-Complete Can Mess Things Up

14. High Contrast Mode Makes Placeholders Look Like User Input

What You Should Do Instead

Use a Visible Label

Put Hint Text Below the Label

Provide Clear Formatting Instructions

Test for Accessibility

Consider Better UX Patterns

Clear Forms, Better Experiences

What Is ARIA (and Why Does It Matter)?

Why Semantic HTML Should Be Your First Choice

What is Semantic HTML?

Why Does it Matter?

Real-world Example

When (and Why) ARIA Is Actually Needed

Filling the Gaps

Roles, States, and Properties

Example: Tabs and sliders

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

Misusing Roles

Example

Redundant or Conflicting Roles

Example

Incorrect State Management

Example

ARIA Overload

Example

Misusing aria-hidden

Example

Why “No ARIA” is Often the Best Choice

Best Practices for Using ARIA the Right Way

Use Native HTML First

Example

Be Precise with Roles and States

Example

Don’t Add ARIA Where It’s Not Needed

Example

Test with Real Assistive Tech

Conclusion

Need Help with Web Accessibility?

Foundational Accessibility Principles for Drop-Down Menus

1. Use Semantic HTML

2. Ensure Keyboard Navigation

3. Use ARIA Roles and Attributes Wisely

Structuring Accessible Drop-Down Menus

1. Toggling Visibility

2. Managing Focus for Keyboard Users

3. Enabling Smooth Keyboard Interactions

Testing Your Drop-Down Menus for Accessibility

1. Screen Reader Testing

2. Keyboard Testing

3. Contrast and Readability

Best Practices for Creating Intuitive Menus

Conclusion

Why Accessibility in JavaScript Matters

Common Accessibility Barriers in JavaScript

Best Practices for Accessible JavaScript

1. Ensure Keyboard Accessibility

2. Manage Focus Properly

3. Use ARIA Responsibly

4. Announce Dynamic Content Updates

5. Test Custom Widgets Thoroughly

Testing JavaScript for Accessibility

Automated Tools

Manual Testing

Real-World Scenarios

Meeting WCAG Requirements

The Problem with `display: none`

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

`aria-hidden="true"`