web developers Archives - Page 4 of 4/Tag

Using NVDA to Test Web Accessibility
Making your website accessible isn’t just a checkbox to tick—it’s about creating a space where everyone feels welcome. Imagine trying to browse a site only to hit wall after wall because it wasn’t designed with all users in mind—that’s the reality for millions of people with disabilities. One of the most effective ways to understand and improve your site’s accessibility is by testing it with tools like NVDA (NonVisual Desktop Access). NVDA is a free, open-source screen reader for Windows that provides audio feedback, enabling users who are blind or visually impaired to explore and interact with digital content.

If you’re a developer or designer aiming to make your website user-friendly for everyone, testing with NVDA can be a real eye-opener. This guide will walk you through everything you need to get started—from setting up NVDA to identifying common accessibility barriers. We’ll also compare NVDA with other screen readers and share tips on integrating accessibility checks into your workflow.

Why Testing with a Screen Reader Matters

Testing with a screen reader is crucial for building websites that everyone can use and enjoy. Did you know that over 8 million people in the United States have a visual disability? Worldwide, an estimated 2.2 billion people are affected by some form of visual impairment. That’s a considerable number of users who rely on screen readers like NVDA to navigate the web. Yet, despite this need, studies show that 95.9% of the world’s top million homepages still have detectable accessibility issues, many of which directly impact screen reader users.

Common Accessibility Barriers

While standards like the Web Content Accessibility Guidelines (WCAG) exist to help ensure content is accessible, there’s still a gap between ticking the compliance boxes and actual usability. Some common accessibility barriers impacting screen reader users include:
- Missing or Incorrect Alt Text: Without alt text, images lack context, making it hard for users to understand what’s on the page.
- Improper Heading Structure: Jumping from an H1 to an H3 heading (and skipping H2) can make navigating a page disorienting.
- Inadequate Link Descriptions: Using link text like “Click here” doesn’t tell users where the link will take them.
- Lack of Keyboard Navigation: If elements aren’t reachable by the keyboard, users may not be able to navigate away from certain sections.
By testing your site with a screen reader like NVDA, you can spot and fix these barriers directly, ensuring your content is genuinely usable—not just technically accessible. This step is vital for engaging a wide audience, including customers who rely on screen readers for equal access.

Plus, by prioritizing screen reader accessibility, you’re not just meeting legal requirements; you’re showing that your brand values inclusivity, which can resonate with customers and build loyalty.

Getting Started with NVDA

Ready to dive in? First, you’ll need to install NVDA on a Windows computer. Just head over to its official website and follow the straightforward instructions. Once it’s installed, take a few minutes to explore the settings. NVDA lets you adjust things like speed, voice pitch, and how much information it reads out loud. Tweaking these settings can make your screen reader testing smoother and help you catch all the essential details without getting distracted.

Understanding the Basics of NVDA

At first glance, NVDA might seem a bit overwhelming, but don’t worry—once you get the hang of a few essential controls, you’ll be navigating like a pro. The main control is the Insert key, which you use along with other keys to execute commands. For example, pressing Insert + Spacebar toggles between browse and focus modes, showing how users move between different sections and interact with elements on your site.

Key Shortcuts to Know
- Tab: Move through interactive elements like buttons and links.
- Shift + Tab: Go back through items, helping you check the flow of navigation.
- H: Navigate through headings in sequence (Shift + H moves backward), which is crucial for accessibility.
- K for links or G for graphics: Jump to specific content, helping you quickly assess if important items are accessible.
Testing for Accessibility Barriers with NVDA

Once you’re comfortable with NVDA, it’s time to put your website to the test. The goal is to see how easy (or difficult) it is for a screen reader user to find and understand information on your site.

Check Your Navigation Structure

Screen reader users rely heavily on clear navigation. Headings should be marked in a logical order, and the Tab key should move through items sensibly. As you use NVDA, please pay close attention to how it announces headings, links, and interactive elements. For instance, links labeled “Read More” can be confusing, while “Learn More About Our Services” is much more straightforward. Descriptive link text is vital to helping screen reader users navigate confidently.

Confirm Image Descriptions

Proper alt text is a must for images. Use the G key to move through images and listen to the descriptions NVDA reads aloud. The alt text doesn’t need to be lengthy—just informative enough to give users an idea of the image’s purpose.

For additional information about alt text, read our article “Understanding Image Alt Text Descriptions.”

Test Interactive Elements Like Forms

Forms can be tricky for screen reader users if they’re not labeled well. As you move through form fields, listen to the labels NVDA reads. Each field should have a clear label, and error messages should be accessible, too. Testing with NVDA can reveal unlabeled fields or hidden error messages that might make filling out forms difficult.

