In a recent doctoral thesis from the department of psychology at Gothenburg University, Sweden, Erik Wästlund provides some interesting findings on mental workload for consumption of information. Two of the principal findings are:

1. Consumption of information is more efficient when information is presented on paper compared to presenting the information on a computer screen.
2. Consumption of information generates less mental workload when the page layout is adapted to fit the screen.

The first point may not come as a surprise. Steve Krug has argued that users tend to scan web pages rather than read them and Erik’s study cites previous research that says users tend to have difficulties reading longer passages of text on a screen.

A fundamental characteristic of reading information on a computer screen is that it “involves both the process of reading the presented text and handling the computer. The reader’s processing capacity is being utilized not only for decoding but also for page navigation.”. When we read e.g. a book the mental workload is low because we know from experience where to focus after turning a page.

Adapting content to the screen

The second point has some interesting implications for people working with the web. Currently, web pages with a lot of text tend to come in two flavors:

1. All text on a single web page and the standard browser scrollbar to move forward in the page. (Example: A review of the Web Content Accessibility Guidelines 2.0, May 2007 Working Draft).
2. Paged text and one or more navigation buttons to move to the next page. (Example: Mark Pilgrim’s Dive Into Accessibility, Day 6: Choosing a DOCTYPE).

Paged text on the web today is rarely adapted to the browser window size.

In Erik’s study the test subjects were given reading assignments. One group read the document in a scrolled format (number 1 above) and the other group read the document in a paged format where the page format was adapted to the computer screen.

The result showed that mental workload was lower when you read information in a paged way adapted to the screen. This is interesting as the current technology for constructung web pages (HTML and CSS) do not provide an easy way to page text adapted to the user’s screen. I am guessing that it may be possible by using javascript to measure the window size and create keys to move forward by a viewport page at the click of a button.

On the other hand, most browsers provide this functionality for scrolled pages in the Page-up and Page-down keys. In the usability tests I have participted in during the past years I can not recall a single user using the Page-up/down keys.

So, does this mean that scrolled text is better if user’s learn to navigate with the Page-up/down keys? Or should content authors paginate long documents? Will these methods have other accessibility implications?

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.

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?

EIZO has created a monitor that can simulate various types of vision deficiencies (PDF document). It is great to see hardware vendors making an effort to provide tools to improve accessibility, but this one makes me wonder. Do you really need to have hardware support for this? The advantage seems to be that you can test moving images more easily.

EIZO worked closely with the Color Universal Design Organization (CUDO) (also see english machine translation) in conducting experiments with colorblind test subjects to improve the ability to identify difficult to distinguish colors.

Fore those not fortunate to have access to an EIZO monitor, there are a number of software tools available to simulate how web pages and images look with various types of vision deficiencies:

• Vischeck (which you have probably used if you tried the Web Accessibility Toolbar for Internet Explorer.
• Colorblind Web Page Filter - simulates a whole range of deficiencies such as deutanopia, tritanopia, protanomaly, tritanomaly and more.

What I haven’t seen is an application that isn’t confined to the browser, but works on top of your operating system. I guess this wouldn’t be very hard to do. Depending on the operating system it should be possible to have a filter applied to the entire screen. If you know of one, please post it in the comments below.

This post is not about web accessibility, but I hope you will find it interesting nonetheless. The Stockholm Museum of Modern Art (Moderna Museet) created an interesting project to make some of its exhibits accessible for visually impaired visitors.
Read more about Accessible Art for the Visually Impaired

I have created a simple tool to check basic accessibility of a web page using RAAKT (the Ruby Accessibility Analysis Kit). Trying it on Google Labs’ new accessible search interface yields interesting results.

Read more about Online Interface for RAAKT - Remote Accessibility Testing