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. 

Button with a default mouse pointer cursor on hover, next to a greyed-out disabled button with a cursor not-allowed mouse on hover

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:

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:

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.
  1. 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.
  1. 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"

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:

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.

Text is the most present and distinctive visual element on a web page and it often falls behind in terms of accessibility. 

Web Accessibility isn’t only about adding alt-text to images or having the right design layout. Small details such as the font and typeface used on a website can make or break user experience.

Choosing the right font is important for text legibility and readability. Not only does it help the reader distinguish individual characters and words, it also makes the reading experience pleasurable and easier on the eyes of the reader.

Accessible fonts make texts easy to read and understand to users with visual and cognitive disabilities, such as loss of vision, color blindness and dyslexia

There are approximately 32 million Americans living with impaired vision, and that number keeps rising as the population grows older and experiences more vision-related diseases.

Taking in consideration how a visually impaired audience experiences content on your website is important in this day and age.

Choosing An Accessible Font

Fonts come in multitudes of shapes, sizes and colors, and not all of them were designed for web accessibility.

An accessible font typography is one that is legible, clear and understandable to the wider audience disabled or not. Generally speaking, It should not slow down the reading speed of a website visitor.

Avoid using decorative fonts such as hand-written, cursive or custom made. When choosing an inclusive font it is important to choose one that is simple and unembellished.

Here are some key features of an accessible font:

Here are some examples of accessible fonts:

Keep in mind that when choosing an accessible font it is important to consider how it will look on different displays and resolutions such as a tablet or phone. Some fonts are easier to read on bigger displays than smaller ones. And the font should be optimized for mobile viewports and screen readers.

Displaying text with images is generally not recommended, firstly because screen readers are unable to read aloud text on images, and secondly when those images are scaled for different resolutions the quality deteriorates making it harder to read.

Using a smaller font size isn’t recommended if you’re planning on making your website accessible. This can cause eye strain and give a cluttered look, resulting in a negative user experience. You shouldn’t make your font size too big either, opting for a medium sized font is advisable.

Running A/B tests and trying different font sizes across web pages is another great way to find the optimal font size for conversion by tracking analytics and user feedback.

Scaling Accessible Fonts with Em and Rem Units In CSS

According to the Web Content Accessibility Guidelines (WCAG) it is recommended to use relative font sizes instead of absolute when designing a website. This can be done using CSS em and rem units when setting units of size, both are relative and scalable units.

While rem units are easier to work with and more predictable in general, since they follow the root element in terms of font size. It lacks flexibility if we need to only scale and control a certain area of a web page.

em on the other hand is more modular and offers detailed control over specific areas of a web page since it follows its nearest parent font size.

em and rem units offer more flexibility when modifying the visual representation of a web page. 

They both have their pros and cons when it comes to scaling font size on a webpage.

The Benefits Of Accessible Fonts

Most of the information found online is conveyed through text, and this is important especially if you’re selling a product or offering a service to your customers.

The value proposition and messaging of your business has to be clearly understood by your customers and this starts with an accessible font.

Inclusivity with your content also means more potential customers since you’re targeting an underrepresented and often untapped segment of the market. This also makes website visitors satisfied and increases browsing sessions which is tracked by Google Search when assessing for SEO score and performance. Conversion and engagement rate is also significantly higher with accessible web pages.

Not being inclusive with your textual content puts you at risk of losing brand trust and endangers your reputation. And this translates into lower customer conversion rate and sales.

Using accessible fonts is also part of the Americans with Disability Act (ADA) compliance guidelines, and not following them puts your business at risk of a lawsuit and being sued for an ADA violation which can go up to $75,000 for the first violation.

Conclusion

Accessible fonts play a crucial role in the digital accessibility landscape. It ensures that everyone experiences content the same way without any barriers in readability and legibility, disabled or not. From choosing a clear and legible font to choosing the right font size, both are important factors in web accessibility.

