VPAT, short for Voluntary Product Accessibility Template, is a reporting format that gauges the level of accessibility for a product. It evaluates how usable your product is for people with disabilities.

This is crucial if your business provides Information and Communication Technology (ICT) services to federal customers or customers who are directly or indirectly funded by various  federal governments. The document helps procuring officers assess the level of compliance of the product to applicable accessibility regulations.

One way not having a VPAT might be affecting businesses is by losing clients to competitors who are offering a VPAT to their customers.

How are VPATs Used?

A VPAT enables procuring officers of government contracts to make an informed decision whether to buy your product and services or not.

Here are 3 ways a VPAT can be used by governments:

• It can help them understand the level of accessibility compliance your products or services offers.
• They can compare accessibility compliance of similar services or products.
• They can choose the appropriate services or product that meets their needs in terms of accessibility standards and legal requirements.

How to create a VPAT?

The easiest way is by downloading a freely available template and customizing it to your needs such as this one offered by the Information Technology Industry Council (ITI).

A VPAT usually includes:

• Product or Service Information: Basic details on your product or service
• Accessibility Standards: Accessibility standards you’re using to assess your product or service accessibility
• Conformance Level: Indicating level of compliance (WCAG A, AA or AAA)
• Product or Service Features: Components of your product or service and their accessibility status
• Supporting Documentation: i.e Accessibility test results

After completing your VPAT you can add it on your website or provide it to end-clients when requested.

Web accessibility is always evolving and updating your products and services can affect how accessible they are. Regularly updating your VPAT at least once a year is recommended to align with your feature releases, new accessibility and government regulations. The biggest mistake we encounter is having an in-house product manager complete the VPAT which leaves room for error if they don’t have accessibility experience. 

Engaging with an external accessibility company to complete your VPAT is advisable to ensure that it’s completed accurately by relying on their expertise to provide insight on testing methods, establish best practices and certify that the report is filled out accurately so you don’t miss anything.

There are multiple formats of VPATs which is a globally recognized template. Whether you are doing business in the U.S., Europe, or Internationally, our accessibility specialists can assist you create a VPAT.

Have a VPAT already? We can help you review or update it!  Contact us at info@advancedbytez.com to get started with your VPAT today.

In today’s digital landscape, creating accessible navigation is essential for inclusive websites. Dropdown menus are a popular navigation tool, but they need to be designed with accessibility in mind. When done right, these menus allow users of all abilities—including those who rely on screen readers or keyboard navigation—to access options easily.

Accessible navigation not only fosters a sense of belonging but also enhances user engagement and satisfaction. By removing barriers, we ensure that everyone, regardless of their physical or cognitive abilities, can have a seamless experience on the web.

This blog will explore the importance of accessible dropdown menus, related WCAG guidelines, and how we can make them accessible for all users.

The Importance of Accessible Navigation    

Accessible navigation is the cornerstone of an inclusive online experience. Dropdown menus should cater to all users, ensuring that everyone can find what they need without barriers. Accessible navigation is particularly vital for individuals with disabilities, who may rely on assistive technologies to interact with content. By prioritizing accessibility, we not only comply with legal standards but also enhance our website’s reach and usability.

Moreover, accessible dropdown menus improve the overall user experience for everyone. Well-designed menus can make content easier to discover, reduce frustration, and promote longer engagement on your site. An inclusive approach also reflects positively on your brand, demonstrating a commitment to diversity and user-centric design. Ultimately, prioritizing accessibility in dropdown menus helps create a more equitable digital landscape.

Challenges in Dropdown Menu Design

Dropdown menus often rely on mouse interactions, which can be challenging for users who navigate with keyboards or screen readers. On mobile devices, issues like small touch targets and unexpected menu collapses during scrolling introduce more accessibility concerns.

Common Issues in Dropdown Menus

Dropdown menus are a convenient way to organize website navigation, but they can create accessibility challenges for some users. Issues like difficult keyboard navigation and limited screen reader support can make dropdowns frustrating to use.

In this section, we’ll go over some of the most common problems with dropdown menus and share tips on how to fix them to make your website easier for everyone to navigate.

Keyboard Navigation Barriers

Dropdown menus frequently lack comprehensive keyboard support, requiring users to rely on a mouse for expanding options. Without clear keyboard shortcuts or focus management, navigating through menu levels becomes difficult for keyboard-only users, who may encounter dead ends within complex menu structures.

Screen Reader Compatibility Issues

Dropdowns can be problematic for screen reader users, especially if the menu’s open or closed state is not clearly announced. Without accessible ARIA attributes, users may become disoriented, unable to determine if a dropdown is accessible or relevant.

Screen reader users also face difficulties when navigating through lengthy or multi-level menus that aren’t structured for linear navigation.

Challenges for Mobile and Touchscreen Users

Mobile users, particularly those with visual impairments or fine motor limitations, may find dropdown menus cumbersome to use. Small touch targets make selecting options more difficult, while menus that disappear during common actions like zooming or scrolling can lead to frustration and disrupt the browsing experience.

Hover-Triggered Menus

Menus triggered by hover actions pose accessibility challenges for screen reader users and keyboard navigators. Without an equivalent action for keyboard or assistive technology users, hover-only dropdowns are inaccessible, leaving users unable to access critical menu items unless they use a mouse.

Lack of Visual Cues

Dropdown menus without visual indicators, such as arrows or icons showing when they are open or closed, can create confusion for all users. This is especially problematic for those with cognitive impairments or visual disabilities, who rely on these visual cues to navigate effectively.

Consistent and intuitive indicators improve usability across diverse user groups.

Inconsistent Behavior Across Devices

Dropdown behavior may vary significantly across desktops, tablets, and mobile devices, introducing inconsistencies. Menus that function smoothly on one platform may behave unpredictably on another, complicating the user experience for those relying on predictable, consistent interactions.

WCAG Guidelines for Accessible Dropdown Menus

To ensure dropdown menus are accessible, we can follow the Web Content Accessibility Guidelines (WCAG). Here are some key criteria to consider:

• 2.1.1 Keyboard Accessibility: All functionalities should be operable via keyboard to allow navigation without a mouse.
• 2.4.3 Focus Order: The focus should move logically through the menu options for easy navigation.
• 2.4.7 Focus Visible: A clear visual focus indicator is essential for users navigating via keyboard.
• 1.3.1 Info and Relationships: Using semantic HTML and ARIA attributes helps convey the dropdown structure and state to assistive technologies.
• 4.1.2 Name, Role, Value: Elements must have programmatically identifiable roles, names, and states for accurate interpretation by assistive technologies.

How to Create Keyboard-Friendly (Accessible) Dropdown Menus

To enhance keyboard accessibility, use semantic HTML elements like <nav>, <ul>, and <li>, as much as possible.

Here’s a simple example of a keyboard-accessible dropdown menu:

<nav>

  <ul>

    <li><a href="#home">Home</a></li>

    <li>

      <button id="about-button">About</button>

      <ul id="submenu" hidden>

        <li><a href="#team">Our Team</a></li>

        <li><a href="#history">Our History</a></li>

      </ul>

    </li>

    <li><a href="#services">Services</a></li>

  </ul>

</nav>

Adding Visual Cues for Dropdown States

It’s helpful to include visual indicators that show whether a dropdown is expanded or collapsed. Adding an icon next to the menu option can visually communicate the dropdown state.

For instance:

#about-button[aria-expanded="true"]::after {

  content: "▲"; /* Arrow up to indicate expanded */

}

#about-button[aria-expanded="false"]::after {

  content: "▼"; /* Arrow down to indicate collapsed */

}

These small additions improve visual clarity, helping all users, especially those relying on visual cues, to understand the menu’s current state.

Furthermore, when the dropdown is collapsed, ensure that the hidden elements are not accessible by screen readers. Use attributes like hidden or display: none; to prevent screen readers from reading the hidden content.

#submenu[hidden] {

  display: none;

}

