When a screen reader encounters aria-describedby attribute that points to another element (by ID), it typically reads the entire contents of the target element as one big string of text.
Whereas aria-details (which also points to another element by ID), just instructs the screen-reader user that there are additional details available (which the user can "move" to that so that it can be read out).
aria-describedby would be good for short strings of text, while aria-details would be better for more complex/semantic details content (i.e. sub tables, cards, lists, etc). So it may be better to switch to using aria-details in <b-table> and <b-table-lite>. This may be beneficial if a initially rendered table has many row-details slots opened.
From https://www.w3.org/TR/wai-aria-1.1/#aria-details
Identifies the element that provides a detailed, extended description for the object.
The
aria-detailsattribute references a single element that provides more detailed information than would normally be provided byaria-describedby. It enables assistive technologies to make users aware of the availability of an extended description as well as navigate to it
Unlike elements referenced by
aria-describedby, the element referenced byaria-detailsis not used in either the Accessible Name Computation or the Accessible Description Computation as defined in the Accessible Name and Description specification. Thus, the content of an element referenced byaria-detailsis not flattened to a string when presented to assistive technology users. This makesaria-detailsparticularly useful when converting the information to a string would cause a loss of information or make the extended description more difficult to understand.
Similarly, should <b-modal> also use aria-details instead of aria-describedby to point to the body of the modal? Or perhaps, if the modal does not have header text, we use aria-describedby otherwise we use aria-details, as <b-modal> sets aria-labelelledby to point to the header text (if present)? Or if we add both, as most screen readers will prefer aria-details over aria-describedby, but for browsers/readers that do not support aria-details, it will fallback to aria-describedby?
In some user agents, multiple reference relationships for descriptive information are not supported by the accessibility API. In such cases, if both
aria-describedbyandaria-detailsare provided on an element,aria-detailstakes precedence.
This would probably need to be tested with multiple screen readers on multiple browsers to see if they pick only one of the two attributes.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4