Opting for an accessibility font benefits businesses and website users alike, by creating an inclusive and comfortable digital environment for both parties.

Shopify has the largest eCommerce market share in the USA with millions of buyers and sellers using the platform every single day. As of writing this, Shopify sites fall behind in terms of accessibility. Shopify themes are not fully ADA-compliant. Making them hard to use by people living with disabilities.

Shopify websites are not ADA-compliant by design. They often lack core features of an accessible website, such as being keyboard accessible. Shopify delegates the matter to the owner of the website, since each jurisdiction has its own laws and regulations related to web accessibility.

The closest you can get to meet ADA compliance are Shopify’s free OS 2.0 themes, though they are not fully ADA compliant. The good news is Shopify’s Checkout went through a full audit and meets WCAG 2.1 AA requirements, but Shopify themes are far from it.

Shopify does offer some guidance in making themes more accessible, but it doesn’t solve the main issue. Website owners need to make those changes and adjustments themselves; not everyone is technically capable. Which leaves millions of Shopify sites inaccessible to the disabled and impaired, especially those built by third parties.

This puts business owners using Shopify in a vulnerable position financially, by the threat of getting sued for ADA violations and losing millions in sales.

The Benefits Of Having Your Shopify Website ADA Compliant

More Profitable

An ADA compliant Shopify website means a better reach and a wider audience. Approximately 42.5 million Americans are living with a disability, facing limitations with inaccessible websites and web content.

Having your Shopify website ADA compliant benefits you and your customers. It opens your Shopify business to an underserved market that otherwise wouldn’t be able to use your website, and you would be missing out on business.

Every year, businesses lose billions from having inaccessible eCommerce websites, losing customers and their reputation. In 2021 alone, retailers expectedly lost $828 million due to having inaccessible websites. 

Being ADA compliant can be a great marketing feature for your brand, promoting it as accessible and ADA compliant will definitely make your Shopify website stand out and attract more clicks. Today, a brand is everything, customers want to do business with inclusive brands that take their customers seriously. Failing to be an ADA compliant eCommerce website can result in lower sales and a damaged brand reputation.

Large retailers like Amazon are spending millions to make their websites accessible and have dedicated accessibility teams. Which isn’t always the case with small to medium retailers using Shopify websites to sell online, most of them ignore the legal requirements of web accessibility and some aren’t aware that it’s a problem on their Shopify site. Making them vulnerable to hefty ADA lawsuits which can bankrupt their online business.

Ultimately, making your Shopify website accessible translates into a better experience for your customers and more money for you.

3 Best Practices To Make Your Shopify Website ADA Compliant

Here are some best practices that you can implement today on your Shopify website.

1. Images

Making sure that images on your Shopify websites are responsive is important for a smoothly running and fast website load time. It also helps us avoid layout shifts on web pages which can negatively affect user experience.

This also includes icons, when displaying icons on your website you should preferably use them in SVG format. Which is a format for vector graphics, enabling us to display icons at any scale without image distortion. Something which raster images like JPG and PNG cannot do.

Unfortunately, not all images can be in SVG format especially if your initial picture was in raster format. The solution is to use Shopify’s liquid template language image_url and image_tag filters.

image_url is how we generate images using Shopify’s image API which are sent from Shopify’s CDN. Using it we can resize, crop, add padding and generate different file formats.

Older browsers display images differently from modern browsers which is where image_url comes in handy. It will automatically generate the right size and format depending on the client’s browser and at the same time load those images in the CDN offering a better load speed. 

Image_tag will generate the HTML <img> tag when given an image URL and the markups needed such as srcset, sizes and much more to display responsive images on all devices.

Here’s a plain example of using image_url and image_tag in liquid template language:

{% assign image_url = 'Assigning_Your_Image_Name.jpg' | image_url: 'medium' %}

{{ image_url | image_tag: alt: 'Image alt text goes here' }}

And here’s the resulting <img> tag from the query:

<img src="//cdn.shopify.com/s/files/1/123/456/products/example-image_medium.jpg" alt="Image alt text">

2. Pricing

Pricing can be displayed in many ways on a Shopify website, with or without decimals and even using HTML superscripts for dollar cents.

This makes it difficult for screen readers to make sense of all the different ways pricing is displayed on Shopify sites. Especially if different HTML tags are used for displaying a single price such as the case with <sup> for superscripts.

One way we can solve that is by simply hiding the price value from the user in a second <span> which screen readers will read. While the first <span> is shown visually to the user but hidden from screen readers.

Here’s an example using HTML <sup> tag for displaying superscript:

<span id="productPrice">
	<span aria-hidden="true">199<sup>99</sup></span>
	<span class="visually-hidden">$199.99</span>
</span>

By doing so you can display the price in any way you like, as long the first span is hidden from screen readers using aria-hidden=true.

3. Forms

Forms are widely used across Shopify sites, for email subscriptions, comment sections, product reviews and at checkouts. Adding form errors is a great way to make your website more accessible and ADA compliant. 

One easy way to do that is by using Shopify’s liquid template form.errors to check for validation issues with forms and display an error message.

Here’s an example with an email input field:

<html>
<head>
    <title>Email Form with Liquid Errors</title>
</head>
<body>
    <h1>Contact Us</h1>
    <p>Please fill out the form below to get in touch.</p>

    <form action="/contact" method="post">
        <label for="email">Email:</label>
        <input type="email" id="email"
name="contact[email]" value="{{ form.email }}" required>

        <br>
        <-- Display Form Error -->
        {% if form.errors %}
            <ul style="color: red;">
                {% for error in form.errors %}
                    <li>{{ error.message }}</li>
                {% endfor %}
            </ul>
        {% endif %}
        <br>

        <input type="submit" value="Submit">
    </form>
</body>
</html>

Conclusion

Having an ADA compliant Shopify website is more important than ever today, Shopify doesn’t offer much assistance in making your website accessible and delegates the matter to the website owner. This puts your organization at risk of losing thousands in lawsuits and lost revenue from customers with accessibility needs.  Need help auditing your Shopify store? Let our accessibility engineers help you. Write to us at info@advancedbytez.com or reach out to us by filling out our contact form

Using single sign on or password managers for sites that don’t allow SSO is a common practice to make account sign up or logins faster. You don’t have to use a screen reader when filling out forms to know how difficult it can get when it comes to the password fields. As someone with cognitive impairments, I often struggle with remembering all the requirements to fulfill a password strength meter. What’s worse – the placeholders disappear as soon as you begin typing. 

The non-inclusivity of password requirements is what fueled this article today. 

We do witness more single password inputs in today’s design trends, however there needs to be a mechanism to confirm the intended password is typed correctly. Show/Hide buttons address this gap, usually designed as an eye icon, but sometimes the words “Show” and “Hide” are also used. The show button is not only a blessing for users like myself but also benefits users with mobility impairments, seniors, and users of assistive technology.  

How to code the show/hide button can be a contentious topic in accessibility circles

During my auditing work, I’ve come across the use of Disclosure widgets and Toggle Switches. I don’t believe either method is wrong but comes down to a matter of preference for users of assistive technology.  

A Disclosure button will cause AT to announce “button show password expanded/collapsed”. If coded as a Switch the nature of the announcement will change to “button show password on/off.” 

Note: Older implementations of switches may have been announced as checkboxes. First reported in 2020, there was an NVDA issue that caused it to announce a switch as a checkbox. This was due to lack of support to differentiate the aria-checked attribute between role=”checkbox” and role=”switch”. This is now fixed. 

Simple Password Toggle Design Pattern 

The toggle button can be as simple as using the text “Show” and “Hide”. We see a lot of <div> elements being used for switches. While it is not wrong, and at the expense of sounding like a broken record I insist on using the native HTML <button> element. It will automatically receive focus and remain in the DOM tab order, avoiding the need of a tabindex=”0” global attribute keeping your code clean.