This approach ensures that assistive technology users will only access elements that are currently visible.

Using ARIA Attributes for Improved Accessibility

ARIA (Accessible Rich Internet Applications) attributes play a crucial role in enhancing the accessibility of dropdown menus for screen reader users and others relying on assistive technologies. These attributes help bridge the gap between standard HTML elements and the dynamic nature of web applications.

Here are key ARIA attributes to consider:

aria-expanded:

This attribute indicates whether the dropdown is currently expanded (true) or collapsed (false). It provides essential context to screen reader users, letting them know the state of the menu.

For example, when a user activates a button to open a dropdown, the value of this attribute should change accordingly, ensuring that assistive technologies can relay this information.

aria-controls:

This attribute links the trigger element (e.g., a button) to the submenu it controls. By using this attribute, you clarify the relationship between the button and the dropdown, allowing screen readers to convey that activating the button will affect the submenu. This connection is vital for users who may not be able to visually perceive the menu structure.

aria-haspopup:

This attribute tells screen readers and other assistive technologies that an element has a related popup, such as a dropdown menu or dialog. When set to true, it informs the user that activating the element (e.g., a button) will open a submenu or another form of contextual content.

This is important because, without this attribute, a user may not expect additional options to appear after interacting with the element. Additionally, assistive technology can provide users with extra information, such as the type of popup (menu, dialog, etc.), improving the overall experience.

In the case of dropdown menus, using aria-haspopup=”true” alerts the user that they can expect more content to appear upon interaction.

Here’s an example of how to implement these attributes effectively:

<nav>

  <ul>

    <li><a href="#home">Home</a></li>

    <li>

      <button id="about-button" aria-haspopup="true" aria-expanded="false" aria-controls="submenu">About</button>

      <ul id="submenu" hidden>

        <li><a href="#team">Our Team</a></li>

        <li><a href="#history">Our History</a></li>

      </ul>

    </li>

    <li><a href="#services">Services</a></li>

  </ul>

</nav>

The following script toggles the dropdown menu’s visibility and manages focus navigation using the keyboard.

const menuButton = document.getElementById('about-button'); // Selects the button that controls the dropdown menu.

const dropdownMenu = document.getElementById('submenu'); // Selects the submenu to be toggled on and off.

// Event listener to handle mouse click events on the dropdown button.

menuButton.addEventListener('click', function() {

  const isExpanded = menuButton.getAttribute('aria-expanded') === 'true'; // Checks the current aria-expanded state (true or false).

  menuButton.setAttribute('aria-expanded', !isExpanded); // Toggles the aria-expanded state to its opposite (true or false).

  dropdownMenu.hidden = isExpanded; // Toggles the visibility of the submenu (hidden if expanded, visible if collapsed).

});

// Event listener to handle keyboard navigation for the dropdown button.

menuButton.addEventListener('keydown', function(event) {

  if (event.key === 'ArrowDown') {

    dropdownMenu.querySelector('li a').focus(); // If the down arrow key is pressed, the focus moves to the first item in the dropdown.

  } else if (event.key === 'Escape') {

    menuButton.focus(); // If the Escape key is pressed, the focus returns to the dropdown button.

    dropdownMenu.hidden = true; // The submenu is collapsed and hidden.

    menuButton.setAttribute('aria-expanded', 'false'); // aria-expanded is set to false since the menu is collapsed.

  }

});

// Event listener to handle keyboard navigation within the dropdown menu.

dropdownMenu.addEventListener('keydown', function(event) {

  if (event.key === 'ArrowUp') {

    const focusedItem = document.activeElement.parentElement; // Gets the parent element of the currently focused item.

    const previousItem = focusedItem.previousElementSibling; // Selects the previous sibling (item) in the list.

    if (previousItem) {

      previousItem.querySelector('a').focus(); // If a previous item exists, moves the focus to the link in that item.

}

  } else if (event.key === 'ArrowDown') {

    const focusedItem = document.activeElement.parentElement; // Gets the parent element of the currently focused item.

    const nextItem = focusedItem.nextElementSibling; // Selects the next sibling (item) in the list.

    if (nextItem) {

      nextItem.querySelector('a').focus(); // If a next item exists, moves the focus to the link in that item.

}

  } else if (event.key === 'Escape') {

    menuButton.focus(); // If the Escape key is pressed, focus returns to the dropdown button.

    dropdownMenu.hidden = true; // The submenu is collapsed and hidden.

    menuButton.setAttribute('aria-expanded', 'false'); // aria-expanded is set to false since the menu is collapsed.

  }

});

By clearly defining the relationship and state of elements using ARIA as well as JavaScript to toggle their values, you can significantly enhance the experience for users who rely on assistive technologies.

Conclusion

Dropdown menus are a vital aspect of web navigation, but they require thoughtful design to ensure accessibility. By adhering to WCAG guidelines, leveraging ARIA attributes, and implementing keyboard functionality, developers can create dropdown menus that everyone can use. Accessible menus not only meet standards but also enhance the overall user experience, making the web a more welcoming place for all.

Accessibility testing is about ensuring that a website is easily accessible to everyone. And by “everyone” we mean people with disabilities, aged individuals or anyone who belongs to the disadvantaged group.

A standard web accessibility testing tool conducts thorough website testing to generate comprehensive reports on the current accessibility status of the tool. These tools further suggest proper fixes and recommendations to resolve these accessibility issues.

This blog will list the top 11 web accessibility testing tools for you to ensure that your website is ready for everyone’s usage.

So, let’s begin!

Top 11 Accessibility Tools/Extensions/Software for Quick Accessibility Check of your Website

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.”

Tim Berners-Lee 

Here are the top web accessibility tools and extensions to perform a quick accessibility check of your website:

1. Dynomapper

The first name on our best web accessibility testing tools list is Dynomapper. It allows you to test the accessibility of any website or app. The best part is that users can witness the live accessibility test within the browser itself with the “visualize” feature of Dynomapper. Additionally, Dynomap also generates comprehensive online accessibility test reports for the users’ easy understanding.

Top Features 

• Dynomapper can test HTML content and can easily create sitemaps irrespective of the URL
• Dynomapper’s powerful Crawler can arrange links and subdomains within minutes
• Dynomapper has outstanding customization features. It lets you personalize the sitemaps with colours for convenience
• Dynomapper can also import XML files for generating sitemaps

Pricing 

Starter plan – $64/month

Standard plan – $129/month

Organization plan – $399/month

2. WAVE

WAVE is a web accessibility evaluation tool that assists websites in creating accessible content. WAVE evaluates website content based on the WCAG guidelines and also conducts the manual evaluation of existing website content to point out all loopholes that could affect accessibility. From unlimited automated scanning to generating consolidated reports, WAVE does it all to help you scale.

Top Features 

• WAVE evaluates the accessibility of web pages by annotating the web page copy
• WAVE conducts the accessibility evaluation within the browser. It doesn’t save any data on the server.
• WAVE not only checks accessibility but suggests some recommendations to the users for fixing the accessibility issues.

Pricing 

WAVE charges the users based on the number of pages you are checking. Here is the detailed pricing chart for WAVE:

Source

3. Cynthia Says

Cynthia Says is another web accessibility checker on our list that assists users in identifying the accessibility compliance issues within your website. You can test each individual page of a website with this tool to find out the web accessibility errors and get consolidated and comprehensive feedback. The whole idea of launching Cynthia Says web accessibility checker was to increase the awareness of the community on accessibility testing and its significance.

Top Features 

• Cynthia Says evaluates the accessibility of your website based on WCAG 1.0 compliance
• It is a simple tool that runs smooth accessibility tests on your website and generates reports based on section 508 compliance
• It is a pretty old web accessibility tool and has not yet been updated for WCAG 2.0 testing

Pricing 

Free

4. LERA