Common Accessibility Barriers to Watch For

Using NVDA can help you spot common barriers that affect accessibility:
- Keyboard Traps: These occur when users get stuck in one part of the page. Use the Tab and Shift + Tab keys to move around; if you find yourself stuck, it’s likely a keyboard trap.
- Focus Indicators: Screen reader users (and keyboard users in general) need a visible marker to show where they are on the page. Test this by tabbing through your site to see if each interactive element has a clear indicator.
- Content Flow: Listen to your site in linear order, from top to bottom. Does it make sense as you go? Unclear structure or skipped headings can confuse users trying to navigate the content in a meaningful order.
Documenting What You Find

As you test, it’s helpful to document any issues you come across. Be specific: note where each issue happens, what the problem is, and why it’s an accessibility issue. For example, if a button lacks a label, describe which button it is, where it’s located, and how this impacts screen reader users. Including step-by-step details on how you tested (like key sequences or what NVDA readout) can also help your team quickly recreate and fix the issue.

Trying Out Other Screen Readers

While NVDA is a fantastic tool, remember that users rely on different screen readers like JAWS or VoiceOver on Apple devices. Testing with more than one screen reader can uncover accessibility issues that one tool might miss. NVDA is particularly good with dynamic content and ARIA (Accessible Rich Internet Applications) attributes. So, if you can, try testing with multiple screen readers to get a fuller picture of your site’s accessibility.

Making Accessibility Part of Your Process

Accessibility testing with NVDA shouldn’t be a one-time thing—it works best when it’s part of your development process from the start. By catching issues early, you’ll avoid significant fixes later and create a better experience for everyone. During design, consider accessibility-friendly patterns like high-contrast colors and adjustable font sizes. During development, use NVDA to test as you go and do a final check once your site is live.

And if possible, getting feedback from users with disabilities can be incredibly valuable. While NVDA can help you simulate a screen reader experience, real users bring real-world insights that can highlight usability issues you might not think of.

Wrapping Up

Using NVDA to test your website’s accessibility is a powerful step toward creating a more inclusive online experience, but there’s so much more to accessibility than just technical adjustments—it’s about making your site welcoming to everyone, including customers who rely on assistive technology.

To help you navigate the broader world of ADA compliance and web accessibility, consider scheduling a briefing with 216digital. Our team can walk you through key accessibility requirements, share insights into your site’s current compliance level, and guide you on building a sustainable, accessible web presence. Let’s work together to make your website an inclusive, welcoming space for all users. Schedule your ADA briefing with 216digital today, and take the next step toward true digital accessibility.
Kayla Laganiere

November 5, 2024

How-to Guides

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

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

Why Keyboard Accessibility Matters

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

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

Common Barriers to Keyboard Accessibility

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

Lack of Focus Indicators
- Problem: Without visible focus indicators, keyboard users may not know where they are on the page. This becomes particularly frustrating when navigating forms or interactive menus.
- Solution: Use CSS to style focus indicators and make them highly visible, such as by changing the border color, background, or outline. Here’s an example:
```
button:focus, a:focus {
	outline: 3px solid #005fcc;
	background-color: #f0f8ff;
}
```
Improper Tab Order
- Problem: Elements on a page need to logically match the visual layout. Without a logical tab order, users may be taken through an erratic sequence, which can lead to confusion and missed information.
- Solution: Arrange your elements in HTML to follow the intended visual order and limit use of the tabindex attribute. By default, elements will follow the document’s source order, so it’s best to organize your code this way.
Focus Traps
- Problem: Focus traps occur when users can’t tab away from a particular element, like a popup or modal. Once they’re stuck, the rest of the page becomes inaccessible until they can close the focus-trapped section.
- Solution: Ensure focus returns to the main content once the user dismisses the popup or modal, using JavaScript if necessary:
```
// Example of returning focus after modal close
document.getElementById("closeModalButton").addEventListener("click", function() {
  document.getElementById("mainContent").focus();
});
```
ARIA Widgets and Their Challenges

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

Why ARIA Widgets Often Fail

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

Reliance on ARIA Without Semantic HTML

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

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

Overuse of role and tabindex Attributes

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

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

JavaScript-Dependent Behavior

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

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

Best Practices for Creating Keyboard-Accessible Interactive Elements

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

Prioritize Native HTML Elements

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

Use ARIA Judiciously

