Check Box Label is not clickable as other check box label

[Ankit K Gupta]

Check box label of Membership tab on General Settings page should be click able as other tabs.

[Ankit K Gupta]

Patch file

[Ankit K Gupta]

Screenshot of Setting page

[SergeyBiryukov]

This would also apply to "Search Engine Visibility" and "Avatar Display" labels on other screens.

[Ankit K Gupta]

Updated patch file with "Search Engine Visibility" and "Avatar Display" labels

[toscho]

These checkboxes are labeled correctly already. Your patch would not help anyone, because "Membership" doesn’t tell the user what the checkbox does. The same applies to the other checkboxes.

This patch doesn’t solve a problem, it creates new problems.

[ocean90]

This is related to #30101/[30027], and I'm not a fan of it too. I would like to hear some insights from the accessibility team.

[Ankit K Gupta]

Replying to toscho:

These checkboxes are labeled correctly already. Your patch would not help anyone, because "Membership" doesn’t tell the user what the checkbox does. The same applies to the other checkboxes.

This patch doesn’t solve a problem, it creates new problems.

Hi toscho,
why we are using two descriptive text for single check box? We are using single label for other element like Text box. But in Check box there are two label.
If "Membership" doesn’t tell the user what the check box does. So we can use only single label for single check box.

[toscho]

Replying to Ankit K Gupta:

why we are using two descriptive text for single check box? We are using single label for other element like Text box. But in Check box there are two label.

The "Membership" is a heading, not a label. Plugins can add more form fields under that heading for additional membership options. The same applies to all the other headings. Do not mix semantics.

If "Membership" doesn’t tell the user what the check box does. So we can use only single label for single check box.

That’s the case already. I also think #30101 is a big mistake, it should be reverted immediately.

[joedolson]

Membership is a fieldset legend, and that's fine. Having two labels is definitely *not* acceptable, and this patch isn't good. A possible direction this could go would be having one label (which should be where it currently is), with an additional aria-describedby pointing to the legend, but this is not truly necessary.

In general, the settings pages need a UI overhaul for accessibility, but this isn't a good solution.

[SergeyBiryukov]

In 31281:

Revert [30027]. These fields are already sufficiently labeled; duplicate labels can lead to confused behavior for screen readers.

see #31117, #30101.

[SergeyBiryukov]

Closing as wontfix, per comment:9.

[Ankit K Gupta]

Replying to toscho:

The "Membership" is a heading, not a label. Plugins can add more form fields under that heading for additional membership options. The same applies to all the other headings. Do not mix semantics.

How can a plugin add more form fields under that heading? There are no any action and filter available to add extra fields under 'Membership' heading.

[5um17]

Replying to joedolson:

Membership is a fieldset legend, and that's fine. Having two labels is definitely *not* acceptable, and this patch isn't good. A possible direction this could go would be having one label (which should be where it currently is), with an additional aria-describedby pointing to the legend, but this is not truly necessary.

In general, the settings pages need a UI overhaul for accessibility, but this isn't a good solution.

single field can have many labels this is absolutely not wrong according to w3c as w3c only says a single label can not refer to many form elements.

[joedolson]

Whether this is allowed by the W3C is not relevant; screen readers are not capable of supporting multiple labels on an element, so the additional labels can only serve to make things more problematic. There are other methods of attaching multiple elements as labelling information that have much better support, such as aria-labelledby, and those should be used if this is going to be pursued.

[toscho]

Replying to Ankit K Gupta:

How can a plugin add more form fields under that heading? There are no any action and filter available to add extra fields under 'Membership' heading.

With JavaScript. I have done that in the past. Not very elegant, but it works.

[5um17]

Replying to joedolson:

Whether this is allowed by the W3C is not relevant; screen readers are not capable of supporting multiple labels on an element, so the additional labels can only serve to make things more problematic. There are other methods of attaching multiple elements as labelling information that have much better support, such as aria-labelledby, and those should be used if this is going to be pursued.

I agree but your first comment was confusing to decline having two labels for one elements.

[5um17]

Replying to toscho:

Replying to Ankit K Gupta:

How can a plugin add more form fields under that heading? There are no any action and filter available to add extra fields under 'Membership' heading.

With JavaScript. I have done that in the past. Not very elegant, but it works.

JavaScript is not the replacement of setting API, I agree with the wont-fix but we can not add extra settings under default settings as it is hard-coded in file.