Archive for the 'Markup' Category

Patterns for WAI-ARIA landmark roles in existing HTML

This is a short summary of some methods to add WAI-ARIA landmark roles to existing web pages, e.g. an existing template package for a content management system.

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).

Contributing WAI-ARIA landmark roles to open source CMS themes

Sometime new technology suffers from a chicken and egg problem. For example, if no websites start using WAI-ARIA there will be few incentives for manufacturers of assistive technology or browsers to include support in their products.

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

Wiki tools

Forum applications

Layout generators

Hosted services

Web frameworks

  • Django

Opera Web Standards Curriculum

From the introduction: “Learning Web Standards just got easier. Opera’s new Web Standards Curriculum is a complete course to teach you standards-based web development, including HTML, CSS, design principles and background theory, and JavaScript basics. It already has support from many organizations (including Yahoo! and the Web Standards Project) and universities. The first 23 articles are currently available, with about 30 more to be published between now and late September.”

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.

Evaluation of WYSIWYG editors (2007)

It has been almost a year since I tested accessibility features in some of the more popular WYSIWYG editors commonly found in open source content management systems (see Evaluation of WYSIWYG editors). During this time, most of these editors have been further developed. Let’s have a look at how they fare a year on.

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.

Editor Score (out of 19)
XStandard 19
EditOnPro 16
TinyMCE 15
FCK-editor 14
WYMeditor 14
Loki 13
Xinha 13
Cute Editor 10

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?

Visually Editing Semantics – What You See Is What You Mean

Many CMSs (content management systems) come with some kind of visual editor that allow editors to create and format content without knowing the markup involved. I evaluated some of these WYSISYG-editors back in March and found most of them lacking in features for semantic markup. One of the more commonly found problems is that they have a lot of features for visual formatting like font selection, font color, indentation etc. In most CMSs these are features you would like to avoid (ask your corporate communication department if they would like to have features that allow editors to go crazy with colors on the website…).

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.

WYMEditor interface showing the markup structure of a text.

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?

Peter Krantz, peter.krantz@giraffe.gmail.com (remove giraffe).