Request all elements to have appropriate accessible names and roles assigned (accessibility)

[robeastwood-agency]

Is your feature request related to a problem? Please describe.
Raised by accessibility experts

All elements have appropriate accessible names and roles assigned.
Some interactive elements do not consistently expose their name, role, or value, making them difficult to identify and operate for users relying on assistive technologies.
For example:

• The menu of assessment forms visually resembles clickable cards but is not announced as links or buttons by screen readers.
• The “Clear” button (an “X” icon) in text input fields is inconsistently operable and announced. In the “Height” field, it is announced only as “button,” without a descriptive name.

Describe the solution you'd like
Recommendation by accessibility experts:

• Ensure use of semantic HTLM and expose roles programmatically. Be sure to provide descriptive accessible names.
• Ensure consistency across elements ensuring that text input fields have a "clear" button where appropriate and is keyboard accessible. Be sure to use aria-label to ensure that elements are announced correctly.

Describe alternatives you've considered
None

Additional context
None

[fongsean]

Hi @robeastwood-agency, I had a play around this and the current clear (X) button on text-based fields are non-focusable, due to tabIndex={-1}: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/tabindex.

The button does have aria-label of "Clear" but is never read out by screen readers because it is never focused.

Our stance on this button is we want it to behave similar to MUI's Autocomplete for consistency. That means it has the following properties:

• Hidden when field is not hovered over.
• Not focusable - to allow users to tab to the next question instead of the (x) button.
• Accessibility users can use Ctrl + A + Delete as a quick way to clear the field, like regular HTML inputs.

We won't be making any changes in this case... Does that sound ok to you?

[robeastwood-agency]

Hi @fongsean - the response from accessibility:

Yes, the clear (X) button is not reachable via keyboard-only navigation for text input fields, however they are reachable via keyboard-only navigation when VoiceOver is turned on. Sometimes I was able to reach and operate the clear (X) button via keyboard-only when VoiceOver is turned on, but most of the time I was only able to reach BUT not operate and there was an inconsistency as to whether it says “clear, button” or “clear, no action available, button” regardless of its actual operation.

This is noted to be the same for comboboxes as well.

Please refer to email from our accessibility team for a screen recording of this behaviour.

[fongsean]

Hi @robeastwood-agency, I have pushed a potential fix on v1.2.10.

I actually wasn't able to tab to the (x) button no matter what I do, with or without VoiceOver, and tried it on different versions of the renderer. I wasn't able to tab to the item headings as well (might be I don't have the most updated CHAP form).

Hence, I made the change blindly by removing a wrapper and adding aria-hidden=true to the button. In theory that should prevent the button from being "tabbed" to. Can you try it out on your end?

[MaryamMehd]

Hi @robeastwood-agency,

Checking in on this accessibility issue regarding accessible names and roles for interactive elements.

It's been about a month since this was opened with the "awaiting ADHA" label. Has ADHA provided guidance on prioritization and implementation approach for these items?

Specifically:

1. Assessment forms menu announcement (links/buttons)
2. "Clear" button labeling and consistency across text fields

If ADHA has approved moving forward, we can start addressing these issues. Otherwise, just wanted to check on the status of their review.

Thanks!