Missing labels for profile and language selectors

Sounds good, but it should be fixed in D8 first.

Confirming this as an issue with the language selection, but the Profiles had labels. They should have been in fieldsets though. Attaching two screenshots.

The fieldsets issue is a difficult one, see #1168246: Freedom For Fieldsets! Long Live The DETAILS.

Definitely hope we can fix this in D8 though.

Language selection patch & screen shot.

EDIT: Note that this only addresses the missing label in the language selection.

So we've solved the first problem with the languages, but not the problem with the profiles.

There is no Profile selection label. Radios & Checkboxes should be wrapped in a fieldset with a label and there's no fieldset & no label.

You should be able to hear the Standard & Minimal checkboxes as options however. I don't think this has changed from D7, but it's been a while.

Do you know how to go through the HTML source? Everett's done a bunch of that, though it's got to be fairly time consuming.

I do appreciate the rational for why fieldsets are required for radios. It's just linked to a lot of other issues. I mentioned the use of DETAILS earlier to address our legacy use of fieldset, but there is also #504962: Provide a compound form element with accessible labels .

Anyways, I've attached the new patch with fieldsets & a screenshot.

It can't be marked RTBC because there are style changes such as you've noticed. It's styled with all caps for everyone.

We want the label to be there for people using screen readers, but we don't want it there for everyone else (at least as it's formatted now).

So, we have to deal with fieldsets so we have a unified approach for this issue.

There is no rationale why this should be a fieldset, I see no good reason for there to be one.

Well, because it provides context and we aren't using fieldsets properly now. See from WebAim:
http://webaim.org/articles/gonewild/#forms
http://webaim.org/techniques/forms/controls

But also from others:
http://www.jimthatcher.com/webcourse8.htm
http://www.cs.tut.fi/~jkorpela/forms/kbd.html

@falcon03 described his experience using this form without fieldsets vs with fieldsets.

I'm not asking for a change in the design pattern. Visually I think it's fine as it is. However, the underlying structure needs to change so that we can use fieldsets with multi-part forms.

Can't we just have a label? "Choose language" and "Choose profile" I think thats how we do almost all From API provided forms?

I am a little surprised we need a fieldset around basically, all checkboxes/radio's is that even in D7?

This is an outstanding problem with FAPI that's been discussed although not understood.

Look at the screenshot between #4 & #9 above. It's not a matter of there not being a label for each of the radio buttons as they are already there. Each input form can only have one label & vice versa. Groups of inputs like this, need to be grouped in a fieldset with a legend:
http://drupal.org/files/ProfileSelection.png
http://drupal.org/files/ProfileSelectionFieldset.png

It's the context that is important & missing. What is Standard or Minimal? The context comes as they are grouped in a fieldset and the label describes what this group has to do with each other.

You also can't have fieldsets within fieldsets, thus the issue with the DETAILS. Or going back further #504962: Provide a compound form element with accessible labels

I get that, I guess we need a fieldset style that doesn't create a border. Because we visually don't want a border.

Absolutely on the border. Also we might need to have one where the text is invisible too.

All radios & checkboxes should be wrapped in a fieldset with a legend. However, someone might might not want to have that be displayed visually.

Hm. Can we element-invisibile the fieldset? Or does that hide its entire contents?

Sorry, should have clarified. element-invisibile the legend not the fieldset.

So to play with jimthatcher.com's code above by adding a class to the fieldset & an optional class to the legend:

<fieldset class="form-grouping">
	<legend class="element-invisibile">Gender?</legend>
	<input type="radio" id="m" name="g" /><label for=”m”>Male</label>
	<input type="radio" id="f" name="g" /><label for=”f”>Female</label>d
</fieldset>

We can remove the outline by default with a fieldset.form-grouping. The other is something that needs to be introduced to FAPI.

Looks like a needs work situation here.

tagging

This just requires some css I think. Hopefully we can get someone to look at it at the sprint.

This patch adds to patch #9:

- Removed the border around fieldsets in these files:
system - normalize.css
bartik - style.css
seven - style.css

You shouldn't edit normalize.css manually, it's a third-party library.
If there need to be overrides elsewhere, that's fine.

Re-roll without the normalize.css change.

There were a few other changes with the CSS so I needed to insert:

fieldset {
  border: 0;
}

into the files. I wasn't sure what to do with Stark, but added it with a note regarding normalize.css.

#25: Label4LanguageSelectionAndProfileSelection-1811216-25.patch queued for re-testing.

Hmm.. Rerolled.

#29: Label4LanguageSelectionAndProfileSelection-1811216-29.patch queued for re-testing.

Thumbs up.

Applied cleanly, Looks good.

Hm. This seems to remove the fieldset border on all fieldsets? Is that intended?

For example, Views UI used to look like this:

And now looks like this:

Since we just about started a war over keeping those borders in another issue, I'm guessing that's not what we want.

Seems like what we need is a attributes => array('class' => 'no-border') which removes the border on the fieldset? Something like that anyway.

However, it's also weird to be introducing these one-off hacks. If it's a fieldset, what's wrong with making it look like a fieldset? IOW, why isn't this ok?

In any event, it seems like adding the ability to make fieldsets arbitrarily borderable or not probably belongs in a separate issue that's not a major bug.

Isn't switching radio button groups to use fieldsets the topic of other issues (for example #504962: Provide a compound form element with accessible labels , already linked to above)? Those issues would presumably take care of the fieldset border problem.

I don't see any reason to special-case the installer, so for this issue, shouldn't we just switch it to a group of radio buttons with a proper screen reader label, and then let it be moved to a fieldset (for even better accessibility above and beyond that) in the other issues, whenever all other radio button groups in Drupal core get switched over?

This patch does that. I made both titles invisible (not just the language selection one) because I think @webchick's screenshot shows why the profile selection one should be too; do we really need three different places on the screen that tell visual users that this is the page to choose a profile? :) I also changed the wording so both labels duplicate the page title exactly (since the label here is really just a substitute for that).

So in theory this patch has no effect on the visual display of the installer at all; it only adds new text for screen reader users. (In practice, the switch to #type 'radios' means some extra divs get added to the page so there are tiny layout differences on the profile selection screen, but nothing major.)

Those test failures look unrelated. In any case, here is a reroll to replace t() with st() which I should have done before.

This addresses the accessibility problem with the language selector.

However, it the way that the the languages are selected has changed enough I'm not comfortable marking it RTBC. The accessibility problem has been resolved by this patch and hope the screenshots help.

It should also be manually tested with a couple of languages to see that it works as expected. Thanks for this patch @David!

Mike asked me to have a look at the code here.
Looks good to me, great work folks.

Great, no visual changes that I could see.

Committed and pushed to 8.x. Thanks!

Moving down to 7.x.

There are labels in the D7 version. At some point (before this) they were dropped. This restores the functionality that was lost in D8. Probably this should have been noted as a regression.

There is a related issue that falcon03 identified that will need to be backported, but think this one is fine #1811128: No table header on install requirements

Thanks everyone!

Perhaps I'm missing something, but I don't see labels for either of these forms in Drupal 7.

Just did a fresh install to check. Ran WAVE (I've looked at the source on this too), and there are the right number of labels for input forms.

I'm pretty sure we're good on these two pages for D7.

Those are labels for the individual radio buttons - but isn't the point of this issue that the group of radio buttons needs its own label (so people understand what it is they're supposed to be selecting)?

@falcon03 suggested a bunch of issues in D8 that he hadn't noticed as errors in D7. And also the goal has been slightly higher in D8 than it was previously. The move to radios from individual radio buttons is semantically better.

However in D8 in October the language selection page had no labels as you can see here - https://drupal.org/files/LanguageSelector.png

This wasn't a D7 problem, but was something that was introduced in D8.

That being said, I'm happy to leave this with the D7 maintainers to see if they'd like to backport this patch.

That doesn't sound like this is major anymore, at any rate.