The aria-checked attribute is required when using role=”switch” and the values are “True” or “False”. These values need to be updated via Javascript when turned On or Off. 

The Space and Enter key should activate the switch. If using a native <button> element this will be taken care of via HTML automatically. 

Code: 

<button id=”show-password” type=”button” role=”switch” aria-checked=”false”> 

<span> Show Password</span><span>Hide Password</span>

Password Instructions Design Pattern

We can start to get fancy by adding password instructions required to create an account. Undoubtedly, this pattern is more user friendly and helps all users meet the requirements. 

How do we make this accessible for assistive technology? 

  1. list our password requirements somewhere on around the form field for all users to access
  2. Assign an id to the text e.g. “instructions” 
  3. Use aria-describedby = “instructions” on the input. This will allow AT to announce them when the users reach the password input field. 
  4. Write password messages e.g. “Show Password” “Hide Password” and set an id 
  5. Apply a live region aria-live=”polite” to the password message id. When the text updates the state changes and the user is informed. The Polite attribute ensures that the user is not interrupted while typing. 
  6. If icons are informative, use aria-label as their accessible names, and aria-describedby to connect them to the “instructions”. The icons could also be marked decorative as there is enough information conveyed via aria-describedby

Password Instructions with Icon Design Pattern

Using the eye icon is popular with today’s design trends, and it follows the same coding pattern as using Show/Hide text with the exception of using alt text for the icon. The visible instructions can be placed inline to make use of the real estate on the page. 

Optionally, the instructions can be completely hidden for visual users through the visually-hidden or sr-only CSS classes. But that won’t make it inclusive would it? If the instructions are important enough for one group of users, everyone should be able to access them. 

Code: 

<form> 

<p id="instructions">Password: Must be at least 8 characters. Must have at least 1 number. Must have at least 1 uppercase letter. Must have at least 1 special character.</p> 

<p aria-live="polite" id="password-message" >Hide password.</p> 

<div class="input-with-button"> 

<button id="show-password" type="button" role="switch" aria-checked="false"> 

<img class=" show-icon" src="icon.png" alt="Show password"> 

</button> 

<label for="password">Password</label> 

<input aria-required="true" type="password" aria-describedby="instructions" > 

</div> 

</form>

We hope that helps you build inclusive components accessible for all your users. If you need help with accessibility design reviews, our engineers review the code on your existing components and perform accessibility design reviews in Figma with annotations on new component designs. Reach out to us at info@advancedbytez.com. Happy coding!

Automated accessibility testing utilizes software to scan websites and applications for accessibility violations against WCAG guidelines. While they don’t cover all the specified standards, software covers up to 20-25% of them. This is better than 0. Automated testing is a great first step in identifying and fixing the low-hanging fruit, and those same series of steps can be applied to reporting to complete the cycle.

Web Accessibility Automation

Automation is a trend that shows no sign of slowing down; leveraging automation technology instead of human capital is changing the business landscape like never before. Saving businesses millions and lowering overhead expenses of running an online business.

Web accessibility testing is easier than ever with automation tools, such as LERA. There are countless benefits of automating your web accessibility testing.

Some of which are:

Let’s have a look at the benefits of automating your web accessibility testing and reporting. And how they can leave a positive impact on your business processes in the long run.

Web Accessibility Testing

Manual Testing or Automated Accessibility Testing?

Web accessibility testing can be divided into two groups: manual and automated.

Manually looking for accessibility violations on each page of your website takes a lot of time and money out of your pocket.

Instead of asking manual auditors to test your website every year giving you late feedback, using automation tools gives you near-real-time feedback on changes made on your website pages. And doing so on a consistent basis enables you to catch accessibility issues early in the development process.

This makes the whole testing process consistent across all your website pages, which translates into a consistent user experience for users with disabilities which is another key benefit. Automation also makes it easier for your development team to debug and fix accessibility issues.

