Semantically correct radios and checkboxes

+1

I like it.

Great patch Neil!

I rerolled this patch against HEAD and also added 2 new classes, form-radios and form-checkboxes. That way themers can style these differently (or in most cases, adjust margins/padding, generally on checkboxes).

Also, because of the changes in the patch, the CSS in the above patch was wrong, it still displayed the list-style-type. I corrected the CSS and also corrected the margins so it displays correctly against all major browsers (above patch's CSS created huge margins in IE).

Should be good to go now!

No longer applies. Does this degrate more or less OK in absence of CSS?

Dries, my above patch still applies cleanly against HEAD.

As for the CSS, yes it degrades very nicely. With CSS disabled, you see a list of checkboxes or radios, appearing almost nearly as identical with CSS turned on.

I tried and it looks really weird in absence of CSS.

$ find . -name *.css | xargs rm

Any CSS-base design looks like ass without CSS enabled, including drupal.org. :-) The question is whether it is still functional. An unordered list of checkboxes may be ugly, but it's still semantically correct and visually understandable. It's actually more correct than a bunch of divs, I'd argue.

I agree with said comments.

In absensce of CSS of you are literrally "turning off style" of course it is not going to look that good :-) But, it is *much* more semantically correct, which to accessibility and screen readers and Google, is *much* more meaningful and much more useful. DIVs are overused, use semenatic content when available.

Still RTC :-)

Moving to 6.x-dev queue.

Doing this without breaking stuff obviously is too tricky to it done get that late in dev cycle. Have to bump it to D7. :(

Well, this seems like a good idea. Patch doesn't apply at all well against the CVS at the moment. Wanted to flag this before we get too late in the end of the D7 dev cycle.

Adding accessibility tag

I do want to give this more thought, but it seems that much of this patch has already been applied.

Main issues are to make lists of radio & checkboxes semantically correct by making sure that they are in an unordered list.

Adding

is probably just something that could be swapped for

(with some modifications of course) in the function theme_radios(). That would be pretty simple I think.

But think it's going to need a serious hack to http://api.drupal.org/api/function/drupal_process_form/7 to allow the list items to be displayed. Really not sure how to pass that it is a list along to the part of the form builder that actually creates the html.

And of course there's:

+ul.form-radios, ul.form-checkboxes {
+ margin: 0.5em 0 0 0;
+ padding: 0;
+ list-style-type: none;
+}

I can see the semantic advantage of having a list of radio or checkbox elements marked up as part of a list. I don't believe that this would actually mean any appreciable advantage for users of assistive technology. I also see the problem of theming radio and checkbox elements with an li wrapper if that same element may be displayed in a table cell.

One possible method of working around this would be to only theme radio and checkbox elements as list items if their parent element is radios or checkboxes. We could also possibly create a new property for the radios and checkboxes form element types that will allow form developers to select whether the collection will be themed as a list or not.

I'm going to drop the accessibility tag here as Everett didn't see this as a major advantage to assistive tech users.

Also going to point folks to #558928: Form element labeling is inconsistent, inflexible and bad for accessibility as surely if we had more consistent forms we'd have less inconsistent results (like the ones described above).

Tempted to close this issue, I don't really see the advantage. But, since others have seen the advantage in the past bumping to D8.

I have to say that I still don't see a use-case. No comment in 10 months and a 5 year old issue.