LERA is a cutting-edge Chrome extension to perform the web accessibility audit of your web pages. It generates a granular, downloadable report that highlights various accessibility issues and the relevant fixes. Based on axe core it comes with a highly vetted industry rule engine to evaluate the accessibility status of your web applications. An advanced automated workflow conducts the website audit based on WCAG 2.1, Level A and AA success criteria and generates a report within minutes.

Top Features 

• Fast automated and manual accessibility testing for individual web pages
• A comprehensive, granular report that highlights the key accessibility issues and fixes
• Advanced testing and WCAG 2.1, Level A and AA compliant

Pricing: Free. LERA is the only web accessibility tool in our list that performs automated accessibility audits and generates a downloadable accessibility report in Excel for free.

5. AEL Accessibility Checker (AAC)

AAC is an API based widget that returns the scan of a single web page. Designed for users who are not comfortable working with APIs, AEL Accessibility Checker has a front-end mechanism to trigger the scan.

The AEL Accessibility Checker (AAC) is a user-friendly solution for quick evaluation of website accessibility. It checks for compliance with web accessibility standards such as WCAG 2.1 Level A, Level AA, and 2.0 Level A, Level AA standards.

Top Features:

• Easy to use API with one click.
• Our simple and powerful API works seamlessly across most available browsers.
• Obtain a single page accessibility report for your website in under 30 seconds.

Simply enter your URL in the input field and hit the “Check website” button! scanner will return a summary with the number of violations found on your web page along with an Accessibility score within 30 seconds. This score will help you gauge the Accessibility health of your website.

Pricing: Its free to use

6. SortSite

The next top web accessibility testing tool on our list is SortSite. You can use it as a web or desktop application on your Windows or Mac system. SortSite can evaluate your entire website and focus on major checkpoints like accessibility, compatibility, broken links, SEO, and usability with one simple click.

Top Features 

• SortSite evaluates websites based on WCAG 2.0, and 110 checkpoints.
• SortSite is compatible with both Windows and  Mac OS. You can use it as a desktop app, desktop browser and mobile browser.
• SortSite can evaluate the HTTP error codes instantly
• The best part about SortSite is that you can purchase it one time and use for a lifetime

Pricing 

Standard – $149 for a single user license

Professional – $349 for a single user license

Developer – $849 for a single user license

7. Accessibility Checker by CKSource

Another great web accessibility testing tool that inspects website content with respect to WCAG 2.0, is Accessibility Checker by CKSource. It checks all the compliance errors within your website content and makes it accessible in real-time. This tool is a favourite among developers and regular users because of its flexibility and simple user interface.

Top Features 

• Accessibility Checker has an optimized UI, and it inspects accessibility level in an in-depth manner
• It can perform accessibility testing of websites in three steps namely content validation, issue reporting and fixing
• The Accessibility Checking engine of this web accessibility tool can categorize issues as warning, error and notice
• There is a “Quick Fix” feature associated with this tool that frees up time by promptly fixing the common accessibility issues

Pricing 

Free – $0

Standard – $37

Flexible – Designed based on the specific requirements of an organization

8. JAWS 

JAWS is a screen reader application that helps you add a speech synthesizer to make the content on your website readable for people with visual impairment. JAWS stands for Jobs Access With Speech and it makes activities like reading emails, scanning PDFs, filling out forms, etc. easier.

Top Features 

• JAWS is a popular screen reader for people with visual impairment
• JAWS supports all browsers and is compatible with Windows operating system
• The Skim Reading feature of JAWS helps in accessing fast information and saves time for the users

Pricing 

Source 

9. Tenon

Tenon is a powerful web accessibility checker that can fix the accessibility issues of your entire organization with its smart accessibility testing kit. It can solve any accessibility issues while the accessibility test is ongoing. Tenon has a dedicated team that can assist your developers in writing accessible codes and in identifying appropriate KPIs for the accessibility testing process.

Tenon has now been acquired by Level Access.

Top Features 

• Tenon evaluates websites with WCAG 2.0 compliance
• Tenon tests the accessibility level of your codes during development and ensures that there are no errors post-deployment
• Tenon identifies the accessibility gaps on the highest traffic pages of a website and fixes the issues quickly
• Tenon helps you create accessibility policies and documentation for every role

Pricing 

Source

10. AChecker

The next web accessibility checker on our list is AChecker. It comes with an intuitive dashboard and generates an extensive accessibility report for your website after a detailed audit. AChecker evaluates your website based on WCAG 2.0 AA compliance and helps the users monitor each accessibility parameter.

Top Features 

• AChecker helps an organization to perform accessibility audit for multiple domains
• It can generate automated reports regularly for your website without any interruptions
• AChecker generates detailed accessibility reports highlighting status charts, for the domains and includes attractive visualization for sensitive areas
• AChecker comes with three premium plans and pricing changes based on the benefits associated with each plan

Pricing 

Basic – $99/month

Lighthouse Single – $199/month

Lighthouse Full – $249/month

11. AXE

AXE is an efficient web accessibility testing extension that helps businesses with automated website testing and compliant reports. It can save your time by quickly catching accessibility errors within coding and offers recommendations for fixing those issues. You can run this extension on multiple browsers including Google Chrome, Mozilla Firefox and Microsoft Edge.

Top Features 

• AXE has a free, open-source extension available for installation and anyone can use it to test the accessibility of website content
• AXE’s accessibility test report adds links to all identified issues to understand each issue in detail
• AXE evaluates website accessibility in light of WCAG 2.0, section 508 compliance
• AXE also comes with a version for manual accessibility testing

Pricing 

Available for free installation. However, to download the accessibility testing report, you need to upgrade to the pro version.

Final Words

Before summing up, all we want to mention is that the concept of accessibility has a deep meaning associated with it. When you are trying to scale your business, you have to build a website that is accessible for everyone. Businesses can’t predict which type of audience will visit their website.

What businesses can do is always stay prepared. We hope you find a web accessibility tool from this list that matches your requirements and helps you build an accessible website. You can always click here to learn more about LERA.

Update: This content has been updated to reflect that Tenon.io is now acquired by Level Access

ARIA Label is an attribute that defines a value to label an interactive element. In other words, it provides the accessible name for an element. An aria-label is intended to be used when there is no visible label present. 

A common example is the use of only icons instead of a button or a link without text. Most users are familiar with the use of the “heart” icon to like a post on social media,

Or, the use of social sharing icons in the footer of a website.

The accessible name for links or buttons come from the button text or link text. As the icons are wrapped inside a <button> or <a> tag, there is no place to display any visible button or link text. If there is no alt text used for the image, the element will not have an accessible name and will either announce “blank” or the file name of the SVG to users who rely on screen readers to navigate the web. 

Aria Label Example

Below is a code example of a “heart” button without an accessible name: 

<button>
	<i class="fas fa-heart"></i>
</button>

Below is an example of how to use the aria-label attribute to provide an accessible name for the “heart” button:

<button ARIA-label="Like this post">
	<i class="fas fa-heart"></i>
</button>

In this example, the ARIA-label attribute specifies that the button’s purpose is to “Like this post.” Screen readers will announce this label to users, ensuring that they understand the button’s function even without a visual label.

CAPTCHA which stands for “Completely Automated Public Turing tests to tell Computers and Humans Apart” are found everywhere on the Web, primarily used to prevent web scrapers and bots from interacting with websites. They’re also useful in protecting websites from DDOS attacks, which can slow down a website and, in some cases, completely take them off the Internet.

They’re intentionally built to give users a hard time, meaning the user has to prove they’re human and not a bot. That requires them to overcome a challenge to gain access to a resource on a website or to submit information to the web server through a form. 

There are three types of CAPTCHA challenges:

• Auditive
• Textual
• Visual

Each one of them offers a specific challenge to users and with this comes the issue of accessibility and inclusivity.

Generally speaking, traditional CAPTCHAs have always been a source of frustration for Web users. Especially those living with a disability, it is a known fact today that not all Web users have the same capacity and ability to navigate the web and this includes solving CAPTCHA challenges.

