Currently many developers seem to be reluctant to add the role attribute in their markup since it will make pages invalid when using the W3C markup validation service. This is understandable given the attitude developers of content management systems have had to put up with from some people in the industry.

If you want to now more about WAI-ARIA, please have a look at the WAI-ARIA best practices document.

1. Adding the role attribute to relevant elements in markup

This is the easiest way of describing the different parts of your web page, but has the drawback of making the pages invalid. To add the role “main” to a div just add the role attribute with the value “main”:

<div role="main">...</div>

2. Set role attribute values on elements by ID

If your markup already has elements with proper ID attributes that match the landmark regions in scope you can use a simple javascript to set the role attributes when the page has loaded. This will allow your precious template code to pass the markup validation test as well if you or your users worry about that. Consider the following markup fragment:

<div class="special" id="mymaincontent">
<h1>The main content heading</h1>
<p>Some text</p>
</div>

Adding landmarks via the role attribute can be done with a simple javascript like this:

function setRoleAttribute(id, rolevalue) {
if(document.getElementById(id)) {
document.getElementById(id).setAttribute("role", rolevalue);
}
}
function setAriaRoleElementsById() {
//Add all Id:s and aria roles here
setRoleAttribute("mymaincontent", "main");
}
window.onload=function(){ setAriaRoleElementsById(); }


For a larger example see Landmarks by ID (view source to see details).

3. Set role attribute values on elements via CSS decoration

If you for some reason are more comfortable using CSS classes instead you can create an unobtrusive javascript like this:

function setAriaRoleElements() {
var els = document.getElementsByTagName('*');
var pattern = new RegExp("ariarole-([\\w]+)", "g");
for ( i=0; i < els.length; i++ ) {
var match = pattern.exec(els[i].className);
if (match && match.length > 1) {
els[i].setAttribute("role", match[1]);
}
}
return;
}
window.onload=function(){ setAriaRoleElements(); }


This will allow you to add CSS classes to existing elements in the following form <div class=”ariarole-main”> and get a role attribute with the value “main” on the same element. This pattern won’t affect validation. For a larger example see Landmarks by CSS decoration.

4. Set role attribute values on arbitrary elements using a javascript library

If you already are using a javascript library like jQuery and Prototype you may be more comfortable using that to set the role attribute. This pattern won’t affect validation. For jQuery a typical example may look like this:

$(document).ready(function() {
$("#mymaincontent").attr("role","main");
});

You can of course use other selector patterns as well.

If you find errors or have suggestions for improvement, please add a comment below. All code examples are free to use without attribution (yes, I am looking at you WTFPL license).

At the European Accessibility Forum in Frankfurt (eminently organised by Namics) I met Steve Faulkner who has done a lot of research on  WAI-ARIA (see Using WAI ARIA Landmark Roles). Although the specification isn’t finalized yet there are many advantages to WAI-ARIA and browser support is increasing.

With the help of Steve, I submitted a minor patch for the default WordPress theme that adds ARIA landmark roles. I believe that a simple thing like this would make the web a better place for a lot of people as well as making web development easier.

How to add WAI-ARIA landmark roles

For an overview of methods to work with landmark roles in existing HTML see Patterns for WAI-ARIA landmark roles in existing HTML.

How to check WAI-ARIA landmark roles

If you want to start working on implementing landmark roles in a theme, check out Juicy Studio’s Web Accessibility Toolbar Extension for Firefox or the YAML debug tool bookmarklet. These will aid you in checking that the markup you add is correct.

Adopt your favorite CMS

What other content management systems would you like to see support WAI-ARIA landmark roles? If more people could help to create patches adoption would increase rapidly.

Add your suggestions below (or better, create a patch and send to the developers).

Content management systems

• WordPress (patch accepted for WordPress 2.8)
• Typo3
• Joomla (patch accepted for Joomla 1.6)
• Drupal (patch submitted by Mike Gifford)
• Dotclear (patch submitted in ticket 728)
• Textpattern
• Plone (ticket 9298 submitted by Christophe Strobbe)

Wiki tools

• MediaWiki (patch submitted)
  
• twiki
• Dokuwiki (patch submitted)
• Dekiwiki (may need some accessibility love in other areas too)
• PmWiki (patch submitted)
  

Forum applications

• bbPress (patch submitted by Marco Zehe and accepted in ticket 1074)
• phpBB
• PunBB

Layout generators

• YUI Grids (done)

Hosted services

