Our adventure in Joomla 1.5 (now 1.5RC2) continues, we have taken further steps in the development of a WAI compliant XHTML strict template. Read this article to discover what we have done so far.

Project goals

With this project, we are trying to create a lightweight fully accessible Joomla! 1.5 template with the following features:
  • Support for multiple skin
  • Font resizing with on-page controls
  • Skin switcher with high-contrast skin
  • Liquid layout with max-width
  • Table-less design
  • True CSS separation between layout, typography and skin
  • XHTML strict W3C validation
  • Produce XHTML strict code from the WYSIWYG editor
  • Automatic multicolumn layout (two columns or three depending on the presence of rightbar components)
  • Access key support
  • Form labels, fieldsets and semantic markup
  • Clean minimalistic XHTML code (lightweight)

The new template in action, blue skin and high contrast skin Joomla XHTML Strict Template

Building an accessible template

The new template override feature available in Joomla! 1.5 allows an easy creation of custom template, we can see an example of such an effort in the Beez template available with the distribution. Unfortunately, this template is not XHTML strict but use the transitional doctype instead. As discussed in the previous article Joomla 1.5 XHTML Strict Template, most of the core components can now be overridden in the template, but a couple of issues remains: some unvalid code snippets that are still produced in the core and the WYSIWYG editor doesn’t produce valid code that follows the strict doctype. The only solution we have found at the moment is patching the core.

Patching the core

Until Joomla! 1.5 release, core patches to implement accessiblity features in Joomla involved a major rewriting of the core, they are now limited to a few files. We have applied a small core patch for the “img” tag (image) code generation and a bigger patch to the WYSIWYG editor (mostly javascript cleanup routines). We feel like another patch will be needed in order to implement accesskey support, but we are still considering if a plugin could be developed instead of patching the core.

To do

We have already completed most of the steps listed in the first paragraph. We are still working on fixing some components output in the template and we are exploring the different options for accesskey support. We will be very happy to hear you opinions and comments about this project.