Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: [b-table, b-table-lite]: should a row with row-details showing use `aria-details` instead of `aria-describedby`? #3801

Open
tmorehouse opened this issue Aug 2, 2019 · 9 comments

Comments

@tmorehouse
Copy link
Member

commented Aug 2, 2019

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-details attribute references a single element that provides more detailed information than would normally be provided by aria-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 by aria-details is 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 by aria-details is not flattened to a string when presented to assistive technology users. This makes aria-details particularly 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-describedby and aria-details are provided on an element, aria-details takes 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.

@tmorehouse tmorehouse changed the title [b-table]: should a row with row-details showing use `aria-details` instead of `aria-describedby`? [b-table, b-table-lite]: should a row with row-details showing use `aria-details` instead of `aria-describedby`? Aug 2, 2019

@tmorehouse tmorehouse added the Type: RFC label Aug 2, 2019

@tmorehouse

This comment has been minimized.

Copy link
Member Author

commented Aug 12, 2019

@jamart2005, @Shemetiuk, @briandhill What are your opinions on this discussion?

@tmorehouse tmorehouse changed the title [b-table, b-table-lite]: should a row with row-details showing use `aria-details` instead of `aria-describedby`? RFC: [b-table, b-table-lite]: should a row with row-details showing use `aria-details` instead of `aria-describedby`? Aug 12, 2019

@jamart2005

This comment has been minimized.

Copy link

commented Aug 12, 2019

I agree in changing aria-describedby to aria-details for modal as sometimes content of modal doesn't make sense to read as a flattened string.

I'm not aware how good aria-details support is and how it exactly behaves. I would want to see it in action to get more feel for it once we can test it out. If I understand correctly, aria-details would NOT read the contents like aria-describedby but just "make users aware of the availability of an extended description as well as navigate to it" whatever that means.

If I just go off my current understanding for it, I'm hesitant on adding both of them at the same time just so we can have a fallback because modal would behave differently(reading the content or not) depending if it is supported or not.

If some users want their modal content to be read on focus and use aria-describedby, we can probably allow them to do so as well?

@tmorehouse

This comment has been minimized.

Copy link
Member Author

commented Aug 12, 2019

aria-details would inform the user that there is more content available, and the element with ID specified by aria-details becomes a landmark/region that screen reader users can request to be read out (by using the screen reader virtual navigation)

@Shemetiuk

This comment has been minimized.

Copy link

commented Aug 12, 2019

I'm agree that changing aria-describedby to aria-details makes sense but it should be tested because I'm not sure how it would behave in different browsers with different screen readers.

About adding both aria-details and aria-describedby:
I don't like when something behave differently depends on browser etc. but I don't think that someone use at the same time Jaws/Nvda/Voice over etc. I believe that in general almost everyone use 1 screen reader with one or few browsers. So probably user won't know about different behavior. That's why I think it could be done, but still want to see how it will works.

@briandhill

This comment has been minimized.

Copy link

commented Aug 12, 2019

I feel like giving the users the choice to be able to hear more detail on something is better for everyone in the end. Have you considered keeping aria-describedby to be used as a brief description, but then having the aria-details available if necessary? I see them complementing each other more than replacing one for the other.

@tmorehouse

This comment has been minimized.

Copy link
Member Author

commented Aug 12, 2019

@briandhill from the WAI ARIA spec, if both aria-describedby and aria-details are present on an element, aria-details will take priority (meaning aria-describedby will not be read out, from what I can interpret from the spec). Although not all screen reader/browser combinations follow the spec.

@briandhill

This comment has been minimized.

Copy link

commented Aug 12, 2019

Gotcha. You could still provide both to give developers flexibility. They might have started out using only aria-describedby before then realizing they need to provide more detail. They can then add the aria-details and the browser will handle it appropriately.

@tmorehouse

This comment has been minimized.

Copy link
Member Author

commented Aug 12, 2019

Might be able to set it as a boolean flag prop, as to which one to use (defaulting to the current aria-describedby behaviour.)

@tmorehouse tmorehouse added this to To do in 2.1.0 Aug 30, 2019

tmorehouse added a commit that referenced this issue Aug 31, 2019
feat(b-table, b-table-lite): use `aria-details` rather than `aria-des…
…cribedby` when details row showing (addresses #3801) (#3992)
@tmorehouse

This comment has been minimized.

Copy link
Member Author

commented Sep 7, 2019

BootstrapVue v2.0.0 stable has been released. See https://bootstrap-vue.js.org/docs/misc/changelog

Table now uses aria-details instead of aria-describedby

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
5 participants
You can’t perform that action at this time.