• Blogger (feature suggestion submitted by Lars Gunter).
• Laconica

Web frameworks

• Django

This is excellent news. Hopefully it will lead to a better web. If you run a consulting company this could be a compulsory course for GUI developers.

A bit of background on RDFa

RDFa is a set of extensions to HTML and XHTML from W3C. With RDFa it is possible to use custom vocabularies to include machine readable data in web documents. In current web documents based on HTML or XHTML there are very limited ways of expressing information for machines. There are:

• HTML elements that express document structure (e.g. headings, lists, tables), and rethoric (em, strong),
• (broadly defined) HTML elements that express various technical terms (code, kbd, samp), and,
• the content itself.

As more business domains are moving online the need to exchange data in a more structured fashion will increase. Instead of publishing data twice, once in a web document for humans and once in a separate file for machines, RDFa makes it possible to include machine readable data in web documents. (In a way, this has been possible since the modularization of XHTML, but in practice, few developers seem to have used the extension mechanisms of XHTML).

An RDFa example

Consider the following XHTML markup:

<p class="contactinfo">
	My name is Jo Smith. I'm a distinguished web engineer at
	<a href="http://example.org">Example.org</a>.
	You can contact me 
	<a href="mailto:jo@example.org">via email</a>.
</p>

Most humans will be able to understand the information but for machines this markup is too vague to parse without ambiguity. By providing more information about the content we can reduce this ambigity. First we provide information about our vocabulary in the HTML element:

<html xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#">

Then we can use the terms of that vocabulary to provide more information for machines:

<p class="contactinfo" about="http://example.org/staff/jo">
	My name is
	<span property="contact:fn">Jo Smith</span>.
	I'm a
	<span property="contact:title">
		distinguished web engineer
	</span>
	at
	<a rel="contact:org" href="http://example.org">
		Example.org
	</a>.
	You can contact me
	<a rel="contact:email" href="mailto:jo@example.org">
		via email
	</a>.
</p>

One of the major benefits is that there is a standard for the vocuabulary specification and it is machine readable. You can open the URI for the vcard vocabulary used above in your browser (you may have to “view source” to see it) and see more information about the terms of the vocabulary. Another big advantage is that you can create a vocabulary specification for your business domain yourself and publish on the web. You do not have to put it through some central authority.

We have now modified the markup in our document to make it useful for both humans and machines. The document still looks the same for sighted users that look at the information in their web browser. Apart from the added benefit for search engines and desktop applications (e.g. importing this information into your adressbook now becomes easier) I believe it will have interesting implications for assistive tools as well.

What if assistive software could use RDFa information?

Since the vocabuary is created in a machine readable format it should be possible to let assistive software such as screen readers load the vocabulary specification and provide more information for the user. If you look at the vocabulary specification for vcards used above each term has a label text. For the title the specification looks like this:

<rdfs:label>Position Title</rdfs:label>

One of the simplest ways of using this information is of course to read it to the listener during the linearization of the page. Since a term can have a description too even more information could be provided to the user.

In practice, the sequence of events for a screen reader working on top of a web browser could look like this:

1. Browser opens the web page.
2. Screen reader parses the HTML and extracts references to all external vocabularies.
3. External vocabularies are fetched and parsed for labels and descriptions.
4. The screen reader announce that extended information exists and starts rendering the page.

So, by using RDFa to reduce ambiguity for machines it is likely that humans too can benefit from the added information. It will be very interesting to see what makers of assistive tools can come up with. What other use cases for RDFa with regards to accessibility can you see?

References

For more information on RDFa see:

• Introduction to RDFa by Mark Birbeck.
• The W3C RDFa primer.
• The Wikipedia entry on RDFa.

Test method

The test method is the same as last time (to be able to see if scores changed compared to the previous test). In short, I tried to create a sample document in each of the editors. The sample document contains markup commonly found on the web. All editors were tested on the same date and the online demo version was used when available. If there was an option to enable more features, all were enabled. Please note that I am primarily testing the output of the editor and not the accessibility of the editor itself.

Tested editors

Most of the editors from the previous test are included this time. Based on feedback from the comments I have also added a couple of new contestants.

From the previous test:

1. EditOnPro by Realobjects. Commercial license.
2. XStandard by Belus Technology. Commercial license. Lite version free (also see special license for open source CMS projects)
3. FCKeditor by Frederico Caldeira Knabben. Open source (LGPL), commercial license available.
4. CuteEditor by Cute Soft. Commercial license.
5. TinyMCE by Moxiecode. Open source (LGPL).
6. New: Xinha. Open source BSD-style license.
7. New: WYMeditor. Open source (MIT and GPL). For an introduction to WYMeditor see Visually Editing Semantics – What You See Is What You Mean.
8. New: Loki by Carleton College. Open source (GPL).

Missing from this round is Kupu as it has not come out with any new release since the previous test. Also, eWebEditPro could not be tested. The online demo gives an error: “Error loading mycontent1”.

Test result

The total score for each editor is listed below. For full test result details see here.

If you find error in the results, please leave a comment or send an e-mail to peter krantz at gmail.com.

Observations

• Many of the tested editors have implemented more accessibility features since the previous test. This is good.
• The bold and italics icons are still used when creating emphasis.
• TinyMCE is one of the few editors that doesn’t nest list items properly. According to the developer comment to my previous article there is an option to corrent this behaviour but it isn’t enabled by default for some reason. TinyMCE now has support for acronyms and abbreviations (with icons that are easy to understand). TinyMCE would have had a score of 18 if the nesting was fixed.
• XStandard is the only editor that pass all the tests.
• WYMeditor is a very interesting contender. Although in a very early stage of development (only two versions released) it managed to score 14 points. It is also the only editor that clearly displays to the user what type of markup is being edited.
• Loki is one of the few editors that has a proper icon for block quotes (it looks like a quote character).
• Only XStandard and TinyMCE provide functionality to create acronyms.

There are now more editors that provide functionality to do proper semantic markup. This is great! My guess is that it would be easy to add many of the remaining features (acronyms, abbreviations and inline quotes) to many of the editors.

Which one will you be selecting for your next project and why?

Som of you will argue that one should never use a WYSIWYG editor and instead deploy a wiki-style editing syntax like e.g. Markdown. This typically solves the problem, but in reality this type of syntax is very difficult for content editors to learn and becomes increasingly difficult if you want to do more advanced editing.

WYMeditor to the rescue

I was planning to start working on my own inline editor by forking TinyMCE and correcting what I thought was wrong with it when I found this comment from Jean-François:

[…] Iâ€d like to present WYMeditor: WYMeditor is a web-based XHTML editor, not WYSIWYG, but WYSIWYM: the end-user can concentrate on rich content, while layout and design are handled via style-sheets.

This sounded almost too good to be true. WYSIWYM (What You See Is What You Mean) is of course how content for the web should be edited. WYMeditor is in an early stage of development, but after playing with it for a while it looks very promising. If it guarantees well formed XHTML it is an easy task to convert it to HTML 4.01 or any other representation you can think of.

Currently it works in Internet Explorer and Gecko-based browsers such as Firefox. You can try an online demo of WYMeditor here.

If content management systems were to use editors like WYMeditor web accessibility would get and instant boost. There are some issues that hopefully will be solved soon:

• icons for strong emphasis and emphasis look like bold and italics,
• heading levels can be mixed in a non-logical way (like inserting h5 after h1)
• support for som elements like acronym, abbreviation and definition lists, are missing

But, if I was developing a CMS I would definitely monitor the progress of WYMeditor.

Could WYMeditor make content editors aware of semantics in a way currently impossible in other inline editors? Will this type of inline editing merge with visual presentation à la XStandard?

Ruby on rails is a great framework for developing web applications. With the increased developer productivity you can put a lot more effort into usability and accessibility. To get started I have created a library (they are called “gems” in the Ruby world) called RAAKT with methods to assert basic accessibility in HTML documents. You will need the programming language Ruby to run RAAKT.

My focus has been to implement machine measurable issues (so no content checking) that never should be present in a document. Other tools give you a massive overdose of checks that end up with results with the wording “if applicable”. In my opinion these do not really help a developer who is new to the field of accessibility.

Currently the RAAKT module will do the following tests on your markup:

• check document structure: Verify that headings are correctly structured (h1 -> h2 etc)
• check tables: Verify that all tables have headers (th elements).
• check for formatting elements: Make sure no font, b, i, blink or marquee elements have been used.
• check has heading: Verify that the document has at least one h1 heading.
• check form: Verifies that all form input fields (except hidden fields) have a corresponding label element.
• check link text: Verifies that all link elements are unambiguous (two links with different targets should not have the same link text. Yes, that means all your edit links in lists). Use the title attribute to separate links.
• check title: Verify that a non-empty title element is available.
• check frames: If frames are used, verify that each frame has a descriptive title attribute.
• check images: Verify that all images have an alt attribute.
• check refresh: Make sure that no client-side meta refresh is present.
• check for nested tables: Verify that no nested tables are present.
• check for language info: Make sure the html element has a lang attribute indicating what language your document is in.

I plan on implementing more checks soon.

Follow these instructions to install RAAKT and test accessibility in your Ruby on Rails application.

Test method

I have selected test criteria based on commonly found content types and their requirements on markup. The test criteria are in the form of a sample document which contains headings, lists, tables and other types of content. Each tool has been used to create the sample document after which the created markup has been inspected. No features for visual formatting has been tested. These are rarely needed as formatting usually is done in a site-wide stylesheet.

Most of the tools can be configured with custom buttons and/or schemas to create specific markup. In this test the official demo version has been used.

Please not that this test is about web based editors (hosted in a browser window). This does not include Dreamweaver, Fronpage and similar tools. The selected tools (and their respective licensing type) are:

1. EditOnPro by Realobjects. Commercial license.
2. XStandard by Belus Technology. Commercial license. Lite version free.
3. Kupu by OSCOM (et al). Open source (BSD-style license). Currently the default editor in Plone.
4. FCKeditor by Frederico Caldeira Knabben. Open source (LGPL), commercial license available.
5. CuteEditor by Cute Soft. Commercial license.
6. JXHTMLEdit by Tecnick. Open source.
7. TinyMCE. Open source (LGPL).
8. Ektron eWebEditPro. Commercial license.

Test result

The total score for each editor is listed below. For test result details see here.

If you find error in the results, please leave a comment or send an e-mail to peter at standards-schmandards.com.

EditOnPro and XStandard seem to be the most advanced editors. They do not rely on cleanup routines or built in browser functionality which ensures consistency between different browser containers. Also, using real XML makes them suitable as a platform for future content management requirements. EditOnPro can be extended with custom schemas and can thus be used as a generic markup editor for specialized content. EditOnPro is a java applet which compared to XStandard makes it load more slowly.

Although CuteEdit and eWebEditPro scored well,they have some drawbacks. Creating table headers involves creating a table and then applyting headers thorugh a separate dialog (in the case of CuteEdit it involves right-clicking a cell, selecting “Verbs” and then “Change to header cell”). This may be too cumbersome for editors to do. And it seems impossible to do this when running CuteEdit in Firefox 1.5.

FCK-editor creates different markup depending on which browser is hosting the editor. Nested lists get the correct markup if you run FCK-editor in Internet Explorer, but not in Firefox. Developers would expect the same behaviour from a component that claims cross-browser compatibility.

TinyMCE scored best among the open source editors. It has functionality to set the lang attribute and title for most elements. Unfortunately it has poor handling of nested lists and I could not find a way to create table captions. These issues should be easy to fix so maybe a future version will provide better functionality.

JXHTMLedit crashed twice in Firefox 1.5 and sometimes display artifacts were left after deleting content.

Observations

Many of the tools have a toolbar with icons for various markup needs. Some common mistakes in the toolbar are:

• The icon to create a blockquote looks like it will increase the left margin. This may lead editors to use incorrect markup to format their text.
• Icons for items rarely used (such as justified text, subscript, superscript, underline and strikethrough) are available instead of icons for more commonly used markup such as blockquote, quote and acronym.
• Most of the editors provide extensive customization options. EditOnPro can be set up with a specific schema to enable creation of custom tags.

Recommendations to WYSIWYG-editor developers

Some fundamental things that all editors should consider:

• Remove toolbar buttons for rarely used markup items such as justified text (justified text on the web is bad for readability).
• The default installation should provide buttons or menu options for inline quotes, blockquotes and acronyms.
• When creating a table, headers should be created by default instead of forcing the user to add them later. Throw in a default caption as well to make sure content editors do the right thing.
• Make sure images without alt-text specified receives an empty alt attribute.
• Do not use the icon for “indent left” for blockquote markup.
• If you claim cross-browser compatibility, make sure that the generated markup is identical.
• Create valid markup

References

• Test result details. See what works and what don’t for each tool tested.
• Sample document used in the test.
• For a comprehensive list of web based markup editors see Genii software index of web based WYSIWYG editors.
• Jakob Nielsen’s “R.I.P. WYSIWYG”. Results-oriented user interfaces may change how we edit content in the future.