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

NVDA does not read accessible description of grouping elements #10095

Closed
Wildebrew opened this issue Aug 14, 2019 · 7 comments · Fixed by #10462
Closed

NVDA does not read accessible description of grouping elements #10095

Wildebrew opened this issue Aug 14, 2019 · 7 comments · Fixed by #10462

Comments

@Wildebrew
Copy link

@Wildebrew Wildebrew commented Aug 14, 2019

If you use aria-describedby to associate a tooltip or error message with a grouping element (a <fieldset> element or an element with role="group" or role="radiogroup") you would expect NVDA to read the value of the associated element whenever it reads the legend (or common label) of the group. This, however, is not the case.

Steps to reproduce:

  1. Open the attached .html file (it is just a static file, no Javascript or CSS validation).
  2. Move focus into the groupin element, (tab from the "Google" link to the "red" checkbox or shift-tab from the "Verify" button to the "Peppermint" checkbox.

Actual behavior:

NVDA announces the label of the checkbox and the common label of the group, "What's your favorite color".

Expected behavior:

NVDA should announce the label of the checkbox, the common label of the group and the associated error message

e.g.
"red, checkbox not checked, What's your favorite color, grouping, error! You must select at least one color"

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

NVDA 2019.2

Windows version:

Windows 7 (looks like Windows version is N/A for this issue).

Name and version of other software in use when reproducing the issue:

Verified with Chrome 74 and Firefox 60-ESR

Other information about your system:

None needed.

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

Have not tried, would expect same.

Relevant info

This works with Jaws 2019 in both Chrome and Firefox.

See also This article from Tenon (where you can see another live example).

@DrSooom
Copy link

@DrSooom DrSooom commented Aug 16, 2019

@Wildebrew: Please try to reproduce this with Firefox Portable 68.0.1. Thanks.

@Wildebrew
Copy link
Author

@Wildebrew Wildebrew commented Aug 16, 2019

@Adriani90
Copy link
Collaborator

@Adriani90 Adriani90 commented Aug 18, 2019

@MarcoZehe
Copy link
Contributor

@MarcoZehe MarcoZehe commented Aug 19, 2019

OK, I can only sort of reproduce this. If I have this snippet:

data:text/html,<fieldset aria-describedby="explainer"><legend>Address</legend><label for="name">Your name:</label><input id="name" /></fieldset><p id="explainer">Your home address</p>

and tab from the document into the grouping, I hear "Address grouping Your Home address", "Your name text field". So in this case, NVDA does read the text as appropriate that is associated via aria-describedby.

But here's the caveat: It does not read it if in virtual/browse mode and just arrowing into the group. There, as well as in many other cases, JAWS indeed does a better job of reading the associated description. So if virtual cursor lands on the legend text, for example, JAWS will read the description right along with it. Same with inputs that not only have a label, but also an aria-describedby. NVDA will ignore these descriptions in browse mode, will only read them when tabbing through the form, and thus focusing elements. It has done so forever.

I unfortunately don't have access to the file @Wildebrew attached to this issue, so I cannot test the specific use case. What I can say is that NVDA not reading the group description per se is not correct. It does read them when focus moves into the grouping from the hierarchy outside of it. It does not read the description when the reading cursor in browse mode lands inside the grouping, on the legend text, for example.

@leonardder
Copy link
Collaborator

@leonardder leonardder commented Aug 19, 2019

@Qchristensen
Copy link
Member

@Qchristensen Qchristensen commented Sep 23, 2019

I've closed #7578 as a duplicate of this issue, but felt it was worth copying @jmuheim's comments across:

"I wonder why do radio buttons trigger focus mode, but checkboxes don't?

Here's a demo with radio buttons. When tabbing to the first radiobutton, the legend's title (Gender) is announced by NVDA (as focus mode is triggered):

https://codepen.io/accessibility-developer-guide/full/WEqVdR/

Here's a demo with checkboxes. When tabbing to the first checkbox, the legend's title (Hobbies) isn't announced by NVDA (as browse mode remains active):

https://codepen.io/accessibility-developer-guide/full/aygeqR/
"

@jcsteh
Copy link
Contributor

@jcsteh jcsteh commented Sep 24, 2019

The problem with aria-describedby here is that the description itself is also part of the buffer. Having the description read as part of the legend or grouping would therefore be somewhat missleading if the description is dupplicated in the buffer later on.

We already report the legend despite the fact that it too is present in the buffer. That decision was made in #7435. I'd argue we should just extend that fix to also report the description.

"I wonder why do radio buttons trigger focus mode, but checkboxes don't?

Because radio buttons support keyboard interaction beyond simple activation; i.e. you can use up/down arrows to change the selection. That isn't true for check boxes, so check boxes don't need this. IMO, pursuing this line of thought isn't the correct path to a fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants