{"version":"https://jsonfeed.org/version/1","title":"Aaron Gustafson: Content tagged WAI-ARIA","description":"The latest 20 posts and links tagged WAI-ARIA.","home_page_url":"https://www.aaron-gustafson.com","feed_url":"https://www.aaron-gustafson.com/feeds/wai-aria.json","author":{"name":"Aaron Gustafson","url":"https://www.aaron-gustafson.com"},"icon":"https://www.aaron-gustafson.com/i/og-logo.png","favicon":"https://www.aaron-gustafson.com/favicon.png","expired":false,"items":[{"id":"https://www.aaron-gustafson.com/notebook/accessibility-assistant-for-figma-v52/","title":"✍🏻 Accessibility Assistant for Figma v52","summary":"I just hit “publish” on Accessibility Assistant for Figma v52 and I wanted to share some details on why this is a monumental release for us.","content_html":"

I just hit “publish” on Accessibility Assistant for Figma v52 and I wanted to share some details on why this is a monumental release for us.

\n

We’re in the process of a major overhaul to this plugin. There was a lot of infrastructural work to do to modernize the plugin and set the stage for a host of new features to make designers more productive when it comes to making their designs more accessible. This release incorporates a lot of that foundational work, notably:

\n\n

We also fixed bugs related to duplicating layers. You can now copy layers and the annotations will go along for the ride, becoming a new Annotation Set. Similarly, you can now duplicate pages and the annotations — which are page-bound — will be re-generated. It’s worth noting that this may take some time on particularly large pages.

\n

This release has been a long time coming, but I’m incredibly proud of the team that’s been working so diligently on this, particularly Ashish Singh from HCL and Michael Fairchild, Scott O’Hara, and Ben Truelove from Microsoft. Their attention to detail and encyclopedic knowledge of accessibility has been instrumental in getting this project to the place that it is.

\n

And there’s more to come!

\n","social_text":"I just hit “publish” on Accessibility Assistant for Figma v52 and I wanted to share some details on why this is a monumental release for us.","url":"https://www.aaron-gustafson.com/notebook/accessibility-assistant-for-figma-v52/","tags":["accessibility","design","inclusive design","Microsoft","user experience","WAI-ARIA"],"date_published":"2026-02-20T23:27:28Z"},{"id":"https://www.aaron-gustafson.com/notebook/bring-focus-to-the-first-form-field-with-an-error/","title":"✍🏻 Bring Focus to the First Form Field with an Error","summary":"While filling out a long form the other day, I couldn’t figure out why it wasn’t submitting. Turns out I’d forgotten to fill in a field, but I didn’t know that because it had scrolled out of the viewport.","content_html":"

While filling out a long form the other day, I couldn’t figure out why it wasn’t submitting. Turns out I’d forgotten to fill in a field, but I didn’t know that because it had scrolled out of the viewport. This is a common problem on the web, but easily remedied with a little bit of JavaScript.

\n

# Step 1: Make the Most of Your Markup

\n

Whenever you’re building a form, you should use every tool in your toolbox for building that form properly. That means:

\n
    \n
  1. Associate labels with their fields
    2. \n
  2. Use specialized input types (e.g., email, URL) as appropriate
    3. \n
  3. Identify required fields with required and aria-required
    4. \n
  4. If you’re expecting a field to match a particular format, note that with pattern and provide an example with placeholder
    5. \n
  5. Additional information about a field should be bound to it using aria-describedby
    6. \n
\n

By following these steps, you’re likely already in a good place when it comes to your form’s UX and accessibility. Browsers will pay attention to the instructions in the markup, validate the user’s input, and even provide guidance on how to correct issues without you having to lift a finger. They’ll even focus the first invalid field on your behalf!

\n

But what if you want to customize the experience?

\n

# Step 2: Enhanced Browser Validation

\n

When you use proper markup for your forms, enhancing them with JavaScript becomes straightforward, thanks to the Constraint Validation API. Consider the following form field:

\n
<input id=\"name\" name=\"name\" required aria-required=\"true\" />
\n

Using JavaScript, we can check to see it’s validity at any point:

\n
document.getElementById(\"name\").validity.valid;\n// Is either true or false
\n

There are also a host of other properties on the field’s validity property that provide even more detail as to the state of the field’s validity (hence the name: ValidityState). In the case of the field above, if valueMissing is true (relating back to that required attribute), valid is false.

\n

Armed with that knowledge, you could use another feature of the Constraint Validation API to show a custom error message in the browser UI:

\n
var input = document.getElementById(\"name\");\nif (!input.validity.valid) {\n  input.setCustomValidity(\"Please enter your name\");\n  input.reportValidity();\n}
\n

The thing is, you don’t really want to litter your JavaScript with strings like that. It’s not maintainable. Thankfully, we can leverage markup to achieve the same goal:

\n
<input\n  id=\"name\"\n  name=\"name\"\n  required\n  aria-required=\"true\"\n  data-error-required=\"Please enter your name\"\n/>
\n

The input in this example has a data attribute containing the error string (data-error-required). We can create whatever data attributes we want and access them using that element’s dataset property. It’s worth noting that hyphenated property names become camelCase when accessed as a named property of dataset.

\n
var input = document.getElementById(\"name\");\nif (!input.validity.valid) {\n  input.setCustomValidity(input.dataset.errorRequired);\n  input.reportValidity();\n}
\n

With that, we get the same result with far looser coupling between individual fields and the JavaScript handling validation.

\n
\n

\"This

\n
\n

You can even extend the approach to handle different kinds of errors:

\n
<input\n  type=\"email\"\n  id=\"email\"\n  name=\"email\"\n  required\n  aria-required=\"true\"\n  data-error-required=\"Please enter your email\"\n  data-error-invalid=\"Your email doesn’t look right\"\n/>
\n

Here I’m using two different data attributes to apply in different error scenarios and the one I show will depend on the type of error a user has encountered. Pretty cool!

\n

And since we’re still operating in the context of the browser’s built-in validation experience, users will still get directed to the first field with an error when they submit the form.

\n

But what if you want to bypass the built-in experience and go full custom?

\n

# Step 3: Going Rogue

\n

The built-in browser validation UI is pretty great, but maybe it’s not your cup of tea. Thankfully, it’s pretty easy to take the training wheels off. You just add a novalidate attribute to the form element. But before you go dropping that attribute in your markup, consider that your custom validation code will all be JavaScript and if that fails to run—yes, it happens—the browser won’t step in and fill the void. So instead of putting it in your markup, inject it into the form when you know absolutely all of the JavaScript code necessary to run your custom validation experience is loaded and ready to rock. In fact, it should be the last line of code to execute:

\n
// Validation Logic Definition\n// including validateMe() function\n\ndocument.querySelectorAll(\"form\").forEach(function ($form) {\n  $form.addEventListener(\"submit\", validateMe, false);\n  $form.setAttribute(\"novalidate\", \"\");\n});
\n

With that in place, we can turn our attention to handling the validation setup.

\n

For simplicity, and based on personal preference, I am going to start with setting up my form to validate when the form is submitted rather than whenever an individual field is changed (hence the “submit” event listener). When the event is fired, the event handler will loop through the fields in the form and validate each one. For the sake of the widest possible browser compatibility, I’m foregoing fat arrow functions and other ES2015 goodies and rockin’ this old school.

\n
function validateMe(e) {\n  var $form = e.target,\n    i = 0,\n    field_count = $form.elements.length,\n    $first_error = false;\n\n  for (i; i < field_count; i++) {\n    var $field = $form.elements[i],\n      valid = isValid($field);\n    if (!$first_error && !valid) {\n      $first_error = $field;\n    }\n  }\n\n  if ($first_error) {\n    e.preventDefault();\n    $first_error.focus();\n  }\n}
\n

First, I get a reference to the form that needs to be validated, then I set up the loop for each of the fields. I also set up a reference to the first field with an error—that is the point of the article after all—as $first_error and set it to false.

\n

Within the loop, I grab a reference to the field and pipe it into another function that will do the actual validation (isValid()). That function will return true if the field is valid and false if it isn’t. The last bit of the loop checks to see if $first_error has been set already and, if it hasn’t, sets it to the current field if it isn’t valid.

\n

Finally, I check to see if $first_error is set (i.e., true) and if it is, the form has an issue, so I prevent the default behavior of the submit event (using preventDefault()) and focus the field captured in $first_error.

\n

# Addendum: Associating Custom Error Messages

\n

I don’t want to get too into the weeds with my isValid() method, as you can see the end result at the bottom of this post, but I do want to take a moment to describe how you should be handling inline field errors.

\n

First off, you will need to add aria-invalid="true" to any fields that have an error. Secondly, you will want to inject the error message into the markup, give its container an id, and associate it with the field using aria-errormessage. So when your JavaScript is done with it, your field will look something like this:

\n
<label for=\"name\">What’s Your Name?</label>\n<input\n  id=\"name\"\n  name=\"name\"\n  required\n  aria-required=\"true\"\n  data-error-required=\"Please enter your name\"\n  aria-errormessage=\"name-validation-error\"\n  aria-invalid=\"true\"\n/>\n<strong class=\"form-validation-error\" id=\"name-validation-error\"\n  >Please enter your name</strong\n>
\n

It’s also worth noting that you’ll want to reset and re-validate the form field once the user has changed the contents of the field (and hopefully remediated the error). Resetting the field will involve removing the aria-invalid attribute and doing one of two things with the error message: either remove it from the markup entirely or simply hide it (e.g., display: none). Once the aria-invalid state is reset, it doesn’t matter that there is an existing aria-errormessage attribute. That said, I generally prefer to totally reset the field entirely, removing both attributes and the validation error element as well.

\n

Here you can see a complete working prototype of this approach:

\n\nHopefully this helps you with the development of your own forms. Good luck!\n","social_text":"When highlighting form errors, moving focus to the first error encountered will ensure the error is seen and remedied.","url":"https://www.aaron-gustafson.com/notebook/bring-focus-to-the-first-form-field-with-an-error/","tags":["accessibility","forms","HTML","inclusive design","JavaScript","progressive enhancement","WAI-ARIA","web design"],"image":"https://www.aaron-gustafson.com/i/posts/2022-08-22/hero.jpg","date_published":"2022-08-22T21:16:02Z"},{"id":"https://www.aaron-gustafson.com/notebook/aria-quicktip-labelledby-vs-describedby/","title":"✍🏻 ARIA Quicktip: Labelledby vs. Describedby","summary":"The difference between the aria-labelledby and aria-describedby attributes is not obvious. Here’s a bit of a clarification for using them in forms.","content_html":"

Last night, while we were enjoying a cool evening and a few drinks outside after day 1 of BDConf, Jeremy asked me for some clarification on the ARIA attributes I had demoed as part of my forms presentation earlier in the afternoon. In particular, he was confused by how aria-labelledby and aria-describedby differ.

\n

I hadn’t really thought about it before, but it’s a good question. They seem pretty similar in function, right? And both support a space separated list of one or more id references. It’s downright confusing.

\n

My simple explanation was that, at least in terms of form fields, they differ in when they are read. The aria-labelledby attribute replaces the associated label element (which is, of course, associated with the field via the label’s for attribute). The aria-describedby attribute, on the other hand, is read after the field type is stated.

\n

To demonstrate how all of this plays out, I threw together a quick CodePen demo that takes you through numerous ways you can use and combine these attributes. I also did a screen recording to demonstrate how ChromeVox exposes these attributes:

\n

https://www.youtube.com/watch?v=U8_VjI-Z1LA

\n

Update: Steve Faulkner shared a doc that discusses how accessible names and descriptions are calculated. Thanks Steve!

\n

Note: I did discover a bug in ChromeVox wherein the content of the elements referenced in aria-describedby are not read when the field receives focus via the keyboard (using the tab key), but it does when it receives focus via the mouse. I’ve submitted a bug report to to the powers that be.

\n","url":"https://www.aaron-gustafson.com/notebook/aria-quicktip-labelledby-vs-describedby/","tags":["accessibility","web design","WAI-ARIA"],"date_published":"2014-11-05T15:45:22Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/improving-the-tweet-box/","title":"📄 Improving the Tweet Box","content_html":"

Twitter.com’s redesign was much welcomed and rightly so. I explored its most prominent feature: the tweet box, and looks at how it can be made more accessible with just a few minor adjustments.

\n","url":"http://webstandardssherpa.com/reviews/improving-the-tweet-box","tags":["web development","JavaScript","WAI-ARIA","HTML"],"date_published":"2011-03-03T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/create-a-tabbed-interface-part-2/","title":"📄 Create a Tabbed Interface, Part 2","content_html":"

Building on the first article, in this piece I focus on making the JavaScript more flexible and accessible.

\n","url":"https://www.slideshare.net/AaronGustafson/create-a-tabbed-interface-part-2","tags":["progressive enhancement","JavaScript","HTML","WAI-ARIA"],"date_published":"2009-11-01T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/publications/articles/create-a-tabbed-interface-part-1/","title":"📄 Create a Tabbed Interface, Part 1","content_html":"

In the first of a two-part tutorial, I demonstrate how to create a script for a lightweight yet powerful tabbed interface using CSS and basic JavaScript.

\n","url":"https://www.slideshare.net/AaronGustafson/create-a-tabbed-interface-part-1","tags":["progressive enhancement","JavaScript","HTML","WAI-ARIA"],"date_published":"2009-10-01T00:00:00Z"}]}