[TYPO3-content-rendering] Fieldset around radio-button group

[JoH]

>>> And this should be default in the "accessibility=1" of TYPO3 4.0?
>>
>> Maybe. But since I gather that 99% of my forms to come will use a
>> colun based layout I'm not to keen on a label-less layout ;-)
>
> Yes, that's the main point/problem here: We want to be "accessible",
> but don't want to piss off the old-gang that is used to column-based
> form layout from TYPO3. Gladly most stuff can be configured via
> TypoScript, but most people won't know this when sending some ranting
> post to our lists ("argghh, 4.0 broke my site!").
>
> My suggestion for 4.1 would be (we should have done that in 4.0
> already, but it's too late now):
>
> Have a basic "css_styled_content" that uses tables when appropriate,
> is not accessible, but works like it always has worked, and which many
> people love so much. But we bring more "power" to TypoScript, allowing
> everything to be changed there (classes, tags, etc). And then we ship
> a new static template in this extension called "CSC accessibility
> add-on" that simply overwrites the default css_styled_content
> TypoScript as appropriate to generate "accessible" output. The CSS
> purists can install this template and be happy.
>
> This way we don't even need the "compat_version" check at that point,
> but let the user decide which rendering he wants for her content.

Well - to make things clear a few statements from somebody who produced a
lot of really accessible sites _and_ tested them with different
screenreaders.
First you should always keep some things in mind:

Accessible > Readable for a Screenreader
Layouttables != not readable for a Screenreader
Layouttables != Accessible

This means you can of course use table based layouts even in a mailform and
still be accessible for screenreaders being used by visually impaired
people.
In fact you can make use of table headers and other stuff to improve
readability and give the user more information while making it invisible for
the "default" user.
But this will be not accessible for other media like i.e. a PDA screens
since the table might force horinzontal scrollbars and prevents elements
from floating.
You see Accessibility is much more than just being usable for the visually
impaired.

When it comes to fieldsets and radiobuttons there's a very simple rule based
on the fact that a radiobutton always implies a decision to be made by the
user.
You can split up the whole set into two parts: The decision itself and a
block of different options.
So the rule is:
A fieldset around a set of radiobuttons should have the decision to be made
as a legend while the radiobuttons should have the different options as a
label.

<fieldset>
    <legend>Do you want our Newsletter?</legend>
    <label for="yes">Yes</label>
    <input type="radio" name="newsletter" id="yes" value="yes">
    <label for="No">Yes</label>
    <input type="radio" name="newsletter"  id="no" value="no">
</fieldset>

Just for the record: Regarding accesibility the specialists tend to avoid
radiobuttons and replace them with selectboxes that don't need a label for
each option. So maybe they won't ever use radiobuttons together with
"accessibility=1".

But how can fieldsets be used to improve readability for the visually
impaired while using TS FORM Elements?
Well - the way it is done now will not improve anything since a fieldset
around the whole block of elements is of no use at all.
The fact that it doesn't offer a legend makes it even more useless and
degrades it to a simple layout element for the default user. You could use a
table instead without any difference for the screenreader.
Forcing a "fieldset in a fieldset" for radiobuttons by hardcoded html tags
makes it even worse, since the other elements won't have any fieldset and
the only thing you could clearly identify as a set with a screenreader would
be the radiobuttons.
BTW: Did you ever check how legends and fieldsets will look in the different
browsers? - It's nearly impossible to make them look just similar. So it
will be hard work for the CSS gurus to get rid of the stuff you forced them
to use by hardcoding it into the PHP classes.

The interesting thing for screenreaders is the legend that will help
visually impaired people to know where they currently are, which is very
important if you are working with complex forms and lots of fields.
But this only makes sense if you are able to group fields manually and
provide them with an appropriate legend. Anything else is just cosmetical
stuff that doesn't improve accessibility in any way.

So my advice is: Do it properly and make fieldsets available the way they
were meant to be or don't use fieldsets at all.

HTH

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.cybercraft.de