CAPTCHAs are a double-edged sword. On one side they protect your website from bots and spammers and on the other they can be problematic in terms of accessibility. 

Let’s have a look at some common accessibility issues with traditional CAPTCHA methods and how you can solve them and some accessible alternatives you can use instead.

Common Accessibility Issues With CAPTCHAS

The real problem with older CAPTCHA technology is that they were implemented without accessibility in mind and using them on your website can be a disaster for accessibility and user experience.

Because they’re built to be challenging to solve and to differentiate between humans and robots, they can be overwhelming to users with visual, cognitive and physical disabilities. This makes it extremely hard or in some cases impossible for them to solve those challenges. A web developer must be careful when choosing and implementing them on your website and ensure they’re inclusive to all users.

WCAG 2.2, under the AAA criterion, requires that whenever a CAPTCHA is used during authentication, you should at least provide an alternative method that doesn’t require the user to pass a cognitive test or provide assistance to complete the CAPTCHA.

Here are some alternative methods that can be used for authentication:

• Biometrics: Fingerprints, facial recognition or voice recognition
• USB Key: The user logs in using a USB token.
• Authentication Links: Enables a user to login without a password by providing their email address and receiving a link.
• SMS: Enables the user to login with SMS by sending them a code to confirm their identity.

WCAG also offers some optional steps you can take to make cognitive tests more accessible:

• Giving the user the option to choose between two different types of CAPTCHA at all times
• Not requiring authorized users to complete them
• Letting employees bypass them

Now let’s have a look at commonly used CAPTCHA methods and their issues in terms of accessibility:

1. Text CAPTCHA

This challenge presents to the user text in the form of an image that’s intentionally distorted and hard to see and asks them to enter the text in a form.

This is problematic to users with visual disabilities like partial or full blindness. Users with visual disturbances like severe astigmatism can also be negatively impacted by those challenges. Screen readers are also unable to process the text image because they don’t have an alt-text assigned to them by default which you can add with an alt

2. Audio CAPTCHA

This CAPTCHA challenge will play an audio with consecutive characters, letters or words and will ask the user to enter them in a form.

Users who are deaf cannot hear the audio being played making it impossible for them to solve the challenge and users with cognitive and learning disabilities will also have a hard time solving them. This can also be an issue for users in noisy environments where they cannot properly hear the audio.

It’s also proven that audio CAPTCHAs come with a heavier cognitive load to all humans, especially if the audio is highly distorted making them harder to solve for everyone.

3. Puzzle CAPTCHA

Puzzle CAPTCHAs are challenges based on logic where the user has to solve a logical problem to prove he’s not a bot. These can be questions such as, “What is 2×9?”, a spatial puzzle where you have to choose the right orientation of an object or a word puzzle where you have to fill in a missing word.

While screen readers can read questions aloud to visually disabled users, spatial puzzles will be harder for them to solve. Not everyone has the same cognitive capabilities, an individual with learning disabilities will find puzzles harder to solve.

4. Image CAPTCHA

This is a type of challenge where the user has to identify images such as identifying which image represents a dog or a bicycle.

Each user interprets and perceives images differently especially if the image is unclear. This is even more an issue for users with vision-related disabilities and cognitive processing disorders making these challenges nearly impossible for them to solve.

How To Solve Accessibility Issues with CAPTCHAs?

As you can see, whether it’s text, audio or puzzle CAPTCHAs, each one of them has downsides in terms of accessibility and aren’t fully inclusive to users. While you cannot make them fully accessible to every users, there are a couple ways you can make them more inclusive:

1. Offer Alternative CAPTCHA

Give your users the option of choosing the CAPTCHA method depending on their capabilities. Like being able to switch to an audio CAPTCHA if you’re visually impaired or an image CAPTCHA if you have a reading disability like dyslexia.

2. Add Alt-Text 

Adding alternative text to CAPTCHA challenges is a simple way we can make them accessible to screen reader users. Such as describing the purpose of non-text CAPTCHA while not giving away hints because that would defeat the purpose of the challenge.

3. Avoid Time Limited CAPTCHA

These can be annoying to every user, disabled users in general take more time than usual to complete tasks like filling forms and this will timeout the CAPTCHA making them to start over again.

4. Don’t use CAPTCHA

The easiest and best solution is to not use them at all If there’s no need. If you have a small ecommerce website with little traffic CAPTCHA will be more of an annoyance to your users than anything. If you really want to protect your websites from bots, use filters or an alternative bot mitigation method instead.

What Are Accessible CAPTCHA Alternatives?

While the best option for accessibility would be to not use them, in some cases you have to.

Like with any technology, CAPTCHA has evolved and we now have accessible alternatives available to us. While no CAPTCHA is 100% accessible, some are better than others.

Let’s have a look at two of the most accessible options available:

1. hCAPTCHA

hCAPTCHA offers two different types of verification methods one which is text-based and the other is a universal accessibility option which serves users with any kind of disabilities. hCAPTCHA is fully compliant with Section 508 and WCAG 2.1 AA out of the box so you don’t have to tweak anything. 

hCAPTCHA also comes with an accessibility token which can be used by users to skip CAPTCHAs as much as they want, to get access to this token you will have to sign up for the hCAPTCHA accessibility access with your email. This cookie will need to be refreshed every 24 hours through the hCAPTCHA sign up page.

2. reCAPTCHA v3

ReCAPTCHA was released back in 2007 and it evolved a lot, reCAPTCHA v1 asked user to read distorted text and type it in a box, reCAPTCHA v2 was about ticking a box that says “I’m not a robot” or give you an image or audio recognition challenge like asking you to tick all the boxes containing a boat. 

Unfortunately, Google’s reCAPTCHA v2 isn’t fully accessible to users with disabilities and as technology evolves so does bypassing methods used by criminals online. There are serious security issues with this second version of reCAPTCHA which enables cybercriminals to easily bypass these challenges with AI and in some cases outsource the reCAPTCHA challenge to human workers in CAPTCHA farms.

To solve those security loopholes and after listening to user feedback, Google released reCAPTCHA v3 in 2018 and it is to this date the most advanced CAPTCHA technology released by Google. What’s unique about this release is it runs in the background out of sight from the user, meaning there are no challenges to solve.

How Does Google ReCAPTCHA v3 Work?

reCAPTCHA v3 assigns a decimal score ranging from 0.0 to 1.0, 0.0 meaning it’s likely a bot and 1.0 meaning it’s likely a human.This score is assigned to users who visit your website and start interacting with it. It will then be used to decide whether the user is a human or a bot. This is a seamless process that doesn’t add friction to the user experience which is key for accessibility and it dramatically improves conversion rates.

You can have ReCAPTCHA v3 run in the background passively or bind it to elements like buttons, forms or any type of action users take on the page. It can also be implemented programmatically offering granular control over sensitive events like when a user logs in or when a user wants to reset his password.

How To Hide Google ReCAPTCHA v3 Badge?

The ReCAPTCHA badge is always shown on websites using it but what if you want to hide it?

Well, hiding it incorrectly can put you in hot water with Google because it violates Terms of Services. You are allowed to visually hide the widget, however, it is not permitted to remove it from the DOM.

Here’s how you can safely hide it in CSS:

.grecaptcha-badge { 
visibility: hidden; 
}

Note: Using display: none to hide the badge will disable spam checking and violate Google’s Terms of Service as it removes the element from the document. .

Google allows you to hide the badge as long the reCAPTCHA text branding is visible to the user as mentioned here. An effective way to preserve your current design without violating the Terms of Service is to insert this below code snippet under the form that is collecting information, protected by ReCAPTCHA.

This site is protected by reCAPTCHA and the Google

<a href="https: //policies.google.com/privacy">Privacy Policy</a> and
<a href="https://policies.google.com/terms">Terms of Service</a> apply.

Conclusion

