It's Spelled aria-labelledby

This is just a quick note on spelling. The specification for aria-labelledby identifies the attribute's correct spelling as "aria-labelledby", as opposed to what might be its expected U.S. English spelling, "aria-labeledby". Apparently, the approved spelling was selected to minimize the difficulty for developers. However, seeing as how easy it is to find examples in the wild where the attribute is spelled "aria-labeledby" suggests that perhaps some difficulty for developers remains.

Browser and Accessiblity API Support

Internet Explorer 8 supports both spellings, i.e., "aria-labelledby" and "aria-labeledby". No matter the attribute's spelling, IE8 passes the attribute value to the MSAA accessibility API, which allows supporting assistive technologies, such as screen readers, to construct the relevant component's accessible name using that value.

Update (March 7, 2011): Thanks to Steve Faulkner for setting things straight (see Steve's comment below). Turns out, in fact, that IE does not support the incorrect spelling "aria-labeledby", but instead, in the absence of a proper label, builds the component's accessible name using whatever text exists within the component. You can read my reply to Steve which explains how I ended up coming to this false conclusion about IE. This is good news, in the end.

Firefox 3.6, on the other hand, only supports the attribute when it is spelled correctly as per the specification. The attribute's value is passed along to both the MSAA and IA2 accessibility APIs that Firefox supports only when the attribute is spelled "aria-labelledby". Otherwise, if the attribute is spelled "aria-labeledby", assistive technologies running on top of Firefox are not able to construct an accessible name for the associated component.

It's in the Spelling

If you need an additional reason to spell the attribute according to spec, let it be that that Firefox only supports it when it's spelled "aria-labelledby". If it's spelled "aria-labeledby", any accessibility benefits intended by using the attribute will be lost to those using Firefox, which is the preferred browser for many, especially those using the NVDA screen reader.

This difference in how the two browsers behave and the information they provide accessibility APIs also helps to explain the results from the two tests provided below.

Test #1: aria-labelledby spelled correctly

Below is an ARIA alertdialog whose label is referenced using aria-labelledby spelled according to the specification.

This alertdialog example requires that JavaScript be enabled.

alertdialog #1 label

Text for alertdialog #1

Test #1 Results

  • In Firefox 3.6, both the NVDA 2011.1b2 and JAWS 12 screen readers announce the referenced label, "alertdialog #1 label," when reading the dialog.
  • In IE8, JAWS 12 announces the referenced label when reading the dialog, but NVDA 2011.1b2 announces neither the dialog's label nor its text content.

Test #2: aria-labeledby spelled incorrectly

An alertdialog whose label is referenced using aria-labeledby spelled incorrectly, according to the specification.

This alertdialog example requires that JavaScript be enabled.

alertdialog #2 label

Text for alertdialog #2

Test #2 Results

  • In Firefox 3.6, NVDA 2011.1b2 and JAWS 12 do not announce the referenced label, "alertdialog #2 label," when reading the dialog.
  • In IE8, JAWS 12 announces the referenced label, "alertdialog #2 label," while NVDA 2011.1b2 announces neither the dialog's label nor its text content. Update (March 7, 2011): It's now clear, based on tests by Steve Faulkner, that JAWS in IE reads the label text only as part of the larger sequence of all the text contained in the dialog, and is not announcing it as an explicit label, per se.

Spell it as Specified

Despite the fact that, in some instances, aria-labelledby is supported when it's spelled "aria-labeledby", it is probably best just to play it safe and spell it "aria-labelledby" as defined by the specification. You'll not only be following the standard, but, and more importantly, users of Firefox with assistive technologies that support ARIA will benefit. Update (March 7, 2011): While contrary to my initial conclusion, IE does not support the "aria-labeledby" spelling. Apparently, however, a development version of Google Chrome supports both spellings. I've not looked at this, but Chrome's accessibility support is still very much in development at this stage.

6 Responses to It's Spelled aria-labelledby

  1. 1. steve faulkner:

    Hi jason my interest was taken by your post. I looked into it further and did some testing. I think while there is something not right going on with the accessible name calculation for alertdialogs it is not as you have described. I have written up my tests and test results

  2. 2. Jason:

    Hi Steve,

    Thanks very much for looking into this in more detail and sorting out what’s really going on. While I guess the conclusion that aria-labelledby should be spelled properly still holds, it’s good to know that Internet Explorer’s behaviour is not because it supports the incorrect spelling “aria-labeledby”, but because, in the absence of a correctly spelled aria-labelledby attribute, it makes its own calculation of the alertdialog‘s accessible name based on the dialog’s text content.

    I appreciate the fact that in your tests you have the referenced label outside the actual alertdialog, which certainly helps to distinguish between label and dialog text content, and more clearly indicate what the browser is using to construct the accessible name.

    Things may have worked better for me had I used Accessibility Probe (AccProbe), which clearly indicates that IE is constructing the accessible name using all of the text within the dialog. I had relied on Accessibility Viewer (AViewer), which does not seem to work the same. For instance, using AViewer with my second alertdialog example, where the attribute is spelled incorrectly, the MSAA accessible name from IE is indicated to be “alertdialog #2 label”. This, I suppose, is why I mistakenly assumed IE was actually supporting the incorrectly spelled attribute.

    On the other hand, using AccProbe, the accessible name for the same example in IE is indicated as “alertdialog #2 labelText for alertdialog #2Close”. This is consistent with the situation as you revealed it to be.

    So, hey, I learned a few things today, which is always nice :) Thanks for that.

    One last question about your test results: I read the results table as saying that, with aria-labelledby correctly spelled correctly, IE does not use the referenced label text, but just the dialog’s element text, i.e., “this is dialog text”. As far as I can tell using AccProbe, IE8 and IE9 use the referenced element text content “correctly labelled” for the component’s accessible name. Am I reading this right?

  3. 3.

    Hi Jason, in regards to the aViewer, you are correct that it does not show the full accessible name in the UI view, not sure why, the info is there (if you use the copy function in the aViewer and paste it into a doc. It provides the full name:

    Name: alertdialog #2 label
    Text for alertdialog #2

    the question in regards to the results:
    You are right about IE 8 exposing the correct accessible name on the dialog with no tabindex set.

    Name: alertdialog #1 label
    Role: dialog
    State: focusable

    The tests I ran yesterday used IE9 RC, I will need to re-check the result when I am at home (currently on a machine with IE 8).

  4. 4. steve faulkner:

    Hi jason, I retested with IE9 and it does work correctly when aria-labelledby is spelt correctly, regardless of whether it has a tabindex or not. Thanks for pointing out the error. Have updated the results.

  5. 5. Marcus Tucker:

    I think your updates would be much clearer if you also used the HTML element STRIKE to indicate the invalidated portions of your original post.

  6. 6. Jason:

    Thanks, Marcus. Not a bad idea. However, in HTML5, which I’ve been using on this site (for better or worse), strike is no longer available, so I’ve used del and ins.

Comments are now closed.