Closed (fixed)
Project:
Webform
Version:
8.x-5.x-dev
Component:
Accessibility
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
7 Mar 2018 at 23:18 UTC
Updated:
30 Jun 2018 at 14:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jrockowitz commentedFirst off, I am totally open to any accessibility improvements. Someone may have to take the lead and start providing patches to improve accessibility.
Since the Webform module's other type elements contain radios and checkboxes that are already wrapped in a fieldset will adding a parent fieldset to these element's make things even more confusing for screen readers. Keep in mind that the Webform module can't change how core handles radios and checkboxes.
Comment #3
mfairchild365 commentedGreat questions. If you look at the module that I created, it applies the `preRenderCompositeFormElement()` trait to the other type elements and removes the default label from displaying. Core (for some reason) does not seem to wrap the radio buttons within the other type with a fieldset, so you only end up with one fieldset. So it isn't an issue.
I happy to help contribute a fix, but I will need some help in determining the best way to accomplish this. I'm not sure if my module is doing it correctly.
This is the resulting resulting HTML from my module (notice that there is only one fieldset):
Comment #4
andrewmacpherson commentedaccessibility is the preferred tag
Comment #5
jrockowitz commented@mfairchild365 Tweaking the rendered output could break some people implementation and the same time fixing accessibility issue would just justify making these types of changes.
If you are for the task, let's start out with a patch. Please make sure to see how the Bootstrap base theme handles your changes. You should also expect to be fixing a few broken tests.
Comment #6
jrockowitz commentedComment #7
jrockowitz commented@mfairchild365 Please review the attached patch.
This change is going to break webforms and websites with custom CSS selectors which target the 'webform-TYPE-other' elements.
If we all agree that it is worth making this accessibility improvement, then all we need to do is write a change record that explains why we are making this improvement.
In other tickets we might want to look at applying the same type of change to any webform or core element that groups sub-elements. This would include composites, email confirm, password confirm, datelist, datetime, etc...
Comment #8
mfairchild365 commented@jrockowitz your patch looks good to me! :) I also noticed that the other input[type="text"] doesn't have a valid label associated with it by default (you have to define one). A placeholder attribute is applied by default with the text "enter other...", perhaps an aria-label with the same value can be used if one is not explicitly defined? Let me know if I should create a different issue for this.
Comment #9
jrockowitz commented@mfairchild365 Please create a new issue for the aria-label.
Can you please create the 'Change record' with a decent explanation to why we are making this change?
If we link to https://www.w3.org/WAI/tutorials/forms/grouping/ in the change record it is going to set that stage for other accessibility related changes.
Comment #10
mfairchild365 commentedI created the change record. Please review and let me know if anything should be added/changed. I'm not familiar with the process and haven't done this before.
Comment #11
jrockowitz commented@mfairchild365 That is perfect.
I am going to mark this RTBC but I can't apply the patch until I tag hotfix release in the next few days.
Comment #13
jrockowitz commentedComment #15
Anonymous (not verified) commentedThis fix seems to add not only a fieldset on the whole component (e.g. id="edit-software-requirements--wrapper" ) but also around the checkboxes--wrapper (e.g. id="edit-software-requirements-checkboxes--wrapper" ). You can see this in the html below. By changing the fieldset with the checkboxes to a div, our cosmetic issue (see screen-shot below) goes away. Is there a reason we have a fieldset in a fieldset? While no cosmetic issue crops up in bootstrap vanilla, we get it in our boot-strap based theme https://github.com/wet-boew/wet-boew/
Comment #16
jrockowitz commentedThe attached patch removes the nested fieldsets.
Comment #18
jrockowitz commentedI committed the patch. Please download the latest dev release to review.