Implementing CAPTCHA can be a headache, on one hand you have to protect your website from bots, spammers and cybercriminals and on the other you have to offer an inclusive and accessible experience to every user.

When implementing features such as CAPTCHAs on your website, it’s always best to gather as much data and feedback from your users, listen to their pain points and run A/B testing. This will help you go forward by optimizing your website and offering an optimal user experience. Reach out to us if you need help with CSS tricks and tips info@advancedbytez.com

Generally speaking you shouldn’t disable or hide interactive elements unless you really have to.

Disabling buttons is a common practice used across the web and there are mainly four reasons why it’s done:

1. Gating and controlling access to unauthorized parts of a website.
2. A process is currently loading after the user clicks a button.
3. Input issues, either missing or not valid.
4. Unavailability of an upcoming feature.

Each one of these cases conveys the same message: the button is currently unavailable. 

It does exactly what it’s intended to do, but we’re faced with accessibility and usability issues if not done correctly. Understanding how your users interact and use interactive elements like buttons is important for web accessibility. 

Why Are Disabled Buttons Bad For Accessibility?

1. They Confuse Users

Why isn’t the button working? Is it my internet connection? Why does this button look weird?

These are questions a user with cognitive or learning disabilities might ask himself when looking at a disabled button. With disabled buttons, because the rest of the interface is accessible, users may be led to think that there is a problem with their input, especially on mobile. Most of the disabled buttons found on the web don’t give any feedback on why they’re disabled which adds to the confusion. Users are left to find out what went wrong using their gut feeling.

Buttons usually have a call to action on them such as “Order” or “Send”, and that’s often what a user wants to do so they will try to click them and if it’s disabled it won’t do anything.

Making users think about your UI is always bad for usability because it adds a layer of difficulty to the task. A general rule in web usability is that tasks should be completed with as little effort as possible.

2. They’re hard to see

There are no contrast requirements for disabled elements in WCAG, which doesn’t mean they aren’t an accessibility issue and that you should ignore them. Disabled buttons are often grayed out or have muted colors, which in both cases are an issue for users with low vision and visual disabilities.

Even though this state is not subject to passing color contrast guidelines, the use of color (1.4.1) alone should not be the only means to convey information. Increase the contrast so that the style is substantially different from the non-disabled styles, even for color-blind users.

Text within a button should always be visible whether disabled or not to give context to the user. Use helpful button text that allows the user to identify that it is disabled and not a user error.

3. They’re invisible to assistive technology

Disabled buttons are usually invisible to assistive technologies such as screen readers and switches when pure CSS and Javascript techniques are used.

Users who rely on assistive technology won’t hear the state of the button indicating the presence of a disabled button that is conveyed visually. Read below to explore a few methods to make disabled button states accessible to assistive technology. 

How To Make Disabled Buttons Accessible?

Now let’s have a look at how you can make disabled buttons more accessible to your users:

1. Use aria-disabled

Setting aria-disabled to “true” will allow the button to receive tab focus, but indicate to screen readers that the button is inactive, announcing its disabled state. If the button using aria-disabled, is left in the DOM order intentionally, the styling that is used needs to pass contrast minimum as we noted earlier. 

Example code for using aria-disabled attribute and allowing the control to receive focus:

<button type=”submit” aria-disabled=”true”> Add to Cart</button>

If you want to remove it from the tab order, a negative tabindex can be used and this will replicate the behavior of the control when the HTML disabled attribute is used. 

<button type=”submit” aria-disabled=”true” tabindex=”-1”> Add to Cart</button>

Another use case for using the aria disabled attribute is if a custom control is developed using <div> or <span>. These non-HTML elements do not support the disabled attribute even with a role=”button”, and the aria equivalent should be used to disable the control. 

<div role="button" aria-disabled="true" tabindex="-1">Edit</div>

Making sure that your focus order is consistent is important for UX and aria-disabled does exactly that by keeping interactive elements discoverable and disabled at the same time so you don’t have to remove them completely. This is important for submitting buttons in forms and items temporarily unavailable to a user. An example of this instance is when buttons are disabled due to a lack of validation or lack of. It’s not ideal UX, and if this design pattern must be used, provide an error message explaining what went wrong.

The <disabled> HTML attribute on the other hand disables the button completely by removing it from the tab order, however it will be announced as “unavailable” to assistive technology in browse mode. 

<button type="button" disabled>Click Me!</button>

Using aria-disabled will still allow a tab stop on the elements, it may be potentially confusing for keyboard-only users.

There are pros and cons to using both methods, and using either the HTML or ARIA equivalent of the disabled attribute must be chosen with care. 

2. Use of visual indicators

A good design practice we tested on user groups is the use of the CSS property cursor: not-allowed for visual users with cognitive impairments. Using this cursor property on a disabled button will provide an additional visual indicator that the button is inactive. 

3. Show Help Text

Showing visible text around the disabled button is an easy and straightforward way to make them more accessible and gives context to the user on why a button is currently unavailable, similar to form instructions. An example of this while filling out a form can have an instruction above the submit button that reads, “all fields in this form must be filled out before being able to submit it”, or similar. 

When using this method it is important to style the help text differently to make it perceivable and visually distinct from the button. By using different fonts, colors or by adding a border to the help text.

4. Don’t Mute Colors

DIsabled buttons often use bad contrast or muted colors that make them less visible to users like those with low vision.

One way to solve this is to avoid using default colors when it comes to disabled buttons. Your design system should have a provision to include a design for disabled buttons that is different from the primary and secondary buttons, such that they are distinct from the more frequently used colors and differentiate them at the same time. You can test if the color is WCAG-compliant and visible by using a contrast checker.

5. Don’t Disable Buttons

The easiest solution would be to avoid using the disabled state for buttons at all, but in case you have to use them make sure to follow accessibility guidelines as much as possible and the tips I’ve mentioned above to provide a better user experience.

Conclusion

Generally speaking, it is always better not to disable buttons if you can because this affects user experience in a negative way.

Especially with disabled users, but if you have to, there are ways you can do it in an accessible way as we’ve seen in this article.

Keep in mind that there’s no one size fits all solution when it comes to making disabled buttons accessible. Testing different solutions, techniques and using user feedback is always better for optimal results.

Thousands of businesses every year end up with lawsuits under the American with Disabilities Act (ADA) and some end up bankrupt because of the heavy financial burden.

There are multiple reasons why being ADA compliant is not only good for your business but for your users which we will dive into in this article by answering key questions around ADA and how it relates to web accessibility.

ADA In a Nutshell 

ADA is short for American with Disabilities Act, a civil rights law applied in several areas in the public space, such as:

• Transportation
• Employment
• Public Accommodation
• Communication
• State and local government services
• Businesses offering public services

This also includes online businesses like Shopify stores or any business running a website offering a service to the public, pair or not.

ADA’s Goal

The ADA protects people with disabilities against discrimination in all areas of public life including online spaces by taking proactive measures in accommodation, like making sure that communication is as effective with everyone disabled or not. It protects them the same way civil rights laws protect individuals based on sex, race and religion.

Public businesses must provide full and equal enjoyment of their services to people with disabilities also called “public accommodations”. They must also provide appropriate communication for everyone to make sure that information is communicated in an effective way which falls into “auxiliary aids”. This can be interpreters, notetakers, captions in videos or assistive listening devices (ALDs).

Who’s Considered Disabled According to ADA?

To put it simply, anyone who’s limited in one or more important life activities falls under the disabled umbrella. And these are subdivided into three main groups of individuals:

• Someone who’s physically or mentally impaired (Amputee, Dyslexic)
• Someone who’s recovering from an illness or injury (Cancer, Broken Limb)
• Someone who’s perceived as impaired (Bodily Scars, Severe Burns)

The ADA guarantees protection and coverage for individuals falling into any of these groups. Which means that they don’t have to apply for anything, they are protected by default because it is a law, not a benefit program.

How Does ADA Apply to Web Accessibility?

