Single checkbox design consistency

[afercia]

For better readability, design consistency, and typography, any field in the Settings pages uses some bold text before the field. This also helps while visually scanning the page.

Text fields, textareas, selects, etc. can use their associated label as "bold text" before the fields.

Radio buttons are always more than 1 and when grouped in a <fieldset> element, they can use the fieldset <legend> element as "bold text". Same goes for checkboxes when more than one.

Single checkboxes instead don't have any semantic element that can be used as a "bold text" before the checkbox. Their associated label is on the right and must stay on the right.

We should explore what the best option is. Is it acceptable to print out some text that is used just for visual purposes (hidden from assistive technologies with aria-hidden="true")? Would that be easy to understand for people going to use the Settings API? Would it be abused?

Screnshot to illustrate the issue:

Worth nothing in this specific case the checkbox and the "New User Default Role" select are actually logically related, thus they should be within a <fieldset> so the text "Membership" (maybe consider a better wording? ) could be a <legend>. There are other cases where this is not the case though, and the issue stands.

Worth also considering that the "Anyone can register" checkbox and the "New User Default Role" select aren't so strictly related to "General settings" and probably should go in a "Membership settings" section/page. This wouldn't solve the issue of the "bold text" though.

Personally, I think single checkboxes are always a bit tricky and maybe worth exploring if this kind of setting can use a different control. Comparing with the multisite settings, there are 4 registration options, where one of them is "Registration is disabled".

So there's some inconsistency with the registration setting on a single site installation. For analogy then, maybe single site should use two radio buttons?

• Registration is disabled
• Anyone can register

[felixarntz]

This is tricky indeed. I like going for a two-radio-button solution as you proposed, but regardless of that we need to figure out how to deal with single checkboxes in general.

I don't see a problem with a visual title (with aria-hidden), like it happens now. It provides visual consistency with the other fields without confusing screen reader users, and it is handled automatically for the single checkbox callback, so users don't even need to know that that title is hidden from screen readers. Using a fieldset for a settings-section would be possible, however I'm not sure how this can easily be conveyed through an API like the Settings API. If we find a way to make this easily understandable for developers, we can think about that. Also related: What happens if a fieldset section contains a radio group (another fieldset) (see #7)?

[afercia]

Just for reference, there is in core only one usage of a single checkbox without the "left column with pseudo-label":

[felixarntz]

I think we should try to figure this out for the initial prototype.

I now agree that we should not support an extra title for a checkbox that already has a label. This should however involve reorganizing some of the fields into specific sections, because these checkbox fields without any heading look bad, as discussed before.

The above screenshot is a positive example of what that can look like.

[felixarntz]

I think for the most part, we only need to continue to follow the above pattern (do not provide an additional "title" for a checkbox) in regard of that ticket (see for example #28).

As a general task to be able to close this ticket, I think we only need to do a single change: Instead of only setting the skip_title_screen_reader argument to true when adding a single checkbox field, we should also set the skip_title argument to true. We can then furthermore adjust the underlying implementations for the screens to not pass the argument manually, as it will essentially become the default.

Does that sound good to you @afercia?

[karmatosed]

Are we talking about:

I think we should avoid this type of bolding. I think we should have bold on all labels and then remove bolding from content like this.

[felixarntz]

@karmatosed The discussion here is only about the semantics.

I already made the checkbox label normal font-weight in #32, and will make the actual field titles bold (see #33). The text "Membership" however will not be part of the field itself anymore, since the checkbox already has a label and "Membership" would be redundant, as discussed before. It will instead become its own section so that the text "Membership" still appears above the checkbox (see #29 for PR).