Introduced in ARIA 1.1, aria-details is meant to help convey that there is additional information available for a particular element a user is interacting with.

Initially one may think aria-details could be synonymous with aria-describedby, especially if familiar with roles like presentation and none. While related, these attributes serve different purposes.

  • Content that is referenced by aria-describedby is flattened to a text string. This string is appended, as descriptive text, after the accessible name and role of an element have been announced by screen readers. A use case for aria-describedby could be to announce content that may appear visually, but can’t be accessed by a screen reader if focus were to move away from the current element (a tooltip for a form control, for example).

  • aria-details does not contribute to the computation of an element’s accessible name or description. Instead it is meant to indicate that more details exist and should be reviewed. Referencing details in such a manner can be useful if the semantics of the content (lists, buttons, images, etc.) are important to comprehension.

Testing out the attribute

The following examples have been tested with various screen reader and browser combinations to determine aria-details current level of support. Results of these tests are noted following the outlined examples.

Example 1: Details for a password field

  • Passwords should consist of an anagram of the longest word you can think of.
  • Passwords should be forgotten, immediately.
  • Passwords should included at least 6 special characters.
Example 1 Markup 
<label>
  Password:
  <input type="password" aria-details="pw">
</label>

<ul id="pw">
  <li> content goes here </li>
</ul>

Example 2:

A computer

Review more information about computers.

Example 2 Markup 
<!-- based on example 18: w3.org/TR/wai-aria-1.1/#aria-details -->
<img src="https://picsum.photos/200/300?image=0" 
  alt="A computer" aria-details="img_detail">
<p>
  Review more 
  <a href="https://en.wikipedia.org/wiki/Computer" 
    id="img_detail">information about computers</a>.
</p>

Test Results

The examples were tested with the following screen readers:

  • NVDA 2018.1 to 2018.3.2
  • JAWS 18 and 2018 (latest releases)
  • Windows Narrator (Windows 10)
  • VoiceOver (iOS 12)
  • VoiceOver (macOS High Sierra)
  • TalkBack (Android Accessibility Suite 6.2)

At a high level, support for aria-details is sparse, with only JAWS 18 & 2018 providing any level of support for the attribute. However, even the support that JAWS provides is (imo) rudimentary at best.

For instance, when an element has aria-details, JAWS will announce “Has details” but provides no indication in where those details may be located in the DOM.

Depending on how you enter an element, JAWS will likely announce “Entering details” when navigating into the element or component providing the related information. Where this may not prove to be true, is if you enter an element via hot key. For instance, navigating to a list by the I key (list item key), rather than navigating directly to the list (with the id aria-details references).

JAWS will also announce “Leaving” when the virtual cursor has reached the end of the details component.

These announcements may provide a passable experience, if there are no other elements with associated details in the current document. However, if a document contains more than one element with details associated with it, those details better be located directly next to the element requiring the further explanation. Otherwise it could be possible for a user to potentially enter details for a different element.

Additionally, the ARIA specification notes:

In some user agents, multiple reference relationships for descriptive information are not supported by the accessibility API. In such cases, if both aria-describedby and aria-details are provided on an element, aria-details takes precedence.

Regarding the current level of support with the tested screen readers, this situation did not arise. However, more testing should be conducted.

Breakdown of support
Example 1: JAWS 18 & 2018 + IE11, Firefox 63.0.1 and Chrome 70

No announcement of "details" made when navigating to the password field by virtual cursor.

Announces "Has details" when focusing password field via Tab key, or via form controls quick key.

When entering the list with the virtual cursor, JAWS announces "Entering Details".

When navigating to a list via the L key, there is no announcement of "Entering details", until navigating to the first list item (by virtual cursor or I key).

If navigating to a list's first item, via the I key, and without navigating to the list first, then there is no announcement of "Entering Details".

When existing the list with the virtual cursor, JAWS announces "Leaving".

Example 2: JAWS 2018 + IE11, Firefox 63.0.1 and Chrome 70

Announces "Has details" when navigating to graphic by use of virtual cursor or G quick key.

When navigating to the link, via virtual cursor or Tab key, the link's announcement will be accompanied by "Entering details".

If navigating by Tab key, directly from the password form control to the link, no announcement of "Entering details" will be made.

Example 1 & 2: NVDA + Firefox 63.0.1 and Chrome 70
Example 1 & 2: JAWS 2018 + Edge (latest)
Example 1 & 2: VoiceOver (macOS) + Safari 12
Example 1 & 2: VoiceOver (iOS) + Safari
Example 1 & 2: Windows Narrator
Example 1 & 2: TalkBack + Android Chrome & Firefox

Availability of aria-details is not announced.

Not enough details?

With the large gap in support across various different screen readers, and the current implementation with JAWS, aria-details won’t consistently, or meaningfully, provide the context for which its potential should allow.

Here’s to hoping that it will receive quick adoption and become a useful addition to providing more informative user experiences.