What is the meaning of the 'aria-describedby' property?

Question

The following HTML is inserted by the jQuery Grid plugin:

<td role="gridcell" style="" aria-describedby="list_createdBy">Sam</td>

What is the meaning of the 'aria-describedby' property?

Answer 1

This is described in the aria specification. It gives the id of an element that provides some additional information about the current element that some users might need.

Answer 2

Here below is an example of how you could use the aria-describedby property. It is used when you have a text that has information about the element. Aria-describedby must be the same as the id of the text that describes it.

First name: <input aria-describedby="name" type="text"> <em id="name">Your first name must be correct.</em>

Answer 3

At the first glance I'd say aria-describedby is likely to be ignored here because it's defined on <td>. Most browsers and screen readers will ignore aria-describedby information when set on element which is not interactive (focusable).

But the specific example a bit more complex due to role="gridcell" which overrides the semantics of <td> and therefore the provided example is valid if it follows the ARIA specification for gridcell. It's a custom component.

Generally speaking the attribute aria-describedby provides the screen reader with the additional information to be announced along the content of the element (not the only but the most common use-case).

For example instead of only "Logout" the screen reader will announce "Logout, John Doe":

    Logged-in as <span id="user">John Doe</span>.
    <a aria-describedby="user" href="/logout">Logout</a>

Or example with a tooltip (Hint: Javascript part is missing here):

    <button type="button" aria-describedby="my-tooltip">Snipping Tool</button>
    <div hidden id="my-tooltip" role="tooltip">
        It can take still screenshots of an open window,
        rectangular areas, a free-form area,
        or the entire screen.
    </div>

Or example with a form element, another common use-case:

    <form ...>
        <label for="my-name">Full name</label>
        <input aria-describedby="my-name-desc" id="my-name" type="text"/>
        <p id="my-name-desc">
            Please tell us your full name.
        </p>
    </form>

The example above will announce both <label> and the additional description (defined by aria-describedby) immediately when a user focuses the input field. Not only that it eliminates a need to read the surroundings to be able to understand what is expected to enter but also reading all elements other than form controls when inside of the <form> might be more complex for a screen reader user. It's a different experience then reading the rest of the page. Because keyboard events can either interact with screen readers or with form controls, but hardly with both in the same time. Not to mention that screen readers offer bunch of useful keyboard shortcuts for example pressing "H" will jump to a next heading but obviously not when <input> field is focused. Then "H" will be entered into <input>.

About ARIA:

• ARIA is commonly used to improve the accessibility for screen readers (not only but mostly atm.).
• Using ARIA does not necessarily make things better! Easily ARIA can lead to significantly worse accessibility if not implemented and tested properly. Don't use ARIA just to have some "cool things in the code" which you don't fully understand. Sadly too often ARIA implementations introduce more issues than solutions in terms of accessibility. This is rather common since sighted users and developers are less likely to put extra effort in extensive testing with screen readers while on the other hand ARIA specs and validators are currently far from perfect and even confusing in some cases. On top of that each browser and screen reader implement the ARIA support non-uniformly causing the major inconsistencies in the behavior. Often it's better idea to avoid ARIA completely when it's not clear exactly what it does, how it behaves and it won't be tested intensively with all screen readers and browsers (or at least the most common combinations). Disclaimer: My intention is not to disgrace ARIA but rather its bad ARIA implementations. In fact it's not so uncommon that HTML5 don't offer any other alternatives where implementing ARIA would bring significant benefits for the accessibility e.g. aria-hidden or aria-expanded. But only if implemented and tested properly!

About aria-describedby

• Provides the additional information along the content of the element
• Works as expected on focusable elements (e.g. button, input, a). Mostly useless on other elements ("mostly" there are exceptions)
• IE 11 is a bit tricky. Sometimes it's ignored. It might make a difference if implemented on a or button as well if referenced element is hidden (display:none), its position (is the inner element referenced?) or if it has tabindex="-1" or role (e.g. role="none") on it etc. Make sure to test all screen readers
• Might behave differently if a screen reader is used in a focus mode (TAB key) or virtual mode (reading the content with ARROW keys)
• Both Firefox and Internet Explorer respect aria-describedby only in focus mode. As such, it does not make sense to add it to non-focusable elements. From: ADG
• While NVDA announces descriptions right away, JAWS sometimes prompts to manually press JAWS+Alt+R to announce it. From: ADG
• If referenced element is hidden it's not searchable with Ctrl+F (which is a common way the users like to navigate the website to quickly find what they look for). From: ADG
• The only case where we truly recommend the usage of aria-describedby, is to attach additional information to interactive elements (e.g. to relate visible information e.g. to form controls). From: ADG
• Good idea: Using combination of aria-describedby (on a form control) and role="alert" (on a SPAN) for a form control error. From: W3.org