XHTML and accessibility of FORM cObj
The cObj FORM currently doesn't render accessible mailforms, even if setting "accessible=1" in its conf. In a discussion in TYPO3-content-rendering mailing list (6.6.2005), ben van't ende proposed a patch, which can be found here:
This hasn't been incorporated into CVS yet. I found some bugs in this implementation and added some enhancements, so we could apply it to CVS and have it included in 3.8.1.
What ben's patch solve:
- Added: FORM conf variable: fieldPrefix where we can set a prefix to use for all fields in this form (instead of the default "formName", which is probably an unique-hash).
- Added: FORM conf variable: dontMd5FieldNames where we can decide not to md5 the field names in the id fields.
- Fixed: generates one ID for each option on radio-fields, instead of reusing the same ID (generating invalid XHTML).
- Fixed: In strict XHTML mode, set the FORM ID instead of the NAME attribute.
My additions to ben's patch were:
- Added: In "accessibility" mode, we need to create a <fieldset> for the radio-buttons, so we have an ID to which the LABEL refers to. Else we end up with invalid XHTML (reference to unknown id). This is also the most "accessible" way (the field-label refers to the whole group of radio-buttons).
- Added: In radio-buttons, the descriptive text after the radio-button is the LABEL for this specific button. So this will now wrap a <LABEL> tag around the text with the correct ID (so one can click on the text next to the radio-buttons to activate them). Only in accessibilty=1.
- Fixed: Check for ctype_digit in formname before generating the prefix, else we might end up having a digit as the first character of the prefix.
- Fixed: ben's patch wouldn't work with accessible=0 (generates invalid XHTML).
- Fixed: On form elements of type "label", there is no element with an ID, so we should not create a LABEL-tag pointing to an ID that does not exist (generates invalid XHTML).
Attached is a patch that includes ben's and my additions. Read to be included in CVS for 3.8.1 (no change in features, just adds options).
This patch also applies to 3.8.0, for the interested reader! :)
(issue imported from #M1369)
#2 Updated by Sebastian Kurfuerst about 14 years ago
Some comments I got:
So I start with a small observation on cleanFormName. It uses an ereg_replace and we've agreed to use preg_replace. And it does a trim twice (the second is superfluos).
Is the substr really necessary? Shortened ids are probably more annoying the long ids. I recall no lenght limit from the standards.
So back to the main FORM function.
The description says in xhtml strict mode name is replaced with id in the form tag. From the patch it looks like it is always changed.
#3 Updated by Ernesto Baschny about 14 years ago
Sebastian, the cleanFormName() is not really mine, but let's see:
1) the correct syntax is "preg_replace('/\[|\]\[?/',':',trim($name));", so just add "/" around the query works. The expression substitutes: "[" OR "] followed or not by another [" with ":", so "data[x][y]" gets "data:x:y:", as documented
2) the second trim() is superfluous, you can get rid of it.
3) I'm not sure about the limitation to 30 chars, maybe the original author (Rupi?) can give us info about it?
4) Even in HTML 4.01 the "name" attribute in the FORM is deprecated (see http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3): "name (...) Note. This attribute has been included for backwards compatibility. Applications should use the id attribute to identify elements."
#5 Updated by Sebastian Kurfuerst about 14 years ago
The description says in xhtml strict mode name is replaced with id
inthe form tag. From the patch it looks like it is always changed.
Yes, but this doesn't break backwards-compatibility, does it?
It may well be that it does. Why break some stupid browsers, just because of this xhtml crave? <rant>I really like standards, but I begin to hate XHTML 1.1. What has been gained by removing the name attribute?</rant>
I see no point in breaking the page for some users when we can fix it by using id only for "progressive" xhtml versions. If I stick to old html standards I expect that TYPO3 delivers "old" code.
=> Concering the last point... is there a unified method to check for XHTML? just an
if ($this->conf['doctype'] = 'xhtml')?
I'll try to verify this, this note is as well a personal reminder for me
#6 Updated by Ernesto Baschny about 14 years ago
Ok, Sebastian, so I suggest change the patch. From:
- ' name="'.$formname.'"'.
+ ' id="'.$formname.'"'.
- ' name="'.$formname.'"'.
+ ' id="'.$formname.'"'.($xhtmlStrict ? '' : ' name="'.$formname.'"').
This will make the forms that are not XHTML 1.1 strict also work on Netscape 4.
As of "unified method to check for XHTML?" I don't understand what you mean. There are several "flavours" of XHTML.
xhtml = XHTML 1.0 Transitional
xhtml_strict = XHTML 1.0 Strict
xhtml_11 = XHTML 1.1
xhtml_2 = future... XHTML 2.0?
The last 3 are "strict" variants, while the first allows almost everything that was allowed in HTML 4.01 (with XML-syntax, of course).
Thus, $xhtmlStrict (used in my patch) is currently being created in the FORM code directly:
$xhtmlStrict = t3lib_div::inList('xhtml_strict,xhtml_11,xhtml_2',$GLOBALS['TSFE']->config['config']['doctype']);
Maybe this could be moved to some init-method ("start()"?) and set to $this->xhtmlStrict so that other cObject methods can make use of it?