TYPO3 Core

Hi Ernesto,
can you maybe look at this and give feedback, and Michael, could you coordinate that somebody brings it to the core?
Sorry that I am spamming you with requests right now ;)
Greets, Sebastian

Three times nested fieldsets aren't the solution for accessible mailforms in v4.0

I will assign it to myself but hope that Ernesto can work on it...

Hi Ernesto, is this possible for you to fix? Would be great if you can help me here. Regards, michael

The attached patch (mailform-accessibility-fieldsets.diff) should solve that minor problem in the TypoScript configuration.

About the issue:

Some "old" TypoScript was added to the new 4.0 css_styled_content setup.txt. This TypoScript comes from the time before patch from bug #14921 was added to CVS (during the "zap the gremlins" action for 4.0). Since then, the fieldset around radio-options (which "group together related controls") is generated by the accessibility=1 option in the FORM code, so there is no need to have that in TypoScript too.

There is still one fieldset around each FORM, which also "groups together related controls" (the whole form). This can be removed via normal TypoScript setup (tt_content.mailform.20.stdWrap.wrap).

Hi Ernesto,

Since then, the fieldset around radio-options (which "group together related controls") is generated by
the accessibility=1 option in the FORM code, so there is no need to have that in TypoScript too.

I think, it would be better to have that in TypoScript than hardcoded, cause W3C definitons doesn't say anything about having automatically created fieldsets only around radiobuttons.

greets,
Marc Bastian

Having that in TypoScript would require the "id" to be replaced dynamically (used by the referencing of the label-for tag).

W3C doesn't tell you anything if something might be generated automatically or not. In this case (FORM in TYPO3), the radio-buttons represent several options of the same item, so they ARE a set of related items. That's why I don't think it is wrong to group them in a fieldset. All the options that compose the multiple-radio-buttons have one single label, which in accessibility mode add a <label for=...> tag around it. To do that we need to give the group of all options a single id, and the most semantically correct way to do that is a fieldset.

Of course it might be a matter of taste. Which is why I had proposed to move every setting here to a more "organized" set of TypoScript settings some time ago. See bug #15324 where this had been resolved, but later rejected because of backwards compatibility issues. I had no time to fix that before RC1 and had asked several times for people to help on that, but noone showed up to do it. So it wasn't added.

But maybe we can consider this for the next version (4.1? 4.5?).

Hi Ernesto,

Having that in TypoScript would require the "id" to be replaced dynamically (used by the referencing of the label-for tag).

no, the label-tag for a set of radiobuttons needs no for="id", cause every button has it's own label-tag.

With your solution every set of radiobuttom gets a fieldset definitely. When I surround all elements of the form with a fieldset (by typoscript), what makes sense, because all related controls and labels are grouped thematically then, I will get a fieldset in a fieldset, what is absolute counterproductive.

There must be the option to disable the automatically generated fieldset around the radiobuttons! So please put it in typoscript and kill the hardcoded fieldset.

Marc,

I don't think your argument about a fieldset in a fieldset being "absolute counterproductive" has any reason except cosmetical. There is nothing wrong with nested fieldsets, and having them improves accessibility by grouping together what has to be grouped together in a visual and semantical way. It is valid, semantically correct XHTML and accessible. With a fieldset, tabbing to a radio-button group by a screen-reader would read the legend and provide the visually impaired user the information about the radio-group, which can then be skipped by tabbing to the next input element.

But what I agree and what is worth a discussion is if the label before a radio-button group needs a "label for" or not. In my view we don't even need a label string (and its LABEL-tag) before the radio-button group, because the label is already being placed in the LEGEND tag of the radio-button group fieldset! This is the semantically correct and accessibly way of having grouping and describing a group of radio-buttons.

I'll discuss the issue in the Content Rendering Group and will probably change this patch to your suggestion, but keeping the default fieldset.

Well - it's just the contrary. Having just a fieldset for radiobuttons (with legend) and another big one around the whole form (without legend) is cosmetical stuff regarding accessbility especially for screenreaders.

Read my posting in the content rendering group to get the reasons.

Personally I tend to regard the current state of the mailform output using CSS-styled-content as a blocker.

Hey,
I asked on an german mailing list of accessbility specialists and the most see no problem with nessted fieldsets.
Okay, but there is still the problem, that you want to hardcode the fieldset around radiobuttons feature. But this feature only makes sense in an overall accessbility context and you can't constrain an admin to have a fieldset around radiobutton, who cares about accessibility.
I can't understand that this buggy concept, submitted more than 2 month ago, will make it into an major final version. Delaying this to v 4.1 means to implement an 4.0 compat mode?