aria-labelledby and aria-describedby support in popular Windows browsers

Back in 2010 I filed a bug on Internet Explorer about its lack of support for exposing the calculated values of aria-labelledby and aria-describedby in the MSAA accessibility API. After some back and forth a partial fix was implemented.

Partial Fix

The upshot was that IE would correctly convey the name and description for an element if the elements referenced by the aria-labelledby and aria-describedby attributes were what IE classed as accessible HTML elements. Notes from IE team on IE’s partial fix (below) for details.

Note: Despite IE’s limited support, screen readers may still support labelledby and describedby in IE, depending on whether they have implemented their own workarounds.

Workarounds (added burdens)

Since 2010’s IE implementation I have been advocating the use of a number of methods to work around the limitation in IE’s implementation.

Use of tabdindex=”-1″

This is the Microsoft documented method:

You can make non-accessible elements accessible by specifying a value for the element’s TABINDEX attribute.

Example:

<p tabindex="-1" id="label-1">label text</p>
...
<input type="text" aria-labelledby="label-1">

Use of the <label> element

The <label> element works (although not listed as an accessible element) and usually descriptions associated with controls are extended labels

Example:

<input type="text" aria-describedby="desc-1">
...
<label id="desc-1">instructions</label>

Of late I have dropped the <label> element advocacy as it was viewed as a misuse of <label> by some in the web standards community.

Where are we at in 2014?

Following a recent discussion I have tested support in popular modern browsers on Windows

Summary

• Firefox 29 supports aria-labelledby and aria-describedby with single or multiple id references.
• Chrome 35 supports aria-labelledby and aria-describedby with single or multiple id references.
• IE 11 does not support aria-labelledby or aria-describedby with single or multiple id references unless the referenced element is what Microsft classes as an accessible element. IE non accessible elements can be made into accessible elements by the addition of tabindex="-1" as documented or via the addition of an ARIA role (when appropriate).

A new Internet Explorer bug has been filed

Notes from IE team on IE’s partial fix (2010)

This is the text from the response by the IE team to the bug I filed (note: actual bug is no longer available)

As we evaluated this bug report and the repro page, we found that the test cases failed because of three different issues:

1.When presented with multiple labeledby and describedBy elements IE did not concatenate the values from those elements into the MSAA name or description.

2.When an element contained a native accessibility attribute (title or alt) the aria-labeledBy and describedBy attributes did not take precedence over the native attributes.

3.The value of the elements pointed at by the aria-labeledby and describedby is only available to the accessibility properties if the elements themselves are accessible objects.  Not all IE elements are accessible objects as is described here: https://msdn.microsoft.com/en-us/library/ms528445(v=VS.85).aspx#acc_elements (*Note – I have asked Cullen to check this documentation as I’m not sure how accurate it is but it was the best I could find.  It doesn’t mention that adding an aria-role to an element also makes it accessible.)

We fixed the first two issues. IE9 will now concatenate the value of multiple labeledby/describedby elements and use labeledby/described by to trump native accessibility attributes if the labeledby/describedby elements are accessible objects.  The list of elements which are automatically accessible objects is here: https://msdn.microsoft.com/en-us/library/ms528445(v=VS.85).aspx#acc_elements and you can easily make any other element an accessible object by adding a tabindex or an aria role to it. 

While we investigated fixes for the third issue, it will not be resolved in IE9.  However, we will revisit this in the future.  Since the test page requires all three issues to be fixed, you won’t see the expected behavior on that page.  The workaround is to add a role=’tooltip’ attribute on elements l1, l2, l3, d1 and d2 on the test page then you will see all the tests working.

Regards, The Microsoft Connect Team.