"Legends for certain fields are not announced by JAWS. As an example, within the “Create Basic page” screen, the “Promoted to front page” checkbox is announced by JAWS as “Promoted to front page checkbox not checked” instead of announcing the legend as, “Promotion Options, Promoted to front page checkbox not checked”.
This defect exists in IE11 and Google Chrome Version 55.0.2883.87 m.
Expected results: All legends are expected to be announced by JAWS. In this instance, JAWS is expected to announce the legend, “Promotion Options” as “Promotion Options, Promoted to front page checkbox not checked”.
Reference: Section 508, Part 1194.22, Paragraph (n).
Notes:
• This defect also exists elsewhere within the application.
• This defect exists on a screen that is not accessible via a keyboard. The user is forced to use the mouse to access this screen, which is not acceptable for a JAWS user.
Comment | File | Size | Author |
---|---|---|---|
#5 | Screen Shot 2017-02-15 at 11.17.37 AM.png | 47.5 KB | mgifford |
Comments
Comment #2
cilefen CreditAttribution: cilefen commentedHi. Welcome to the issue queue. Just for your information, if you assign yourself to an issue, people assume you are working on the code fix.
Comment #3
cilefen CreditAttribution: cilefen commentedComment #4
kershme CreditAttribution: kershme commentedComment #5
mgiffordAgain, Section 508 is changing to WCAG 2.0AA.
I'm also a bit confused as there isn't a legend here. I think the problem is with detail/summary elements in HTML5.
This is the HTML from /node/add/page in 8.3
Comment #7
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedOkay so this looks like a spurious report, based on confusion between fieldset/legend and the new HTML5.1 details/summary.
The only examples specifically mentioned here are the node form meta data, which are all details/summary. The issue summary also notes that the issue exists elsewhere in the application. We are using details/summary quite liberally across our admin UI.
We now only use fieldset/legend sparingly (radios, and compound widgets like date/time) to avoid screen reader problems with nested fieldsets. In any case, fieldset/legend announcements vary considerably between different screen readers, so this is probably out of scope for Drupal core to address.
As far as details/summary go, I think there is room for improvement to align them better with the HTML Accessibility API mappings. That's currently a W3C working draft, and AFAIK no current browsers implement it yet. It's bleeding-edge, so it isn't really the fault of Drupal, browsers, or AT. Our present
aria-details.js
is out of sync with the roles + states suggested in the editor's draft, so we can make an improvement there. However we should proceed slowly, and wait for the drafts to stabilize.TODO:
- Update this issue summary, make this issue about improving
aria-details.js
in line with HTML Accessibility API mappings. Update (2018-04-13): No, do that in a new issue. There are red herrings, here, let's close it.- possibly postpone this until the W3C docs stabilize.
- Close off any old details/summary issues as outdated.
Comment #9
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commented@mgifford, - Re: #5
It's because they are separate fields, as far as Form API are concerned. They are two separate FAPI
#type="checkbox"
elements, not a single FAPI#type="checkboxes"
element. The "promote to front page" and "sticky at top of lists" are separate properties on the node entity. They just happen to be presented in the same grouping container on the node form.In D7, the publishing options were separate FAPI
#type="checkbox"
elements, grouped inside a#type="fieldset"
container.In D8, the publishing options have had a lot of refactoring, and are now BaseFieldDefinitions on the Node entity. But by the time it gets to rendering, they are still separate FAPI
#type="checkbox"
elements. What's changed is that the grouping container is no longer a fieldset, it's a HTML5 details, or FAPI#type="details"
In D8 a FAPI
#type="checkboxes"
element will still get the HTML fieldset and legend. You can still have that if you create a Field API "list", multi-valued, with a checkboxes/radios widget. But that's not what we have here in the node publishing options.There's no requirement in HTML or WCAG for 2 consecutive checkboxes to be grouped inside a fieldset with a legend. They don't have to be next to each other at all, for that matter. The "published" checkbox has moved to a different part of the form, but it was in the D7 fieldset.
I think this is a non-issue, maybe a misunderstanding about expected behaviour, based on the visual appearance, or the way that the D7 node form used to behave. Works-as-designed I'd say.
Because the alternative is to say the data model of the node entity is somehow wrong, because it doesn't match an idea of what the form could or should look like. That doesn't hold water.
Comment #10
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedA couple of extra things.
1. The original report says:
I don't know what that's about, the details/summary elements work well in most screen readers I tried them in. Summary announced as button, with open/closed state, and they open correctly. I think it's copy pasta from another report. There was a bunch of these 508 issues , arrived in a batch.
2. In #7 I said
I've logged #2960602: Modernize aria-detail.js semantics. for this.
Comment #11
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedThere's a lot of cross-over between this and #2951714: radio buttons and checkboxes should be grouped by fieldsets, but that issue is phrased more like a "what's best?" than the "this is a defect" phasing here.