Do not use aria-details for InputControl and BaseControl

[afercia]

Description

Splitting this out from #56381 (comment)

#45931 and #46170 introduced conditional logic in the InputControl and BaseControl components to use either aria-describedby or aria-details for the help prop.

I have to note that both PRs change an important accessibility feature but they aren't marked with any accessibility label. I'm not sure that's the best way to encourage participation and contribution to this project. More importantly, both PRs introduced a regression in the level of accessibility that could have been prevented by asking feedback to contributors more familiar with accessibility.

Why aria-details is a problem

Semantics

First of all, semantically aria-details is meant to be used to provide 'a detailed, extended description'. In most of the cases, the help text is not a detailed, extended description. It is pretty short actually. Which makes aria-details semantically inappropriate in the first place.

Poor support

More importantly, aria-details has poor support. This was also noted in a comment on the InputControl PR. I'm not sure I understand why, although acknowledging aria-details has poor support, it has been implemented regardless thus providing users with a subpar experience.

a11ysupport.io is a good source to check actual support for accessibility features. Tha latest tests for aria-details are from 2022-09-16. Thet clearly show that:

• VoiceOver and Talkback have no support at all.
• JAWS and NVDA have only partial support.

Thus, the change that makes conditional use of aria-details actually provides a regression in the level of accessibility for a relevant part of screen reader users.

Screenshot of the table from a11ysupport.io that illustrates actual screen readers support:

aria-details is not an equivalent of aria-describedby in terms of interaction and user experience

In order to get the description provided by aria-details, (quoting) it is necessary for the user to navigate to the container referenced by aria-details to view and interact with the content of that description. This differs from aria-describedby, which is part of the naming calculation for the element that has focus, and where it is not necessary to move focus away from that element to hear the description.

The ARIA 1.2 documentation clearly states that aria-details doesn't take part in the accessible description computation.

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.

What does that mean? Theoretically, if it worked, when users land on a control that has an aria-details attribute, the screen reader should inform users that 'this element has a description' and provide a mechanism to jump to the description so that users can read it. This is not what we want.
Instead, we want a control's description to be announced automatically by screen readers when users land on the control. That is what aria-describedby does, because it does take part in the accessible description computation.

As such, even if it worked for all browsers and screen readers, aria-details would provide users with an experience that is entirely different from the one provided by aria-describedby and it's an experience that is clearly less efficient.

Rationale behing the conditional use of aria-details

It seems to me the conditional use of aria-details is based on a wrong assumption. The condtiion is:

• if the help prop is a string, use aria-describedby
• if the help prop is a component, use aria-details

An example of a component passed to the help prop can be seen for the PostURL component.

If I undeerstand correctly, the reasoning was that ARIA descriptions actually require plain text so that it was assumed that hen a description contains markup, it should use aria-details.

Seems to me there's some confusion regarding the usage of aria-describedby and aria-description.

• aria-description: it's part of ARIA 1.3, which is not a finalized W3C recommendation yet. As such it can't be used. It is true that is accepts a string, much like aria-label, but we can't use it anyways.
• The component was using aria-describedby in fact. aria-describedby accepts one or more ID references that point to other elements. The references elements can contain markup. The browsers already flatten the referenced elements content to a string that does not contain any markup.

As such the assumption that 'ARIA descriptions actually require plain text' appears to be wrong, as these components were using aria-describedby.

This change should be reverted, and the documentation updated accordingly

Cc @ciampo @mirka

Step-by-step reproduction instructions

• Go to the post editor and edit a published post (we need to access the post slug editing UI)
• Click 'Link' in the setting panel > Post tab, to open the permalink popover.
• Inspect the input field to edit the post slug.
• Observe there is an aria-details attribute that points to the paragraph that contains the full permalink below the input.
• Use Safari and VoiceOver, navigate to the input field.
• Observe the screen reader doesn't announce in any way the input field has a description.

I'm pretty sure there are other instances where the help prop is getting passed a component, thus rendering an aria-details attribute. Optionally test these other instances as well but that's not strictly necessary.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

Screenshots to illustrate the different behavior of aria-details and aria-describedby.

As mentioned above, even if aria-details had good sipport, it provides a different mechanism for descriptions. The browser doesn't provide any compouted accessible description. Screenshot from Chrome dev tools inspetor, accessibility tab:

aria-describedby does:

[afercia]

Noting that the aria-details thing, besides being incorrect and unnecessary, doesn't work tor the TextareaControl which renders an aria-describedby attribute anyways even when the help prop passes a component. This is the case, for example, for the Image, Cover, Media & Text blocks. They all pass an ExternalLink component to the help prop but they render an aria-describedby attribute.