Wrap composite elements in a fieldset element

I don't particularly think this is a big deal. The label for radio buttons or checkboxes as a group is not associated with a field that's true, but then every individual radio/checkbox has another label that is associated with each option.

Other options for passing this "accessibility" test could be placing the entire set of options in a fieldset and give the fieldset the title of the select options. Then edit the select options component and check the box for "Hide title". Effectively this makes it so that the fieldset has the title instead of the checkboxes/radios.

Now this is pretty much a farce of accessibility that will make it pass your test but will probably be more obnoxious than helpful. Once placed in a fieldset, screen readers will read the name of the fieldset before every option. So for example if you had "food options" as the fieldset title and "breakfast", "lunch", "dinner" as checkboxes.

Current: "Food options [pause] checkbox breakfast [pause] checkbox lunch [pause] checkbox dinner"
With fieldset: "Food options [pause] checkbox breakfast [pause] Food options [pause] checkbox lunch [pause] Food options [pause] checkbox dinner"

But users that utilizes screenreaders a probably use to the overly verbose and unnecessary repetition caused by "accessibility improvements".

The related radio buttons or checkboxes should be grouped with a fieldset and the label should be a legend, thus expressing the semantic structure of the form. In the HTML standard, the @for of a label element needs to point to a form control. I have attached a patch to webform 7.x-3.9 which changes theme_webform_element so that it wraps child elements in fieldset and legend. Part of the patch is a bit of CSS which removes the impact on layout of the new fieldset.

@Liam Morland: Putting this into Webform first is the incorrect order of things. The first place (if it happens) would be Drupal core. I won't be putting this into Webform as the default markup for practical reasons around expected markup for radio buttons/checkboxes. If we do this it would require all themes to accommodate two styles of markup for forms: Drupal core and Webform.

Thanks, quicksketch. I have submitted a patch for this against Drupal 8. See #504962: Provide a compound form element with accessible labels .

Liam, do you think it can be brought into http://drupal.org/project/accessible so that we can have a solution here within Drupal 7?

I'm working on it, but I will probably not have anything to show until after my vacation, so it will be early July.

No rush, enjoy your vacation!

D7 Accessible Helper Module version of this patch: #1195418: Use fieldset and legend for theme_date theme_checkboxes and theme_radios

Marking as postponed. As quicksketch says, this won't go into Webform until it goes into core. A patch against core has been submitted for D8, but will not likely get backported. For D7, use the Accessible Helper Module.

Bumping this to D7, mostly so that it doesn't get lost. It will probably just work out of the box with D8, although we still need to get in the patch the @Liam mentioned.

I'm wondering if there is a way to eliminate the theming concerns that have been raised.

The Accessible Helper needs help for this. It's not yet in the dev release:
#1195418: Use fieldset and legend for theme_date theme_checkboxes and theme_radios

It's sounds like that will work.. Least until D8 when I hope it's just managed by core.

I've been having to use the fieldset as the label option and it's not great. Is that still the best option available? Any word on if D8 will address this?

This patch needs help with the simple tests:
https://drupal.org/comment/7952865#comment-7952865

Which also depends on:
https://drupal.org/comment/8212499#comment-8212499

But I think that last one is RTBC.

Now that some Fieldset support has been added to Drupal 8.x core -- e.g. https://www.drupal.org/node/1932074 -- is it time to restart this work on Webform module?

Fixing this issue with radio and checkbox accessibility in Webforms would be a big boost for accessibility. It's a requirement.

Makes sense to me.

Patch needs a re-roll and some volunteers to test it.

Here is a straight re-roll of the patch in #3. However, the CSS does not remove all the styling now given to legend elements by core. More of the core CSS would need to be reset for this patch to have no visual impact.

My gut feeling is that we won't be able to get a satisfactory solution for D7 because it has too much impact on styles. Thoughts?

The maintainers have decided to defer all aria issues to D8. They are marked postponed because they will be looked at after the D8 port is functional.

