Improve ARIA usage for details/summary groups.

Hi. 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.

Again, 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

<details class="node-form-options js-form-wrapper form-wrapper" data-drupal-selector="edit-options" id="edit-options" open="">    <summary role="button" aria-controls="edit-options" aria-expanded="true" aria-pressed="true">Promotion options</summary><div class="details-wrapper">
    <div class="field--type-boolean field--name-promote field--widget-boolean-checkbox js-form-wrapper form-wrapper" data-drupal-selector="edit-promote-wrapper" id="edit-promote-wrapper"><div class="js-form-item form-item js-form-type-checkbox form-type-checkbox js-form-item-promote-value form-item-promote-value">
        <input data-drupal-selector="edit-promote-value" id="edit-promote-value" name="promote[value]" value="1" class="form-checkbox" type="checkbox">

        <label for="edit-promote-value" class="option">Promoted to front page</label>
      </div>
</div>
<div class="field--type-boolean field--name-sticky field--widget-boolean-checkbox js-form-wrapper form-wrapper" data-drupal-selector="edit-sticky-wrapper" id="edit-sticky-wrapper"><div class="js-form-item form-item js-form-type-checkbox form-type-checkbox js-form-item-sticky-value form-item-sticky-value">
        <input data-drupal-selector="edit-sticky-value" id="edit-sticky-value" name="sticky[value]" value="1" class="form-checkbox" type="checkbox">

        <label for="edit-sticky-value" class="option">Sticky at top of lists</label>
      </div>
</div>
</div>
</details>

Okay 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.

@mgifford, - Re: #5

I'm also a bit confused as there isn't a legend here. I think the problem is with detail/summary elements in HTML5.

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.

A couple of extra things.

1. The original report says:

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.

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

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.

I've logged #2960602: Modernize aria-detail.js semantics. for this.

There'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.