Bug #14921

XHTML and accessibility of FORM cObj

Added by Ernesto Baschny over 15 years ago. Updated over 14 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


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)


FORM-ids-accessibility.patch (6.39 KB) FORM-ids-accessibility.patch Administrator Admin, 2005-08-11 18:06
bug_1369_2.patch (6.17 KB) bug_1369_2.patch Administrator Admin, 2005-11-11 17:53
bug_1369_3.patch (6.09 KB) bug_1369_3.patch Administrator Admin, 2005-11-23 19:49

Related issues

Has duplicate TYPO3 Core - Bug #15019: mailforms are rendered with hashed id'sClosedMichael Stucki2005-10-09


Updated by Sebastian Kurfuerst over 15 years ago

the current patch bug_1369_2.patch is the revised version by Ernesto and me. Comments are welcome!
Greets, Sebastian


Updated by Sebastian Kurfuerst over 15 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.

Greets, Sebastian


Updated by Ernesto Baschny over 15 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."

So this is what we do in the JavaScript: we use document.getElementById(), which is DOM Level 1, W3C standard, supported by all major browsers since 1999 (IE>5). It won't probably work on NN4, and I'm not sure if "document.formname" which we have as a fallback works on IE4. I have no way to test it.


Updated by Sebastian Kurfuerst over 15 years ago

Hi, I've uploaded a new patch.
1 - done. Thanks
.2. Yes, did it.
3. There is no limitation in the standards, I removed it.

Greets, Sebastian


Updated by Sebastian Kurfuerst over 15 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
Greets, Sebastian


Updated by Ernesto Baschny over 15 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?



Updated by Sebastian Kurfuerst over 15 years ago

Hi Ernesto,
thanks for your input! It is highly appreciated as I can work faster then. A revised version is at the core list right now.

Greets, Sebastian


Updated by Sebastian Kurfuerst over 15 years ago

fixed in CVS. It would be great if you could test it again to make sure everything works as expected. I had to merge parts of the patch by hand.

Thanks and greets, Sebastian

Also available in: Atom PDF