HTML5 and Accessibility in TYPO3: Laying a foundation for the future

Categories: Community Created by Patrick Broens

The past two months Patrick Broens has been working intensively on the Accessibility project, a part of the BLE (Bundesanstalt für Landwirtschaft und Ernährung) project. TYPO3 has received funding from the German Government Agency BLE to improve the accessibility and usability of TYPO3. These improvements are targeted for TYPO3 version 4.7, that is expected to be released in April 2012.

One of the goals of this project is to have proper W3C validated output in the frontend of TYPO3, mostly produced with css_styled_content and cms. TYPO3 claims it can output with various doctypes, including HTML4, several XHTML variants and HTML5. But is that claim correct? Not really. TYPO3 output is a mixture of XHTML, like closing void tags with a slash (<br />) and HTML, for instance targets, sometimes hardcoded in the source code. Furthermore, while you can change the doctype to HTML5, you won't find any HTML5 tags in the core. Up until now it seems that TYPO3's handling of doctypes has been, at best, only partially implemented.

This is all changing, however. TYPO3 is used more and more for governmental websites worldwide and governments especially have the demand for more accessible websites. W3C validated output is just a small part of it; the Web Content Accessibility Guidelines (WCAG) 2.0 are much more important. Following these guidelines will make content accessible to a wider range of people with disabilities, including the blind and vision-impaired, the deaf and hearing-impaired, individuals with learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general. If that is not enough, the W3C also has WAI-ARIA, the Accessible Rich Internet Applications Suite, which defines guidelines tfor making Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. Last but not least, the BLE requested improved support for HTML5 in TYPO3.

And here the problems begin. Although HTML5 is getting more common, it is still a draft, not a standard, as is WAI-ARIA. In other words, these specifications can change. While WCAG 2.0 is a standard, it does not take HTML5 into account. You won't find any single recommendation about the usage of the new HTML5 tags, probably because HTML5 is not a standard… at least not yet! To add to the confusion , just try to read the complete documentation of WCAG 2.0 and WAI-ARIA. It's huge. Not to mention that WCAG 2.0 sometimes gives you dozens of ways to meet these guidelines. Which one to choose?

Enough complaining, though; we must find a path forward I've followed W3C long enough to know drafts won't change that much until they reach the “Standard” status.

When working with a CMS like TYPO3 it's sometimes hard to implement W3C recommendations into the core. HTML/XHTML by itself is not that hard --it's all about markup -- but when it comes to WCAG 2.0 and WAI-ARIA, we have to shift our thinking and our approach a bit. Because markup decisions have to be made as to how the markup for a each content object will be, we need consensus on this. Most of the output will be generated by the CMS and the system, well, we as the community, can decide what the output will look like. For WCAG 2.0, and partly HTML5, a lot of decisions have to be made by the website builder, the editors and only a small part can be handled by the system. For WAI-ARIA the focus is even more on the editors. This bothers me. Ideally, a CMS should be an almost automated system in which editors don't have to care that much about accessibility, only about content. With the introduction of WCAG 2.0 and WAI-ARIA they need to take care. They need education for it. A system like TYPO3 simply can't make decisions on that level. Not to mention that a lot of the same things are covered by HTML5, WCAG 2.0 and WAI-ARIA, but with different implementations.

Here's an example of what I mean. Let's say we have a block with links which you can define as a “Navigation block.” For accessibility it is wise to make this transparent to the visitor, for instance to bypass this block when it is not relevant.

  • HTML5 has the <nav> tag which clearly identifies everything in between as a navigation block.

  • WCAG 2.0 technique H50 recommends to use a <map> tag to group links (to all of you who think <map> can only be used for image maps, you're wrong. In HTML this can be used to group links)

  • WAI-ARIA does not care about tags. You can identify a navigation block with the role=”navigation” attribute.

You can see this might be (and was!) extremely hard to implement. On every level decisions had to be made how to do such implementations. Because WAI-ARIA was not a real issue in this project, only one WAI-ARIA implementation was done and only when using HTML5 doctype (the longdesc attribute is obsolete in HTML5).

So what has happened?

Most of the changes I describe were made in the extensions css_styled_content and cms. This means the focus was on content objects which can be added by the editors in the backend. The content objects Search, Form and Media are out of focus in this project, as well as extensions and the RTE.

W3C valid for all doctypes TYPO3 offers

This was a task which involved several layers of TYPO3, like cms, css_styled_content, TSFE and other parts of the TYPO3 core. Void tags needed to be checked if the closing was allowed by the doctype, more control is needed over empty tags when there was no actual content to show (for example empty <ul>s) targets where removed when the doctype does not allow framesets unless explicitly set by the editor. To address this last issue a new property was added to TSFE, to check if the doctype does allow framesets.

Wherever possible get rid of width and other styles

The content objects “Text with images” and “Images” were using a markup where style=”width: xxpx;” was needed a lot. The most important reason for this was to keep the caption within the width of an image. To get rid of this style, which may have been the biggest challenge in this project so far, I implemented a different markup with <table> and <caption>, only if there is a caption. The <caption> tag will not exceed the width of a table, even when the table has no given width. By using this kind of markup a lot of these styles could be removed. One drawback of using the <caption> tag is that it is impossible in IE7 to put the caption below the image. It will always be on top. All the other browsers are fine, because you can use the style declaration “caption-side: bottom;”. 
For each content object it is possible for an editor to set the top and bottom margin. It was impossible to remove these kind of styles.

Move inline styles to external stylesheet

No more inline styles! The few styles which could not be removed are now put in the file typo3temp/stylesheet_xxx.css. This file will hardly change and for most pages the same one will be used, unless there is a specific setting for a single content object, like the top or bottom margin mentioned above.

Implement HTML5 where useful

Although some of you want to see more HTML5 in TYPO3, only some has been done. This is becuase a system like TYPO3 can't decide what tags to use, like <section>, <article> or <aside>. Most of the HTML5 implementation is up to the website builder. Nevertheless I've made some progress on this front. When the doctype is set to html5, headers are using <header> and <hgroup> when the subheader is present as well. When you want to display the date in the header, the <time> tag will be used. Images are rendered with <figure> and use <figcaption> when a caption has been provided by an editor. The <nav> tag will wrap the content element “Menu/Sitemap”

Meet WCAG 2.0 success criteria

Meeting WCAG 2.0 success criteria is mostly up to the website builder. Only a few issues apply to the system itself, like css_styled_content. The most important one is to have the possibility to add an alternative text for non-text objects, like images. Luckily a lot of work has already been done regarding the alternative text.
WCAG 2.0 demands that a navigation block will identify itself as such, for instance to skip it. WCAG 2.0 describes a lot of techniques to reach this goal. You can now add a <map> tag around each navigation block made by the “Menu/Sitemap” content object. Another technique which has been implemented is the option to add a “skip navigation block” link in front of the menu/sitemap, which takes the visitor to the next content element on the page.

Currently I'm so deep in this topic that I could go on forever. I especially see a big future in WAI-ARIA and parts of it can be implemented in the basic content elements of TYPO3. Because this specification is so big, this process will take a while and needs a lot of discussion. And I'm still not sure if HTML5 will take over parts of WAI-ARIA. The right place to do discuss and work on it is the Content Rendering Team, and this team definitely needs a boost. So if you are interested in accessibility in TYPO3, I would like to invite you to join us in this effort. Contact us on the mailing list to get involved.

Let's make TYPO3 better for people with disabilities!