Easy ARIA Tip #1: Using aria-required

Inspired by a conversation I had with Aaron the other day, I’m starting a mini series about easy accessibility improvements you can accomplish using ARIA, but which do not require you to implement a whole widget. Some ARIA attributes also work on plain old standard HTML elements and can easily improve accessibility within supported browsers and screen readers. On browsers that do not support these attributes (yet), they are ignored and do not break your page just because that attribute is there.

The first attribute I’d like to cover is called aria-required. It is one of the universal aria attributes, which means, as stated, that it can be used on any conventional HTML element such as input or select.

Let’s look at this sample excerpt:

First name:

Last name:

Street address:

In this excerpt, both the firstName and lastName input elements have the aria-required attribute set. Note that in normal scenarios, you’d also stype them or their label differently, or put an asterisk “*” after the label.
However, if you cannot or do not want to put an asterisk on the label, but only style it with bold text or the like, screen readers usually cannot pick up the information automatically that this is a required field. If you use the aria-required attribute as shown above, modern screen readers will indicate that this is a required field automatically, if used together with Firefox 3.
Screen readers that already support this feature are NVDA, JAWS 9.0, and Window-Eyes 5.5 or higher. JAWS 8 does not support this attribute yet. Also, ORCA does not seem to pick this attribute up yet, at least my testing showed that Orca did not indicate the required state to me when tabbing through that form.

On the browser side, Opera 9.5 is going to include ARIA support, so this technique is not limited to Firefox. Also, as this technology spreads, more browsers will pick up on it, and your sites will automatically be compatible and more accessible once these other browsers also support ARIA.

This is the first of a couple of examples that demonstrates how easily you can use ARIA without implementing a whole widget to improve accessibility on your web sites. Start using it today, and you’ll make sure that you help insure good accessibility for people using modern browsers and screen readers!


53 thoughts on “Easy ARIA Tip #1: Using aria-required

  1. So what’s the status with ARIA and IE? I’d love to start using some of these features, but I guess I’m going to have to carry on doing what I do currently regardless.

  2. Robin, IE does currently not support ARIA. However, you can use the markup nevertheless. Firefox, and other modern browsers will use it, and once IE comes around to supporting it, too, you do not need to change your pages again then, they will just start to work for IE users as well as they already do for Firefox users.

  3. Under which doctype is aria-required a valid attribute?

    And s/action=post/method=post/ on the form element in the example.

    Then there’s this thing called XML — but that’s another story.

  4. 1. Thanks for the suggestion on the form. The code was just meant as an example, and I didn’t pay attention to the form attributes (only where it mattered, and that was on the input tags).
    2. With Firefox, the aria-required attribute works on any doc type. I used it in a plain HTML doc that didn’t have a doc type specifier at all.

  5. I like this ideas, Its best practice if this implementation is send to specific type of browser agent only. Can you write the full list of User-agent string that supported “ARIA-required” propriety.

  6. I like this ideas, Its best practice if this implementation is send to specific type of browser agent only. Can you write the full list of User-agent string that supported “ARIA-required” propriety.

  7. It’s not necessary to filter WAI-ARIA attributes based on some browser versions. Those browsers that don’t support WAI-ARIA yet, such as IE 7, will simply ignore the attributes, they do not affect the layout of a page or such.

    1. Obviously that is only part of the problem, for example older browser will have shortcomings in what they expose to AT via the APIs so a polyfil may not be that usefull. ARIA Host languages define what is premissable and what is not. On the contrary, the need for ARIA increases with the use of technologies such as web components. Thanks

    1. Your website is one of few blogs where I could find useful information about implementing accessible support and I want to congratulate you for this.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.