The ADA doesn’t turn a blind eye to the online space when it comes to accessibility.

Since it doesn’t have technical standards when it comes to web accessibility, businesses and governmental institutions have a lot of flexibility when it comes to being compliant online. 

While this can be great news, don’t be fooled into thinking it’s something you can be lenient about because failing to be ADA-compliant can hurt your wallet.

The DOJ requires websites to be reasonably accessible to individuals with disabilities, one way this can be done is by following the Web Content Accessibility Guidelines (WCAG) which is a standard in terms of web accessibility. 

The minimum required to have is WCAG Level AA which is the Information and Communications standard.

The Dangers of Not Being ADA-Compliant?

Lawsuit

Thousands of companies in the US end up with lawsuits and settlements every year with their customers. 

Which ends up being costly, ADA penalties start from $96,382 for a first time violation and can go up to $192,768 if you end up violating more than once. In the worst case, this can lead to bankruptcy.

Brand Image

Brand image plays a major role when customers make buying decisions online and web accessibility is a huge part of it. Running a non-accessible website can cause reputational damage, making you lose revenue.

Lost Opportunities

Disabled individuals make up a big segment of online users and failing to accommodate them can make you lose revenue and have less visibility in this segment of the market.

In a study called “The Internet is unavailable” done by Nucleus Research, US e-commerce retailers running non-accessible websites have lost close to $6.9 billion dollars to their competitors annually.

Conclusion

Web accessibility and the ADA go hand in hand when it comes to making the Web accessible; failing to do so comes with various risks and consequences.

Gone are the days when web accessibility was a mere choice, compliance is the norm today across all industries, it’s crucial for your online business and your customers. The smart and obvious thing to do is to make sure that your website is ADA-compliant.

Ensure your website meets all ADA compliance standards and avoid potential risks with Advancedbytez’s expert Web Accessibility and Audit Service. Let’s make your site accessible to everyone.

Forms can be a major cause of concern for disabled users. Issues such as not being able to navigate input fields using the <TAB> key or form error messages not being perceivable or understandable are quite common on websites.

Making sure that error messages on forms are accessible is crucial for UX and ease of use. Failing to do so can result in a user being frustrated and leaving a website which is bad for business.

Making users aware and offering appropriate information to correct an input error are part of the WCAG 3.3.1 and WCAG 3.3.3 Success Criterion respectively. 

We will be looking into a client-side solution in JavaScript at the end to validate a form, bring focus to a field containing an error and read it out loud to a screen reader.

But first let’s have a look at what an accessible form error consists of.

What is An Accessible Form Error Message?

Making form error messages accessible is important for UX. This enables users to interact with a form effectively, helping them understand input errors and solve them whenever they happen. This is useful especially for those with visual disabilities.

Here are the key features an accessible form error should have:

Clear And Descriptive

The input error message should be explicit, in plain language and explain precisely what went wrong and instruct the user how to correct the issue. 

Usage of technical jargon or ambiguous terms should be avoided to not confuse users. This helps in making UX seamless and easy to understand for everyone.

Visible With Consistent Formatting

It should be visible to the user, associated with the form field that has an issue and use consistent formatting across the website. This helps in keeping the interface clean and comprehensible.

Aria Attributes

It should use the Aria attributes aria-live to alert assistive technology when an error occurs and aria-describedby to offer helpful form hints to screen reader users.

Focus Management

The browser should bring focus to the first form field that has an issue after the form was submitted. This helps users using assistive technology navigate to the field and correct it.

Color Contrast

It should have enough color contrast between the error message and its background. Enabling users with visual disabilities such as color blindness to differentiate the error messages from the rest of the website content.

Form Error Identification, Correction And Accessibility

After a user submits a form that contains an error, the error message provided must be presented in a certain way to be considered accessible:

1. Identify fields that contain errors: Making the user aware that there’s an issue with a form being submitted is the first step in solving it and this starts by highlighting the fields that are of concern. This is helpful to users who have a visual disability by making it easier to locate fields that contain an error.

2. Provide suggestions to correct the errors: Some users need more assistance in solving form errors so giving tips on how to solve them can be quite helpful. This can also be a time saver for users with or without disabilities.

3. Expose the information properly to assistive technology: This will help screen reader users understand what went wrong, one way this can be done is by setting aria-invalid=”true” whenever a field is invalid which will make screen readers identify the field as invalid and in need of attention. Using appropriate ARIA labels is an easy way to make forms more accessible to assistive technology.

There are multiple ways we can present an error message to a user, we’ll keep it simple and focus only on inline error messages since they’re commonly used across the web.

What is an Inline Error Message?

An inline error message is one that appears close to the field containing an error, usually on top or the side of the input field. The error message should generally let the user know what went wrong and how to resolve it.

The key advantage of this type of error message is that they appear close to the field within context, dragging the user’s attention where the error is located.

Not all users have the same level of understanding of the English language, users with cognitive and learning disabilities often have a reduced vocabulary making it harder to learn and understand new terms. Which is why using clear wording in plain language is a crucial aspect of an accessible inline error message. This allows the error message to be understood by a broader audience.

Like with any type of error message, making inline error messages easily distinguishable from the rest of the form by having enough color contrast between the message and the background is important when implementing this method. This saves the user time when searching for the error within the form.

Here’s an example of a simple Username and Password form with an accessible error message which alerts the user that the “Username cannot be empty”:

On the other hand if the form contains multiple input errors, having the user scroll or <TAB> through dozens of fields can be frustrating especially for disabled users. In which case focus management comes into play, you can read more about it here.

Generate An Accessible Inline Form Error Message Using JavaScript

Let’s have a look and break down an example where screen readers read an error message whenever a field is empty.

Username And Password Form

Here’s the HTML of our Username and Password form:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Accessible Form with Error Messages</title>
  <style>
    .error-message {
      color: red;
      font-size: 14px;
      margin-top: 5px;
    }
  </style>
</head>
<body>

<form onsubmit="validateForm(event)">    
   <label for="username">Username: </label>    
     <input type="text" id="username" name="username" aria describedby="usernameError" aria-invalid="false" “required”>    
  <span id="usernameError" class="error-message" role="alert">  
  </span><br>    
  <label for="password">Password:</label>    
    <input type="password" id="password" name="password" aria-describedby="passwordError" aria-invalid="false" “required”>    
  <span id="passwordError" class="error-message" role="alert"> 
  </span><br>    
   <button type="submit">Submit</button>  
</form>

In the example above, our Username and Password input fields are both using the aria-describedby and aria-invalid ARIA attributes.

These attributes are crucial for screen readers when dealing with interactive elements such as input fields:

aria-describedby="passwordError" aria-invalid="false"

• aria-describedby is used to reference the error message to the input field for screen readers. We do this by using the ID of the error message text, wrapped in a <span> in our example above, and referencing it to the aria-describedby property on the input field.

• aria-invalid is used to indicate to screen readers whether the value entered into the input field is in a format that is going to be accepted by the form. This serves as the first level of client-side validation and is used in conjunction with aria-describedby to provide a user with more information about the error and how to fix it. It is important to note that aria-invalid must be set to a value of “false” before the form is submitted, and must be toggled to “true” via javascript after submission if the entry is invalid. 

Some may argue that it may not be necessary to include the aria-invalid attribute if a visible error message is tied to the form and it leads to code bloat. It helps provide additional context to a user and in my opinion a best practice of form validation. 

JavaScript Form Validation

Here’s the JavaScript code that will validate the form and check whether a field is empty:

<script>
    function validateForm(event) {
      event.preventDefault();

      // Reset previous error messages and styles
      document.getElementById('usernameError').textContent = '';
      document.getElementById('username').setAttribute('aria-invalid', 'false');
      document.getElementById('passwordError').textContent = '';
      document.getElementById('password').setAttribute('aria-invalid', 'false');

      // Get form values
      var username = document.getElementById('username').value;
      var password = document.getElementById('password').value;

      // Validate username
      if (username.trim() === '') {
        document.getElementById('usernameError').textContent = 'Username cannot be empty';
        document.getElementById('username').setAttribute('aria-invalid', 'true');
      }

      // Validate password
      if (password.trim() === '') {
        document.getElementById('passwordError').textContent = 'Password cannot be empty';
        document.getElementById('password').setAttribute('aria-invalid', 'true');
      }

      // Move focus to the first field with an error
      var firstErrorField = document.querySelector('[aria-invalid="true"]');
      if (firstErrorField) {
        firstErrorField.focus();
      }

      // If there are no errors, proceed with form submission
      if (username && password) {
        alert('Form submitted successfully!');
      }
    }
  </script>

Here’s How The Script Works:

1. If there was already an error message displayed, it will reset it and set the aria-invalid attribute back to “false”.
2. Retrieves the values within the Username and Password field.
3. Validates Username and Password by checking if they’re empty, if they are it generates an error message and sets the aria-invalid attribute to “true” indicating to screen readers that the input field needs attention.
4. Moves focus to the first field containing an error.
5. On the other hand, if the Username and Password aren’t empty it alerts that the form was submitted successfully. 

Conclusion

Form error messages are often left unchecked for accessibility issues or if any improvements can be made in how they’re presented to users and screen readers. 

Failing to do so results in a bad user experience especially for users with visual or cognitive disabilities who are more prone to making errors when filling a form. Especially forms with multiple fields and different types of inputs.

This is where JavaScript comes in handy for running validation checks, bringing focus to input fields containing errors and changing their ARIA attributes on the fly so that they can be detected by assistive technology.

It’s easy to use pre-built libraries today to speed up development. However, they don’t always cater to accessibility. Don’t be fooled by the random aria attributes sprinkled throughout the code. If you need expert developer consulting on how to make accessible components, reach out to us or write to us at info@advancedbytez.com. 

Happy coding!

Keyboard accessibility is a crucial aspect of web accessibility. A lot of internet users surf the web and navigate web pages using only their keyboard. This is done either for convenience, personal preference or due to a motor disability; making sure that your website is keyboard navigable benefits a wide range of users.

There are multiple ways you can optimize your websites for accessibility, one simple way is by implementing event listeners using JavaScript. This provides a number of ways to present, update, and enhance content on a web page on the fly without having the user refresh the page, which is especially useful to users using assistive technology.

Interactive Elements

Assistive technologies rely on interactive elements(i.e forms, buttons) to understand and interact with elements on a web page.

Which implies that any discrepancy in how interactive elements are presented can negatively affect users and assistive technologies such as screen readers and speech-input software. 

Incorrect element properties can also cause issues with assistive technologies because they use attributes such as Name, Role and Value of UI elements to parse controls and structure properly. This is also part of the WCAG criterion WCAG 4.1.2 Name, Role, Value.

Focus Management

Most of the time you don’t need custom focus management for simple native HTML elements such as , the <button> tag for buttons, the <input> tag for user input and the anchor <a> tag for links. Native HTML elements are accessible out-of-the-box and have predefined roles and global tab index attributes of “0”. This allows the elements to be focusable with the tab key and establish a sequential focus order. 

The only time focus order can be an issue is when you’re building custom components or designs that require manual focus management. In this case, focus order can end up being inconsistent with the design and sequential logic of the content on the website. An example of such a design pattern is the use of modal popup dialogs, when activated require the focus to be trapped inside the overlay and not move to the elements in the background. 

Tabindex

In some cases, you might want to apply focus to an element that is not focusable by default. You can do that by using the tabindex attribute which makes unfocusable elements focusable. Remember that you shouldn’t be using tabindex on elements that don’t need it such as buttons.

There are three methods you can use with tabindex:

• tabindex= ”0” allows custom elements other native HTML elements  to receive keyboard focus.<div> and < span > are examples of such elements that may require a tabindex=”0”. It works by placing the element in the logical navigation flow and doesn’t change the tab order.

• tabindex= “-1” will remove the element from the navigation order, meaning that you won’t be able to access it via <TAB>, but can be focusable using JavaScript. This is useful when creating accessible interactive widgets in JavaScript. Take the example of the modal again. The button that activates the modal should have tabindex=”0” but the modal itself will have a tabindex=”-1” to remove it from the tab order and prevent a user from tabbing through the contents of the modal that isn’t active yet.

• tabindex= ”1” and above will be the first elements to be focused starting from one. This would be useful if you wanted a focusable element removed from the tab sequence. Keep in mind that using a positive integer when using tabindex is not advisable and bad practice for accessibility. This can break the expected tab order and create a confusing user experience when tabbing across interactive elements on your website, especially if content is dynamically added to the website.

Tab Order

Users who are unable to navigate the web using a mouse or a trackpad, will often rely on the tab key. Making it one of the most important keys on a keyboard for users with motor disabilities. The Tab key is often used to navigate through focusable elements like forms and buttons on a web page. 

The HTML DOM which regroups all the properties, methods and events of HTML elements on a web page can end up having a broken tab order if focusable elements aren’t in a correct order relative to how a website is designed.

Because the Tab key will jump to Interactive elements in the order they appear in the DOM, not how they appear visually. You can easily solve that by having your source code match the visual hierarchy of your website front-end design. 

The default Tab order should be logical, intuitive and follow the visual flow of the web page. Similar to a book, it should be going from left to right, top to bottom.

Focus Styling

How focus is styled is as important as focus order, it doesn’t matter how good focus is managed if the user doesn’t know which button or link is currently being selected as he tabs through the page. 

Modern web browsers have different visual stylings for how focusable elements are selected, some more visible than others. To avoid having issues with styling, within your stylesheet you should avoid setting the focus outline to none or 0, because this will override the browser’s default focus indicator if you’re using a custom theme.

How To Improve Accessibility Using JavaScript?

We can improve accessibility using HTML and CSS, they can do the job most of the time. But when dealing with more complex designs and components then JavaScript is the solution.

JavaScript, unlike HTML and CSS, can trigger events based on the user’s actions.

Let’s have a look at some useful methods we can use in JavaScript:

Focus()

This method allows us to bring the keyboard focus to an element that’s either tabbable or focusable. This is a quite useful method for keyboard accessibility.

Here’s an example where focus is set to the input as soon as the page loads:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Focus Example</title>
</head>
<body>
    // Input field
  <input type="text" id="myInput" placeholder="Type here">

  <script>
    // Focus on input when page loads
    document.getElementById('myInput').focus();
  </script>

</body>
</html>

Here when the page loads the .focus() selector is used to focus on the input field called myInput.

OnKeyDown()

The OnKeyDown() method will listen to whether a key was pressed or not, in this case we will be enabling a user to click a button with either the <space> or <enter> key.

A common practice we see in today’s web development practices is to style a link to look like a button.

I am a power keyboard user and expect that if I come across a button, it will be activated with either the Enter or Space key. If it is actually a link made to look like a button and I use my Space key to activate it, there is a page scroll. This raises important accessibility issues when a user expects a known interaction to take place and the opposite happens. This can be fixed by adding a keydown event to the link to allow it to be fired with the Space key. 

Let’s have a look at an example:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Keydown Example</title>
</head>
<body>

  <button id="MyButton" onclick="PerformAction()" onkeydown="HandleKeyDown()">
    Click me, press space or enter!
  </button>

  <script>
    function PerformAction() {
      alert('Button clicked!');
    }

    function HandleKeyDown(event) {
      // Check if pressed key is Enter (key code 13) or Space (key code 32)
      if (event.key === 'Enter' || event.key === ' ' || event.keyCode === 13 || event.keyCode === 32) {
        PerformAction();
      }
    }
  </script>

</body>
</html>

When the button is brought into focus and the <space> or <enter> key are pressed the HandleKeyDown() function is called through the OnKeyDown() method.

The HandleKeyDown() method will check if the <enter> or <space> key were pressed using their key code which are 13 and 32 respectively.

It then calls the PerformAction() function which triggers an alert box.

SetAttribute()

This method is used to set attributes to elements, while not directly related to focus and accessibility it can be used to enhance user experience, such as dynamically changing attribute values of elements relative to their change in states. 

Let’s have a look at an example where the SetAttribute() method is used to toggle the aria-expanded attribute of a dropdown menu:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Dropdown Menu with aria-expanded</title>
  <style>
    .dropdown {
      position: relative;
      display: inline-block;
    }

    .dropdown-content {
      display: none;
      position: absolute;
      background-color: #f9f9f9;
      box-shadow: 0 2px 5px rgba(0, 0, 0, 0.1);
      padding: 8px;
      z-index: 1;
    }

    .dropdown:hover .dropdown-content {
      display: block;
    }
  </style>
</head>
<body>

  <div class="dropdown">
    <button id="dropdownButton" aria-expanded="false" onclick="toggleDropdown()">
      Toggle Dropdown
    </button>
    <div class="dropdown-content" aria-labelledby="dropdownButton">
      <a href="#">Option 1</a>
      <a href="#">Option 2</a>
      <a href="#">Option 3</a>
    </div>
  </div>

  <script>
    function toggleDropdown() {
      var dropdownContent = document.querySelector('.dropdown-content');
      var dropdownButton = document.getElementById('dropdownButton');

      // Toggle visibility of the dropdown content
      if (dropdownContent.style.display === 'none' || dropdownContent.style.display === '') {
        dropdownContent.style.display = 'block';
        dropdownButton.setAttribute('aria-expanded', 'true');
      } else {
        dropdownContent.style.display = 'none';
        dropdownButton.setAttribute('aria-expanded', 'false');
      }
    }
  </script>

</body>
</html>

The toggle button’s aria-expanded attribute is set to false by default when the menu is collapsed. When it’s clicked the toggleDropdown() function is called using the OnClick() method.

The toggleDropDown() function expands the dropdown and changes the value of aria-expanded to ‘true’.

When it’s clicked a second time, the drop-down collapses and the aria-expanded attribute is set to ‘false’.

Conclusion

Keyboard accessibility is still an issue today as websites become increasingly complex in terms of features and designs which are often not optimized for keyboard accessibility, navigation and focus management.

And this requires us to devise ways to solve those accessibility issues using JavaScript’s event handlers and various other techniques. Allowing us to detect a user’s actions on a web page and perform certain modifications enhancing focus, navigation and accessibility.

Fonts and web accessibility go hand in hand, other than font and background contrast ratio. Font sizing is as important for users with visual impairments and for user experience. Optimizing font size for accessibility will result in a more engaging content experience for all users.

Generally speaking, an accessible font is one that does not slow down the reader. The reading experience should be seamless, letters should be easily distinguishable from one another and easy on the eyes to avoid eye strain.

It has to be easy to see, read and understand by everyone, disabled or not.

Minimum Font Size Requirement

While there aren’t any minimum font size requirements according to the Web Content Accessibility Guidelines (WCAG), it is recommended to use a font size of at least 16px. Going too small or too large with website fonts can lead to accessibility issues and negative user experience. WCAG recommends that website users be able to zoom in on text to make it 200% larger without any loss in clarity.

Being able to reflow content on a web page and resize text are both important criteria according to WCAG, for users with low vision.

A web browser default font size is set at 16px, people with cognitive or visual disabilities will often increase the default font size to make text legible using the web browser zoom feature or change the default font size directly in the web browser settings. To ensure that fonts are resized correctly, it is the web developer’s job to use accessible coding practices. So that it does not interfere with the way the browser displays text.

Why Should You Use Relative Scaling Units In Font Sizing?

One of the easiest ways to make sure that textual content is resized according to the user’s preferences is to use relative scaling units instead of absolute ones. Fonts on websites using relative scaling units will increase according to the browser’s default font size, while fonts on websites using absolute units won’t.

In web design, we commonly use pixels(px) when sizing elements such as fonts. Using px is straightforward and sizes fonts exactly how we want it. However the issue with using absolute units such as px is that they are non-scalable. Meaning that whenever the value of another element changes, absolute units don’t. They are fixed and stay the same irrespective of the web browser settings.

Which is bad news if absolute units are used for font sizing, when a user increases its browser default font size or uses the web browser zoom feature, fonts using px stay the same and are not affected.

The alternative is to use relative scaling units such as em and rem, which can solve that issue and offer an adaptable, accessible and responsive font sizing.

Another reason why relative scaling units are important is the wide variety of devices used to access websites. All those devices render web pages differently and using relative units will help make sure that texts are rendered at a readable size.

What is an EM Unit?

em is a unit relative to the nearest parent element. It enables you to adjust the font size of a relative element to the font size of a parent element. When the font size of the parent element changes, the font size of the relative element changes as well.

For example, if the body element font size is set to 16px, then 1em = 16px. If a paragraph element is nested inside the body with a font size of 0.5em, it becomes half the font size of the body element, 0.5em = 8px.

Here’s a code example of how em units work when used for font sizing:

<!DOCTYPE html>
<html>
<head>
    <style>
        /* Set the base font size for body element */

        body {
            font-size: 18px;
        }

        h1 {
            font-size: 2em; <- This will be 36px (2*18px)
        }

    </style>
</head>
</html>

As we see in the example above, the <body> tag is set at 18px and the <h1> tag is set at 2em.

Here 1em equals 18px so text in the <h1> tag will be sized at 36px.

If font size is not specified in the <body> it defaults to the browser’s default font size, which is 16px.

Compounding issue with CSS EM units

Using em units gives a more modular control over specific parts of a web page, which is great for responsive and adaptable websites. But we can get into issues if we keep nesting elements inside one another. This will lead to em units compounding and make the text unintendedly larger.

Here’s an example where divs are nested within each other which compounds the em units value and makes the text larger:

.primary {
  font-size: 15px;
}
.secondary {
  font-size: 2em;
}

---

<div class="primary">
  I'm 15px
  <div class="secondary">
  I'm 30px, it's all good.
    <div class="secondary">
    I'm 60px, what's going on?!
      <div class="secondary">
      I'm 120px, this is too big!
      </div>
    </div>
  </div>
</div>

Here’s the output of the code above:

I’m 15px

I’m 30px, it’s all good.

I’m 60px, what’s going on?!

I’m 120px, this is too big!

The solution to em units compounding when nesting elements is to use rem units instead.

What Is A REM Unit?

rem is a unit relative to the root element which is the <html> element on a web page. When font size is not specified, it defaults to 16px. Similarly to em units, 1rem = 16px and 2rem = 32px. They are more predictable in how they size elements on a web page.

Unlike em units, rem units are relative to the root element which makes them impossible to compound.

Here’s a code example of how rem units work when used for font sizing:

<!DOCTYPE html>
<html>
<head>
    <style>
        /* Set the base font size for html element */
        html {
            font-size: 18px;
        }

        body {
            font-size: 1rem; <- This will be 18px (1*16px)
        }

    </style>
</head>
</html>

As we can see, rem and em units are no different in how they function when used for font sizing. Only difference being em units will relate to its closest parent and rem units will relate to the <html> or root element.

None is better than the other, em is great for modularity when we want certain parts of the web page to size fonts in a particular way. While rem is more predictable in the way it sizes fonts but gives you less flexibility and modularity.

Conclusion

Regular text, images or text-based form controls not resizing upon zooming the viewport to 200% is a common WCAG violation we encountered during our manual audits. Making sure that web pages size fonts correctly when users zoom or increase font size is important for web accessibility and responsive web design. 

And this starts with web developers and designers using accessible coding practices like replacing absolute units with relative sizing units when designing websites and setting font size. 
Write to us at info@advancedbytez.com and talk to one of our engineers if you need help conducting a manually accessible audit of your web or mobile application.