Use ARIA only when there’s no HTML equivalent, like custom dropdowns or sliders. And if you do need ARIA attributes, implement them carefully with an understanding of their purpose. For example, use aria-expanded to indicate the open or closed state of a dropdown menu:
```
<button aria-expanded="false" aria-controls="menu">Menu</button>
<ul id= "menu" hidden>
  <li><a href="#home">Home</a></li>
  <li><a href="#about">About</a></li>
</ul>
```
Enable Logical Focus Management

Ensure that interactive elements maintain a logical and intuitive focus order. When creating modals or popups, use JavaScript to trap focus within the modal until it’s closed and then return focus to the last element interacted with:
```
const modal = document.getElementById("modal");
const lastFocus = document.activeElement;
// Trap focus within modal
modal.addEventListener("keydown", (e) => {
  if (e.key === "Tab") {
    // Logic to keep focus within modal
  }
});
// Restore focus after modal close
modal.addEventListener("close", () => {
  lastFocus.focus();
});
```
Include Skip Links

Skip links are simple yet effective. They allow keyboard users to jump directly to the main content, bypassing repetitive navigation menus. Add a skip link that appears when focused, like this:
```
<a href="#mainContent" class="skip-link">Skip to main content</a>
<main id="mainContent">
  
</main>
```
The Importance of Testing for Keyboard Accessibility

Testing is critical to achieving real keyboard accessibility. Use keyboard-only navigation to interact with your site, ensuring that each element responds to the Tab, Enter, and Escape keys appropriately. Here are a few tips for testing:
1. Turn Off Your Mouse: Try navigating your site using only the keyboard. See if you can reach every interactive element and complete all tasks.
2. Use Assistive Technology Simulators: There are free screen readers (such as NVDA or VoiceOver) that let you experience your website as a keyboard-only user would.
3. Run Accessibility Audits: Automated tools like Google Lighthouse or WAVE can catch many keyboard accessibility issues, but a manual review is still necessary.
Conclusion

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

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

October 29, 2024

How-to Guides

ARIA, How-to, keyboard accessibility, web developers, web development
Digital Accessibility Lawsuit Targets Contractors
The recent case of Bryan Bashin vs. ReserveCalifornia.com has opened the door to a new type of accessibility lawsuit. It’s not just website owners being held accountable—government contractors who build and maintain websites are now in the spotlight too.

This case is important for developers, designers, and accessibility experts working on government websites, as it sets a strong example of what can happen when accessibility isn’t prioritized. More importantly, it serves as a wake-up call for businesses and contractors alike to understand that accessibility is not just an option but a legal necessity. Failure to comply with accessibility standards could result in costly lawsuits and reputational damage.

In today’s digital world, ensuring that everyone, including people with disabilities, can use your website is not just good practice—it’s the law.

Case Overview: A New Direction

Bryan Bashin, who is visually impaired, sued ReserveCalifornia.com, claiming the site was inaccessible to people with disabilities. This violated both the Americans with Disabilities Act (ADA) and California’s Unruh Civil Rights Act. What made this case different? Bashin didn’t go after the website owner, California State Parks—he targeted the contractors who created and managed the site.

ReserveCalifornia.com is a key website for booking campsites and other outdoor activities in state parks. Because it wasn’t fully accessible, users who depend on assistive technologies, like screen readers, had trouble navigating it. By focusing on the developers, Bashin’s lawsuit sends a clear message: if you’re responsible for public websites, you must meet digital accessibility standards—or you could face legal action.

The Laws: Unruh Act and ADA Title II

This case relies on two important laws: California’s Unruh Civil Rights Act and the updated ADA Title II rules for government websites.
- Unruh Act: This California law allows people with disabilities to sue organizations that don’t make their services accessible. Bashin used this law to seek damages, which gave him additional legal options beyond the federal ADA.
- ADA Title II: This part of the ADA focuses on making sure government services, programs, and activities—including websites—are accessible. Recent updates have strengthened these rules, making it clear that public websites must meet accessibility standards. Bashin’s lawsuit shows how these laws are evolving, putting contractors in the spotlight.
What It Means for Web Developers: Widespread Impacts

While this lawsuit happened in California, its effects could reach across the country. The Unruh Act may be specific to California, but ADA Title II applies nationwide. Developers working on public sector projects need to understand that ignoring accessibility could lead to serious risks, especially as more governments crack down on non-compliance.

Developers and contractors are expected to follow the Web Content Accessibility Guidelines (WCAG), the international standard for digital accessibility. Not meeting these standards puts them at risk of lawsuits like Bashin’s, and the $2 million settlement in this case shows that courts are willing to hold developers accountable.

What is the WCAG?