I'm not sure I agree with quicksketch that this is not a big deal. In spite of six years of delaying issuing any specific guidance for site accessibility, the Department of Justice has continued suing various businesses and government agencies for having inaccessible websites. But even without their official guidance, it's clear what criteria they would apply to test for site accessibility. Of the 16 cases I found which they settled in 2015 and which touched on site accessibility, every one of them required conformance with WCAG 2.0 Level AA.

Webform's default behavior violates WCAG 2.0 Level AA.

With Webform 7.x you cannot solve these violations by moving the select options into a fieldset. If you do create a fieldset for your select options and move them into it, the topmost label is not associated with a form control (which is incorrect HTML) and is also redundant with the fieldset legend. Then if you suppress the topmost label so that it's not redundant with the legend, it also suppresses the red star which tells the user whether a specific field is required. And, in spite of that, it still sends the incorrect (and redundant) HTML to screen readers.

I look forward to the D8 release and the possible D7 port (but I'm not good with PHP so almost certainly can't help with that work).

@DanChadwick the patch in #21 doesn't involve ARIA from what I could see.

ARIA is used (a bit) in D7 core and finalized in 2014.

@johnofjack anyone should be able to apply the patch provided if they need to meet this guideline. Ideally it would be done by default though.

Error messages are still a big concern for meeting WCAG 2.0 AA and still need a lot of support in Core, even in D8.x

Closing to clear out the old Webform 8.x-4.x branch. See #2827845: [roadmap] YAML Form 8.x-1.x to Webform 8.x-5.x.

This issue should not have been postponed. This is not ARIA, it is very basic accessibility and the webform module is doing it incorrectly. I've been trying to re-roll the latest patch, but have thus far not been successful. If this has been fixed in 8.x, it needs to be backported immediately. All of our sites are failing accessibility reviews because of this problem, and for a public institution, this is not acceptable.

Here is what I think is an accurately re-rolled patch, but a bit has changed, so I'm not sure. If the original author if the patch could review it, that would be extremely helpful.

This one looks like it might be more correct. Maybe.

There are still some issues here. One is that fieldsets around required radio groups do not seem to retain any classes or styles that indicate that they are required, and I'm not yet sure what the best practice for this is. I'm sure it would not be too difficult to work out.

Oh, and user-created fieldsets seem to lose their child fields when they have inline labels with this patch. Not sure why. More work is needed.

To solve your immediate problem, you can probably put fieldsets around your radio buttons. Solving it properly should be done in core first since Webform follows the core form API. Fixing it may break themes due to what has to be done to make the fieldset have no visual impact. For this reason, it may not be feasible to do for D7.

I think there is a close to 0% chance of this being changed in D7 core at this point, so I see nothing wrong with trying to fix it here. Also, webform may use the form API, but it overrides the form element theme function, and there are plenty of changes and omissions in it that I am not familiar with. If they are fixed in core, then this patch would be rendered obsolete, which would be fine.

Here is an updated patch that addresses the issues I mentioned in #29

The same theming issues exist if it is fixed in Webform. It could be done controlled by a configuration variable with the default being that it performs as it does now.

I definitely get it. Accessibility usually takes a backseat to pretty much everything else. If the best case here is that people can find this patch and use it, then that's better than nothing, because waiting for a core fix that will never come is not going to cut it for many of us. If adding a config variable to control this would allow it to be committed, then I can look into making that happen.

I wish I could just fix it for everyone, but I know it will create compatibility issues with some themes. It would be great if you can make this patch work with a config variable. It could be set in the site-level Webform config.

This patch adds the new config option.

looks like this new variable needed to be added to webform_variable_get, as well.

Thanks for the patch. This needs to use theme_form_required_marker(). Please check the coding standards. There is no point using empty() on $has_element_children since it always has a value.

Thanks @Liam Morland for catching that & @chrisgross for writing up the patch.

This will need a re-roll due to the refactor above.

Here is a re-roll. The CSS needs some work for the new legends to look the same as they do without the patch.

New version with CSS updated so that output appears the same as Garland. I would appreciate it if others would give this patch a try and post here how it works for them.