Web Accessibility Crawl Scan

There are multiple ways you can scan your website for accessibility issues, one way is to run a crawl scan. Which starts by scanning a base URL, it then finds links leading to other webpages, scans them and so on and so forth until the whole website has been scanned for accessibility violations.

Running an automated web accessibility test is a great way to analyze parts of your websites that you probably had no idea existed. You can run them as much as you want and whenever you want.

What if a crawler detects no issues on your website, does that mean you don’t have any? Not necessarily, crawlers are a great way to find non-ambiguous issues on your web pages, this is not the case with ambiguous issues.

Some accessibility deficiencies will require a manual review from an auditor to verify. One such example is alternate text for images. It’s easy to run an automated scan and test whether an image has an alternate text or not, but how do you validate if the alternate text is appropriate? This can only be verified manually.

Talk to an Accessibility Auditor for help with manual code review of your web application.

Web Accessibility Reporting

Generating accessibility reports is often ignored or not given enough attention, yet it’s a crucial part of web accessibility. With automation tools, accessibility reports can be generated as often as you want depending on your business needs. Scheduling automatic reports helps keep accessibility top of mind for your whole team.

Legal And Compliance

It helps legal and compliance teams monitor risk, consent decree requirements and prevent legal actions against your business. It also helps them make sure that your organization respects accessibility compliance standards, the most common ones being WCAG 2.0 Level A/AA and WCAG 2.1 Level A/AA.

Development

Accessibility reports are useful for development teams as well, more often than not developers don’t think much about accessibility and are unfamiliar with WCAG rules. These reports can be used by developers to prioritize resources and focus their development efforts into solving high impacts issues first. It also helps in pinpointing where exactly these issues are occurring, and what proactive measures they can take to avoid them in the future.

Leadership

For leadership, accessibility reports and dashboards that focus on summarization are a great way to manage and have a birds eye view of an organization’s efforts towards accessibility.

Some of the default information that we track at AdvancedBytez are:

Contact Us Today to learn more about Custom Accessibility Reporting Dashboards!

Conclusion

Automating your web accessibility testing and reporting enables you to test your website as a whole, you get quick feedback and it’s easily scalable. Fixing accessibility issues at later stages of development is difficult. Running these tests early in the design and development process will save you time and money.

Generating automated accessibility reports enables your legal and compliance team to assess, monitor, and ensure that your organization respects accessibility standards. It helps your development team understand, troubleshoot and prioritize their development resources towards resolving urgent accessibility issues. And take proactive actions to avoid them in the future. It also helps leadership manage and stay updated on the organization’s accessibility compliance level.

Whether your development team is looking to QA bugs or convince your leadership that you are on the right track, we have an end-to-end solution to meet your needs – Manual, Automation and Managed Accessibility Services.

Talk to an Accessibility Engineer today to explore your needs.

Code linters are automated tools that evaluate source code for errors, bugs, and other issues. They identify common mistakes and coding styles that do not adhere to best practices, helping to identify and fix problems in your code before it is compiled.

An accessibility linter is a software program that analyzes the source code of a website or application and checks it against particular criteria, usually related to accessibility, to identify issues and potential problems.

Accessibility testing is a critical part of any software development lifecycle and the use of accessibility linters can be an invaluable tool to help catch and fix accessibility bugs before they become a problem. 

Benefits of Using Accessibility Linters 

Using accessibility linters is a great way to detect and fix accessibility bugs in source code before projects are compiled and deployed. Most linters are free, making them a low barrier of entry for developers to start using. They are also simple to use, and will integrate with your IDE and start finding and helping you fix bugs. 

The benefits of using accessibility linters include

Reduction of errors in production –

Using an accessibility linter is also a great way to prevent accessibility issues before they become a problem. By integrating an accessibility linter into the automated pull-request process, developers can ensure that all code is checked for accessibility issues before it is merged into the main branch. This helps to ensure that any code that is merged into the main branch is as accessible as possible.

Increased knowledge of accessible code –

In addition to helping prevent accessibility issues from becoming a problem, accessibility linters can also help developers learn how to write accessible code. By providing references to help developers better understand the accessibility issue, they can learn how to avoid making the same mistake in the future. This can be especially helpful for developers who are new to coding or are unfamiliar with accessibility.

Consistency of code –

Increased readability, maintainability and consistency of the production of code is possible by using the strict linting framework.

Consistency of style –

Linters ensure fewer debates concerning code style during code reviews.

Objective assessments –

Linters can provide an objective and measurable evaluation of code quality, which can help to prevent debates regarding code quality from descending into subjectivity.

As the overall quality of code improves this will reduce the level of effort required for manual accessibility testing. 

Popular Accessibility Linters 

Popular Accessibility Linters are open source tools used to detect and fix accessibility bugs in source code. These linters are typically integrated into IDEs and can also be used in automated processes such as pull requests and continuous integration and delivery (CI/CD). 

Some popular accessibility linters include ESLint, AccessLint, and Axe Accessibility Linter.

1. ESLint

ESLint is one of the most popular JavaScript linter which has a wide selection of library rules to help developers detect and fix common accessibility issues. It can be used in both Node.js and browser-based projects. 

There are different accessibility add-ons for each framework allowing you flexibility. ESLint supports React, Angular, Vue and JSX.

2. AccessLint

AccessLint is a linter that finds accessibility issues in your pull requests available as an app for GitHub. You can use AccessLint when a pull request is made, reviewing the changes and comments for accessibility issues, before code is manually reviewed. 

3. Axe

Axe Accessibility Linters is another popular accessibility linter. It is a free and open source automated testing library that can be used to detect and report on accessibility issues on 40 rules based on the axe-core rule engine. It is available for both web and mobile applications and can be integrated into IDEs, pull requests, and CI/CD pipelines.

The Axe linter supports linting for React, Vue, Angular, Markdown and HTML and is available for both Github and VS Code.

By integrating these linters into IDEs and automated processes, developers can ensure that their code is as accessible as possible.

How to Use Accessibility Linters?

These tools can be integrated with development environments and integrated into the automated pull-request process to detect and fix accessibility bugs before the project is compiled and deployed. 

Often, these tools can even provide references to help developers better understand the accessibility issue and prevent them from making the same mistake in the future. Accessibility linters can also provide valuable insight.

For example, some tools will detect and report on which accessibility criteria have been met and which have not. This can be a valuable resource for developers to identify areas of improvement or potential issues that may have otherwise gone unnoticed. 

They will then report any errors they find, and suggest ways to fix them. For example, if a linter finds missing alt text, it will suggest adding the appropriate alt text. Linters can also be used to detect potential keyboard traps, and flag any missing labels or form elements. Linters can be used to scan code in a variety of languages, such as HTML, CSS, JavaScript, and more.

Considerations When Using Accessibility Linters 

When using accessibility linters, there are a few things to consider. 

To get started with accessibility linters, first you need to choose which linter is best for your project. Once you’ve selected a linter, you can install it into your IDE and/or automated PR process. Once the linter is installed, you can start running it against your source code. 

The linter will then scan your code and report any accessibility bugs that it finds. Depending on the linter, it may also automatically fix some of the bugs. When using accessibility linters, it’s important to remember that they may not be able to detect all accessibility bugs. After all, automation only catches up to 25% of the bugs.

Conclusion

Accessibility linters are a powerful tool in the fight against accessibility bugs, and they offer a low barrier of entry for developers to detect and fix these bugs before they can impact users. However, linters can be limited in scope and not detect all accessibility bugs, so it is important to supplement them with other automated tools. Browser extensions are a great way to supplement linters, as they are usually accessible, simple to use, and can detect and reference a third of the WCAG Success Criteria.

With the right linter, you can start making your development process more accessible and make your applications more usable for all users.

Skip to content