[TYPO3-core] RFC: CSS styled content accessibility mode

Sebastian Kurfuerst sebastian at garbage-group.de
Mon Dec 19 15:11:30 CET 2005


Hi Michael,

> First of all: Why do you increase the version number in ext_emconf.php?
> I see a very general problem coming here: We decided to drop the system 
> extensions from TER, but this would mean that their version numbers would 
> normally never increase from now on. How will we proceed with that?
I think it makes sense to increase the version number here. The
extension changed, and to keep track of the changes it also makes sense
to say something like "Version 0.3.1 included with TYPO3 4.0". For the
average user it is not understandable that the version of CSC shipped
with 4.0 is better than shipped with 3.8 when the version number didn't
change.

> > Short description:
> >       * accessible_tables has been included into core with this
> So what does that mean? Is accessible_tables now integrated with 
> css_styled_content? Is the original extension going to be dropped?
Yes. It will be marked "Obsolete" but has to remain (at least for some
time) in the Repository, because I will publish a last and final version
containing an update wizard. This is needed because the internal
structure inside the tables has been changed a bit - and the update
wizard migrates the data from accessible_tables into the new data
structure.

> >       * standard behavor not modified
> >       * accessibility mode added: changes menu, mailforms and removes
> >         the p-tag inside cells (lots of people requested this)
> > By default, there is no change in the behavior of CSS styled content,
> > but by switching on the constant ACCESSIBILITY = 1, the accessible menu
> > and mailform will be activated, and the <p>-Tag is removed from table
> > cells.
> Fine but: I suggest to get rid of the ACCESSIBILITY constant before you even 
> start to advertise it. Why should one not want this?
Well - the problem is it heavily breaks backwards compliancy.
It first of all removes the p-tag. from inside table cells, and then it
overrides the content elements mailform and tt_content.menu - and thus
the CSS of the page needs to be adjusted.
Anyways, I'll add a comment to the constant that switching it on is
recommended for new installations.

> If you decide to keep it, then I suggest to enable this constant as well as 
> the accessibility flag for FORM objects both by default. I know this may 
> conflict with the backwards compatiblity, but we should focus on proper 
> instead of unchanged output.
> >       * It is as well possible to change the splitChar in tables now:
> >         | , and ; possible - and cells can be escaped by " and '. The
> >         wizard had to be adjusted to work with this change.
> First, I think you forgot to add the wizard changes to the patch. Can you send 
> them again, please?
nope, they are inside. check the last part of the patch.

> About the delimiters: I suggest you add the tab character here.
no problem, will do that.

> >       * accessible menu/sitemap from Ben
> >       * accessible mailform configuration
> What does it mean? What is going to be changed by it? Will it break an 
> existing layout? See above regarding switching this on by default.
yes, it will break an existing layout. Anyways it is a lot more
accessible, as it uses for example <ul> and <li> for menus / sitemaps -
and removes the tables from mailforms. 

> > This patch is a major step towards XHTML compliancy and accessibility.
> > Another patch will follow soon integrating css_imgtext.
> Make sure you mention this in the NEWS.txt file.
good point :-)


Greets, Sebastian




More information about the TYPO3-team-core mailing list