In end-user (public, non-authorized user) themed output, groups of Children nodes and Link Operations are wrapped in FIELDSETs with LEGENDs. However, the content within these containers are not form elements -- it's text and HTML output.
This is a completely inappropriate use of these containers that significantly complicates styling via CSS (particularly in the case of LEGEND). It also violates the HTML 4 and XHTML specifications, which require that FIELDSET and LEGEND be contained within a FORM and be solely used "to group thematically related [form] controls and labels".
This inappropriate use of FIELDSET and LABEL also poses accessibility issues that could easily confuse users of assistive technologies.
This default themed behavior should be removed altogether. It should not even be an option. Instead, DIVs should be used.
Behavior present in versions 5.x-2.2 and 5.x-2.x-dev.
(To be clear: this applies only to end-user themed output. Use of FIELDSETs and LEGENDs *is* appropriate within the admin tools.)
Comment | File | Size | Author |
---|---|---|---|
#12 | relativity.module.diff | 725 bytes | OliverColeman |
#9 | relativity-no-fieldsets.patch | 5.78 KB | Anonymous (not verified) |
#6 | fieldset-fakery.html_.txt | 1.73 KB | Anonymous (not verified) |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedThat's just not true. The HTML 4 and XHTML specs do not require fieldset and legend to be contained within form elements. FIELDSET can even be the child of the BODY element. It's valid syntax to put fieldsets outside forms.
If it creates semantic problems for your documents, you can override the theme functions. The fieldset is output in a theme function, and the default functions allow you to turn off the fieldset by passing FALSE as the second parameter to theme_relativity_show_parents, theme_relativity_show_children, theme_relativity_show_ancestors.
I don't know how it would present accessibility problems if the fieldset. Did you test it with other devices?
Comment #2
spencersundell CreditAttribution: spencersundell commentedHi bangpound --
Thanks very much for the information on how to disable fieldset output. It's greatly appreciated and I'll give it a try. So far, I'm finding that I can eliminate the fieldset containing the various child nodes, but theme_relativity_show_children still wraps each child in a fieldset regardless of the parameter passed.
All the same, and with all respect, one should not be forced to go to extra lengths to eliminate unnecessary and even counterproductive markup. Clean output should always be the default, no?
By the same token, what exactly is gained by using gratuitous fieldsets and legends by default?
The display complications caused by use of fieldset and legend are non-trivial. How they are displayed is completely inconsistent across the myriad browsers out there. Firefox in particular is extremely limited in how CSS can be used in relation to legend, which can't even be hidden unless it's wrapped in another gratuitous container like a div or span. This latter issue is an especially big problem in this context. In a professional web dev context, all of this is needlessly problematic.
Re: the HTML specs...
After some confirming testing with the W3C validator, I stand humbly corrected and you are quite right on the letter of "the law" (so to speak). Nevertheless, the spirit and intent is crystal clear: the W3C HTML 4 spec discusses FIELDSET and LABEL solely in the section devoted to forms (in section 17 of the HTML4 spec), and nowhere else. Indeed, that sub-section is entitled "Adding structure to forms: the FIELDSET and LEGEND elements." Note that it refers explicitly to forms content and not to non-form content.
Further, the spec states:
The term "controls," of course, refers specifically to form input elements, as explained at the outset of the form section of the specification: "Users interact with forms through named controls."
No other use for FIELDSET or LEGEND is ever mentioned anywhere else in the HTML spec, including the section devoted to structuring page text.
The HTML 4 Transitional DTD states fieldset is a "form control group". The XHTML 1.0 DTDs state "The fieldset element is used to group form fields."
So okay, ya got me: technically it's valid because it is not specifically forbidden -- which surely must be an oversight, but so be it. But it's clearly an inappropriate use of the elements contrary to their explicitly defined purpose. There ain't one single form element to be grouped anywhere in the end-user output.
Re: accessibility...
Accessibility concerns are multivalent and complex (as always). In the case of screen readers, various programs will respond differently when encountering a form, or thinking they're encountering a form. But most basically, a fieldset announces in effect that "Hey user, here comes a set of form fields you will interact with so watch out." Except in this case there is no form, no fields, no interaction (at least of that kind). This is misleading to the unsighted user. In the context of a larger site, if/when such users actually do encounter a form, they've now been conditioned to disbelieve the road signs. This helps no one.
But accessibility is not just about screen readers: for example, the cognitively challenged must also be accounted for. This includes those with developmental disabilities, but it also includes the elderly and others. I'll concede that the visual display may not lead such users astray, if they also happen to also be using a screen reader things could become very confusing indeed.
Respectully yours...
Comment #3
darius CreditAttribution: darius commentedHi everyone,
I appreciate the discussion, and I do agree in principle with spencersundell that fieldsets should be eliminated in the display themes. However, I am busy with other relativity issues, so for now the easiest solution is to overwrite the theme_relativity_ functions with your own custom theme functions.
BTW, proposals of how to achieve the same type of display without using fieldsets are welcome. The change should be transparent to users who already rely on the current default look.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedIt never bothered me because I don't rely on those theme functions, but they should output better code.
I don't know why a screen reader would think it's encountering a form when it hasn't encountered a FORM element. That's why I asked if you have any actual evidence that there's an actual usability or accessibility problem?
There's no great reason to use a fieldset/legend pair. I suspect it's because Drupal has a fieldset theme function that allows you to pass a title and content to it. But so does theme_item_list, and for our purpose, that might be the better way to go.
Comment #5
spencersundell CreditAttribution: spencersundell commentedHi darius --
My suggestion in that case would be to generate divs with some appropriate CSS class names attached in lieu of the fieldset and legend tags.
Sadly, there is no 100-percent bulletproof way to reliably and portably do a pixel-perfect imitation of a fieldset/legend pair using CSS. Even a close second would generally require (modest) custom intervention by the site builder. This is because:
That last one is the real bummer since it truly fubars a plug-and-play universal fix. :-(
But...here's an as-close-as-possible divs-and-CSS approximation (your mileage may vary, void where prohibited, do not use while driving). I've included a header tag for semantic purposes -- I opted for an H3, but it could be an H2 or whatever suits.
Fieldset approach (obviously)
Semantically-correct CSS version
The CSS:
The markup:
I hope this is helpful. Thanks for listening.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedI gave it a go as well, and it can be done even more simply for A-grade browsers. I tested in Safari, Firefox on Mac and IE 6.
I don't think it's possible to guarantee that we can reproduce fieldset appearances across browsers and platforms, because they all have slight variations. For example, IE adds some extra margin to the legend. If people aren't using some kind of reset CSS, I don't see how it's possible.
My example is attached. It has a TXT file extension because Drupal.org doesn't want HTML files attached.
Comment #7
spencersundell CreditAttribution: spencersundell commentedHi bangpound --
My only concerns about your markup example is it (apparently) has a third-party dependency, namely the YUI resets, and -- more importantly -- appears to rely on a star hack variant for a couple things.
CSS hacks must be avoided at all costs because, like all hacks, they rely on errant behavior that will change in future and thus produce unpredictable display. The impact of the release of IE7 is a major case in point.
Regards...
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedThe star hack was applied to legend and fieldset elements — those elements we're not going to be using — so I don't understand your objection. If I remove all linked stylesheets, the examples still look identical.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedHere's a patch to get us started. All fieldsets are replaced by themed boxes.
I also removed some \n and
<br />
that were making relativity's lists difficult to theme. And I made the children list into an actual HTML list.If you want to keep the fieldsets, you can simply put this in your theme's box.tpl.php file.
If you have something else going on in your box.tpl.php file, obviously you should make sure you don't destroy your customizations. I couldn't find another unintrusive way to do this, because relativity currently doesn't load a stylesheet and I don't see why we should start...
Comment #10
gmknowles CreditAttribution: gmknowles commentedThis error is thrown when setting up display options
This was probably posted in the wrong place as this should be a new issue.
When uninstalling I get these errors:
* user warning: Table 'drupal.view_view' doesn't exist query: relativity_display_settings /* : relativity_display_settings */ SELECT name FROM pcf_view_view ORDER BY name in /phoenix-customflooring.com/sites/all/modules/relativity/relativity.module on line 1680.
* user warning: Table 'drupal.pcf_view_view' doesn't exist query: relativity_display_settings /* : relativity_display_settings */ SELECT name FROM pcf_view_view ORDER BY name in /phoenix-customflooring.com/sites/all/modules/relativity/relativity.module on line 1680.
Comment #11
Anonymous (not verified) CreditAttribution: Anonymous commentedThe last comment should be a new issue. I'm reverting to the original title and version of this issue.
Comment #12
OliverColeman CreditAttribution: OliverColeman commentedI slightly modified relativity.module to wrap the list of child nodes in a div instead of a fieldset, see attached patch for 5.x-2.3.
Comment #13
mgiffordadding accessibility tag. Could also be discuss this here http://groups.drupal.org/accessibility
Comment #14
mgiffordChanging this to won't fix.