fix: aria-describedby isn't recognized by SRs in fast-button

[bennyrags]

🐛 Bug Report

When a user adds the aria-describedby attribute and value to the fast-button element, the attribute appears on both the fast-button element and its button child element. This dual use appears to break the aria-describedby functionality. This is an important for screen readers, which use aria-describedby to tie a focusable element, such as a button, to another element that contains important additional information.

A good use case for this is the fast-tooltip component. Someone creating an accessible tooltip needs to programatically bind the fast-tooltip to the element that the fast-tooltip is providing more information for. This is done through aria-describedby, but it is not working if I add aria-describedby to the fast-button element. However, If I add aria-describedby to simple button element, and tie it to the id of fast-tooltip, it is read by a screen reader.

This may be a broader issue for focusable elements: fast-anchor, fast-checkbox, etc, and for other aria- attributes. I've only tested aria-describedby with the fast-tooltip and fast-button components.

This is a similar issue to #6041.

💻 Repro or Code Sample

• Go to fast-tooltip
• Add an id to the tooltip
• Add aria-describedby to the fast-button element, make its value equal to the tooltip id
• Open Chrome devtools
  • notice the aria-describedby attribute is present on the fast-button element and its button child
• Run a screenreader and focus on fast-button. You will not hear the tooltip content announced
• Replace fast-button with button in the code editor, while keeping the aria-describedby attribute on the button
  • Run the screenreader. Focus on the button. You should hear the tooltip content read aloud

🤔 Expected Behavior

A user who needs to add additional information to a fast-button or other focusable element should be able to add aria-describedby as an attribute with a value, or pass a value to a prop, and have the contents of the bindeded element read aloud by a screenreader when the fast-button is being focused upon.

😯 Current Behavior

If a user attaches aria-describedby as an attribute to fast-button, the attribute appears on both the fast-button element and its button child. A screenreader does not read the tooltip content.

However, if a user attaches the same attribute to a button element and runs the screen reader, the fast-tooltip content is read aloud.

💁 Possible Solution

I'm new to FAST, but a possible solution would be to add an option to fast-button and other focusable elements that allows users to pass an aria-describedby value as a prop, which is then added as an attribute to the shadow root child, in this case button.

🔦 Context

This issue has serious accessibility implications. A focusable element that requires additional information needs an aria-desciribedby attribute that is binded to the id of an element that is providing additional information. The fast-tooltip component is a perfect example, because its purpose is to provide additional information to a focusable element.

If there is no bind between the focusable element and the element that holds the additional info that describes it - or, as in this case, if the bind isn't working - screen readers will not know the two are connected, and will not read the additional information when the focusable element is being interacted with.

🌍 Your Environment

• Browser: Chrome 105
• NVDA 2021.3

[chrisdholt]

Thanks @bennyrags - we're aware of this but will use this as a tracking issue for our current vNext work. We're looking at discussing and addressing the approach here. Just an FYI that it may be that we change how we've implemented tooltip or we update to move away from delegatesFocus due to the current gaps with cross root ARIA.

We'll use this issue to keep the discussion going and the community up to date.

[MathisPct]

💁 Possible Solution

I'm new to FAST, but a possible solution would be to add an option to fast-button and other focusable elements that allows users to pass an aria-describedby value as a prop, which is then added as an attribute to the shadow root child, in this case button.

For that solution you have suggested, it can not be works for now :( . Indeed, both fast-button and fast-tooltip have their own shadow root. Because of that specificity we face to the shadow DOM boundary problem.

@chrisdholt Do you have some news about a possible solution ?

(We are facing same problem within my team. We also have a *-button' component which encapsulate a native button inside its tree and a *-tooltip' component)

[olaf-k]

@chrisdholt Do you have some news about a possible solution ?

(We are facing same problem within my team. We also have a *-button' component which encapsulate a native button inside its tree and a *-tooltip' component)

the probable path ahead is cross-root Aria capability (which @chrisdholt has participated to). it's only at proposal stage at this point unfortunately.

[janechu]

Unfortunately @microsoft/fast-foundation is being deprecated, refer to #6955. I see this was mentioned in a PR, we will be addressing open PRs and merging what we can before we snap an archive branch to preserve the latest state of Foundation, however to bring us up to date I am closing out issues.