WCAG is the go-to guide for making websites accessible to people with disabilities, such as those who are blind, deaf, or have cognitive challenges. It focuses on making content:
- Perceivable: Users must be able to experience content, whether through text, images, or other formats like captions.
- Operable: Users should be able to navigate the site with different tools like a mouse, keyboard, or voice commands.
- Understandable: The site’s information and operations should be clear and easy to use.
- Robust: The site should work with current and future assistive technologies.
For developers, following WCAG not only ensures legal compliance but also opens websites to a wider audience and improves overall user experience.

Why WCAG Matters

You might ask yourself, “Why should I care about WCAG compliance?” First and foremost, it helps make your website accessible to a wider audience. If your site isn’t usable for people with disabilities, you could be missing out on potential customers. In a digital age where online shopping and information-seeking are essential, excluding anyone based on accessibility is not just unfair—it’s bad for business.

Moreover, the Bashin case shows that failing to meet accessibility standards can lead to legal consequences. As more digital accessibility lawsuits arise, companies that don’t prioritize compliance could face significant financial penalties. By adhering to WCAG guidelines, you protect yourself from legal issues and show that you care about your users.

Best Practices for Developers and Digital Accessibility Experts

Bashin’s case is a reminder that developers and consultants must make digital accessibility a priority from the start. It’s no longer enough to just create a good-looking or functional website—it has to work for everyone, including people with disabilities.

Here’s what developers and business owners should focus on:
- WCAG Knowledge: Work with developers who understand WCAG standards and have experience making accessible sites.
- Conduct a Website Audit: Regularly audit your website for accessibility issues. There are tools available online that can help you identify problems, such as missing alt text for images or issues with color contrast.
- Implement Ongoing Training: Train your staff, especially those involved in website management and content creation, about digital accessibility.
- Ongoing Monitoring: Accessibility isn’t a one-time job. Websites need regular testing to stay compliant. This proactive approach helps prevent potential violations before they lead to costly lawsuits.
- Stay Informed and Up-to-Date: Digital accessibility standards and regulations change over time. Make any necessary updates to your website to remain compliant.
The Bigger Picture: Nationwide Repercussions

The Bryan Bashin vs. ReserveCalifornia.com case is a strong reminder for developers everywhere: accessibility is no longer optional. By holding government contractors accountable for digital accessibility violations, this case sets a powerful precedent. Developers and accessibility experts must be proactive and make sure all public-facing websites—especially those for government services—comply with WCAG and other accessibility standards. The future of digital accessibility enforcement is here, and developers need to stay ahead to avoid costly legal risks.

To avoid the risks of costly legal action and make sure your website is accessible to everyone, now is the time to act. Find out if your website is ADA compliant today by scheduling a 15-minute complimentary website audit and consultation with our experts at 216digital. We can help determine if your site is at risk of a lawsuit and provide fast, effective ADA compliance solutions so you can focus on what matters most: running your business.
Greg McNeil

October 10, 2024

Legal Compliance

Accessibility, ADA Compliance, ADA Website Compliance, Bryan Bashin vs. ReserveCalifornia.com, Unruh Civil Rights Act, web developers

Using NVDA to Test Web Accessibility

Why Testing with a Screen Reader Matters

Common Accessibility Barriers

Getting Started with NVDA

Understanding the Basics of NVDA

Key Shortcuts to Know

Testing for Accessibility Barriers with NVDA

Check Your Navigation Structure

Confirm Image Descriptions

Test Interactive Elements Like Forms

Common Accessibility Barriers to Watch For

Documenting What You Find

Trying Out Other Screen Readers

Making Accessibility Part of Your Process

Wrapping Up

The Importance of Keyboard Accessibility & Why ARIA Widgets Don’t Work

Why Keyboard Accessibility Matters

Common Barriers to Keyboard Accessibility

Lack of Focus Indicators

Improper Tab Order

Focus Traps

ARIA Widgets and Their Challenges

Why ARIA Widgets Often Fail

Reliance on ARIA Without Semantic HTML

Overuse of role and tabindex Attributes

JavaScript-Dependent Behavior

Best Practices for Creating Keyboard-Accessible Interactive Elements

Prioritize Native HTML Elements

Use ARIA Judiciously

Enable Logical Focus Management

Include Skip Links

The Importance of Testing for Keyboard Accessibility

Conclusion

Digital Accessibility Lawsuit Targets Contractors

Case Overview: A New Direction

The Laws: Unruh Act and ADA Title II

What It Means for Web Developers: Widespread Impacts

What is the WCAG?

Why WCAG Matters

Best Practices for Developers and Digital Accessibility Experts

The Bigger Picture: Nationwide Repercussions