radio button question label not displaying for screen reader "form" view

[ekressmiller]

Tested again using NVDA and Narrator screen readers after updating to Docassemble 1.4.103.

Still no label for radio buttons:
NVDA:

Narrator (the built-in Windows screen reader) seems to have a similar issue:

This is what it looks like when there is a label:

Note the label "for" tag exactly matches the "id" and also the "name" of the input box. I'm wondering if you can do something similar with the "legend" to tell it what to attach to?

[ekressmiller]

Note, did a little googling on this issue and have not yet found an example addressing how to . And some of the accessibility tutorials I can find seem to have the same issue.

So I wonder if this might simply be how things currently tend to work with screen readers and radio buttons?

e.g. the radio buttons here and here appear to have the same issue. But both are also several years old.

[ekressmiller]

interesting example from SSDI application. They include the question label in the first radio button label. Wonder if that's an intentional workaround?

[plocket]

I would love to see info from a different screen reader or find documentation on how the screen reader expects this problem to be handled. What version of the NVDA screen reader are you using? I'd love to find out more about it.

The examples of HTML from docassemble and other sites that you gave are "right" in that they implement what I understand is the specification for a group of fields. That is, the official accessibility standard and the one that the UK government uses. In those specs, the element that's supposed to describe the whole group of radio buttons is the <legend> element while <label> elements are supposed to be for individual fields. The screen reader is supposed to recognize <legend> and associate it with the fields.

The SSDI form might be using this trick to include visually hidden text that the screen reader is able to read. As you can see in that reply, there are many inconsistencies with screen readers, though the exchange at that link seems to say that NVDA should be recognizing <legend>.

There are other ways, like the above, to get around this too, I'm sure. They're very hacky and don't align with the spec. I don't think docassemble does any of them and it's already doing the right things from what I can see. Not sure what to do about that. Maybe it would be reasonable enough to ask for an additional aria-labelledby attribute to be added to every fieldset field. It might be something we could implement ourselves and submit in a pull request. That said, I'm not sure every screen reader would recognize that either. It would be nice to have some proof of that before diving into that rabbit hole.

[plocket]

Further findings: I don't know about what requirements the researchers identified. I think docassemble's fixes did try to address those. I think the implementation may need some tweaking. An automatic accessibility checker dislikes them and, after doing some research, I think I agree with the checker and I might be able to make changes that align with both.

For example, we can see from the images that fieldset has aria-required="true", but no role="radiogroup" while a lower div has both. From what the MDN describes about aria-required, I believe fieldset should have both and the div should have none.

I don't know if changing that will change the behavior of the screen reader. Like you said, @ekressmiller, maybe screen readers aren't yet up to this challenge. It's a change I need to make anyway, though, so we can at least try a mock up and see how it goes.

[jhpyle]

I don't have access to the testing tools you are using. Can you test this interview?
https://demo.docassemble.org/start/base/examples/radio-list
I moved the role="radiogroup" and aria-required="true" to the <fieldset>. (These changes aren't on PyPI or GitHub yet.)

[ekressmiller]

The test interview still shows up as "unlabeled" on the form fields view.

NVDA (v 2024.1.0.31547):

Narrator (note, the fact that Narrator doesn't even seem to have a place this label would go is one of the factors that makes me wonder if this is just the status quo for radio buttons):

[ekressmiller]

Although (responding to my own comment about Narrator), maybe Narrator is not a good model for what a screen reader should provide.

[plocket]

A shame Narrator is having trouble. It does pass aXe tests. I use this free chrome extension for quicker aXe testing.

[ekressmiller]

That article about Narrator's a bit old so I suppose it's possible it's better now.