Helping developers write accessible code

Blog author Kendall Gassner's headshot next to the blog title, Helping Developers Write Accessible Code.

Why does accessibility (and, therefore, accessible code) matter? As a software engineer at Intuit®, I think this is a very important question, and Intuit’s Global Accessibility Leader Ted Drake has a great answer in Building an inclusive experience: Why accessibility matters.

“Our goal, as developers, is to build products that reach the largest possible audience,” he writes. “Accessible design affects everyone.”

“Everyone” means users with and without disabilities. As Ted points out, every user, regardless of their limitations (or even more so, because of them), should be able to recognize each element on a screen, and know how to interact with it using their input device of choice.

For inclusion to occur, developers need to utilize inclusive design principles during the development process. Developers will find that putting the needs of those with disabilities at the top of their priority list will benefit all users. This accessibility-first mindset eliminates the need to go back and fix frustrating and time-consuming problems.

It’s truly a win-win for everyone. The best part is, there are several tools to help developers write accessible code. And this is why I created the open source vs-code plugin: accessibility-snippets.

Code snippets are templates that make it easier to enter repeating code patterns, such as loops or conditional-statements. Accessibility-snippets is intended to make it easier to repeat accessible patterns, with most of the snippets relating to WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) standards and guidelines.

A quick review of ARIA

Before taking a look at accessibility-snippets, it’s important to know a little bit about Accessible Rich Internet Applications (ARIA).

ARIA enables developers to make web content and applications more accessible to people with disabilities. For example, users who rely on screen readers or can’t use a mouse (rendering many websites unusable to them) can use ARIA added by developers to help them navigate pages identify menus, primary content, secondary content, banner information, and other areas.

Intuit’s Zachary Hall discusses ARIA and the Accessibility Tree in Why the Accessibility Tree is key
to understanding accessible applications: “Browsers will use ARIA attributes if they are provided to fill in data for an Accessibility Tree. If the data is not provided, it will fall back to other attributes on the element, if possible. It is important to limit the use of ARIA where possible and use semantic HTML, but there are some cases where ARIA is needed to have a custom component behave like a control that assistive technology can understand.”

Aria attributes are powerful tools, but when used incorrectly, they can make a site less accessible. With so many different states and properties, it can be difficult for a developer to find the appropriate attributes for the component they are working on. This is where my vs-code extension comes in. My extension creates code templates of common aria patterns to aid proper aria usage.

Accessibility-snippets’ features

Css snippet

  • Reduced motion – Adds a reduced motion snippet with prefix transition.

React Aria Snippets

  • AlertAria – Add role=’alert’ to a node containing an alert message. Setting role=’alert’ automatically sets aria-live=”assertive” and aria-atomic=”true.”
  • AlertDialogAria – Add role=’alertDialog’ when an alert is urgent and demands immediate attention. Only use alertDialog when the alert message has associated interactive controls.
  • ArticleAria – Add role=’article’ to a node that can easily stand on its own separate from the main content of the page. An example is a newspaper article or a forum post. Use aria-posinset to indicate the article within the feed. Use aria-setsize to indicate how many articles are in the feed.
  • ButtonAria – Add role=’button’ on a clickable element that triggers a response when activated by a user. Add aria-pressed when a button can toggle ‘on’ or ‘off.’ Add aria-expanded if a button triggers another node to expand or collapse.
  • CheckboxAria – Add role=’checkbox’ to a checkable interactive control. Add aria-checked to indicate the state of the checkbox.
  • ComboboxAria – Add role=’combobox’ to a composite widget containing a single-line textbox and another element such as listbox. Add aria-haspopup if the combobox contains a popup. Add aria-expanded if the combobox expands or collapses a node. Add aria-owns to indicate which elements the combobox owns.
  • DialogAria – Add role=’dialog’ to a window separate from the rest of the webpage like a modal.
  • FeedAria – Add role=’feed’ to a dynamic list of articles. Add aria-busy if articles are being loaded or have been removed from the feed.
  • LinkAria – Add role=’link’ to elements that act as hyperlinks. Ensure the link can be navigated to via the keyboard. If the link role is added to an image add alt text. Add an aria-label if the link does not provide a descriptive text label.
  • RadioAria – Add role=’radio’ to a checkable interactive control. Use radio in place of checkbox if only one item in a group can be checked. Add aria-checked to indicate the state of the checkbox.
  • SliderAria – Add role=’slider’ to allow users to select from a certain range. Add aria-orientation to indicate what direction the slider is oriented in. Add aria-valuemin to indicate the minimum value. Add aria-valuemax to indicate the maximum value. Add aria-valuenow to indicate the current value. If the value is not represented by a number add aria-valuetext in place of aria-valuenow.
  • SwitchAria – Use role=’switch’ on checkboxes that represent an ‘on’ or ‘off’ state. Add aria-checked to indicate whether component is on or off. Add aria-required if the field is required.
  • TextboxAria – Use role=’textbox’ on elements that allow input of free-form text. Add aria-activedescendant to indicate the current active child (for example if the textbox has an autocomplete popup and the focus changes to the popup). Add aria-autocomplete to indicate if the textbox will display a list of suggestions. Use aria-multiline if the textbox can contain multiple lines of input. Add aria-placeholder to give users a hint of what the input should contain. Add aria-readonly if the user cannot modify the value. Add aria-required if the field is required.

To learn more about ARIA, check out Ted’s 5 tips for making apps accessible. He notes that ARIA “is a set of HTML attributes that redefine the role, state, label, and value of an element” and “surface information to assistive technology to let the user know what they can expect.” He discusses the importance of form labels; buttons; links with an href; focus management; and headings, landmarks, and page titles.

He also writes, “Accessible product development is the responsibility of all designers and developers.”

Making accessibility priority #1

Just over 30 years ago, the Americans with Disabilities Act (ADA) was signed, ushering in the era of universal, accessibility-first, and inclusive design. I am so thankful that I work at a time when assisting those with disabilities is a priority and for a company that promotes accessibility.

My goal in designing accessibility-snippets is to help other developers in the creation of accessible code. In return, I hope they will provide contributions and feature suggestions that will help make it a success for everyone. To learn more about accessibility-snippets check out Intuit’s accessibility snippets written by Aliza Carpio, Tech Evangelist.

For more information on accessibility, make sure to read: