Easy ARIA tip #2: aria-labelledby and aria-describedby

Sorry it took me so long to get back to it, but here it is, my second tip on the usage of some easy ARIA markup to make your sites more accessible.

Imagine this: You have a form where you ask your user a question, but the answer is actually part of the sentence the question is made of. A classic example we all know from our browser settings is the setting “Delete history after x days”. “Delete history after” is to the left of the textbox, x is the number, for example 21, and the word “days” follows the textbox, actually forming a sentence that is easy to understand.

If you’re using a screen reader, have you noticed that, when you go to this setting in Firefox, it actually tells you “Delete history after 21 days”?, followed by the announcement that you’re in a textbox, and that it contains the number 21. Isn’t that cool? You do not need to navigate around to find out the unit. “Days” could easily be “months” or “years”, and in many ordinary dialogs, there is no way to find this out other than navigating around with screen reviewing commands.

Well, we have to thank Aaron and all the other great people who invented ARIA, for this capability! The solution is in an ARIA attribute called aria-labelledby. Its parameter is a string that consists of the IDs of the HTML or XUL elements you want to concatenate into a single accessible name. Yes, you read right, this not only works in HTML, but in XUL, too!

A second attribute that works very similarly is called aria-describedby. It can also take IDs of one or more elements to make up an additional description. In Microsoft Active Accessibility, this is converted into the AccDescription of the element. Some screen readers like NVDA pick this description up and speak it automatically after the name and type of the control, assuming that this information is giving the visually impaired user additional information that a sighted user also gets.

aria-labelledby and aria-describedby are both specified within the element that is to be labelled, for example an html:input or a xul:textbox. In both cases, the label for/label control bindings that may also exist, are overridden by aria-labelledby. If on an HTML page you provide aria-labelledby, you should also provide a label for construct to also support older browsers that do not have ARIA support yet. With Firefox 3, your blind users will automatically get the better accessibility of the new attribute, but the users of older browsers are not left in the dark this way.

And here is an example I made up for demonstration purposes:

minutes

Allows you to specify the number of minutes of inactivity after which your computer should shut down.

A Note for JAWS 8 users

JAWS 8.0 has its own logic to find labels, causing it to always override the accessibleName the textbox of an HTML document gets. With JAWS 8, I have not found a way to get it to accept the label from the example above. But NVDA and Window-Eyes do it just fine, and Orca on Linux also has no problems.

Previous Easy ARIA tips
  1. aria-required

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:








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!

Yahoo! demonstrating wai-aria roles and states with their YUI Menu Control

Victor Tsaran, accessibility guru at Yahoo!, just posted to the mozilla.dev.accessibility newsgroup that they implemented wai-aria roles and states into the Yahoo! UI’s menu control. You can find the blog post here. To try it out:

  1. From within the blog post, open the link “new YUI example”.
  2. From the article that opens, open the “View Example in new window” link.
  3. On the page that appears, arrow to the first item that starts with “text/html”, and press ENTER on it. This will turn on Forms Mode (in JAWS) or your relevant navigation mode.
  4. Use Left and Right Arrows to navigate the menu bar, use DownArrow to open the menu, just like you would use any ordinary menu.

I tested it, and it works great! Good work, guys!
Note that you need Firefox 3 beta 2 and JAWS 8 or later, or Window-Eyes 6 to take full advantage of this.