Yesterday I discovered that Mozilla add-on hosting has improved a lot so in the future you will find Fangs there. It should make updating a lot simpler. Version 1.06 adds compatibility with Firefox 3.6.

See Fangs screen reader emulator add-on over at Mozilla.org.

Introduction

When you start working with web accessibility as a site owner you will typically be exposed to online accessibility evaluation tools recommended by your supplier. These tools typically let you enter a link to a web page after some automated checks are made you get a report of all the errors that were found.

While these tools may be a good way to convince your organization to increase funding for accessibility work you should be careful how you interpret their results. Your website may be good enough already and if you try to fix all reported errors you may be spending money in the wrong thing.

As an example of how difficult these tools may be to trust and understand I have selected some of the more popular ones from the Web Accessibility Initiative list of tools and performed some tests.

Letting accessibility evaluation tools test themselves

Here, each of the tools were pointed at their own starting page. When possible WCAG 1.0 triple A settings were selected.

Very few errors as expected. After all, these tools are built by professionals and I would expect them to have checked their own service.

Letting them test each other

So, what do they say about each other? Only one way to find out.

It is understandable that people find it hard to make use of web accessibility evaluation tools. How are you supposed to interpret these results? None of the tools are in agreement on any of the tested pages. Similar results would be returned for most pages you evaluate.

Observations

• WAVE didn’t find any accessibility issues in any of the pages. Also, WAVE would display a fun error message if you try to make it check itself by URL (I had to copy and paste the source instead).
• The output from many of the tools are really hard to interpret, especially if you are new in the field of web accessibility. The  TAW tool, for example, displays tiny icons all over the page and you have to hover them to see what they mean.
• Worldspace uses nested tables for layout (something that WAVE didn’t complain about).

What would be your advice for a site owner that wants to increase accessibility on his/her website? How can they check if their supplier did the right thing when creating the markup?

(Please leave a comment or send me an email if you find any errors).

A big thank you to Stuart Middleton who showed me the necessary steps to get rid of the annoying security warning that Firefox 3 displays for unsigned extensions.

In order to make accessibility development efforts more efficient I believe that accessibility has to be integrated into all stages of a project with as much automation as possible. Here are some ideas on how this can be done for the developer role.

Project roles and process

Consider the typical staffing of a web development project and how the respective roles relate to accessibility:

• Designers create the user interface design. The design needs to be checked for visual aspects such as contrast issues, choice of color, font readability etc. The designer deliverables are often due early in the project.
• Developers create the markup and application logic for the application. The markup has needs to be checked for technical accessibility issues such as correct markup of tables, forms, document structure etc. The developer devliverables appear throughout the project.
• Content producers (copywriters) create text. The text has to be checked for readability issues and other language aspects. Content is often delivered towards the end of the project.

Accessibility experts typically appear at the end of the project to test the application. This is natural as it isn’t until the end that the majority of design, markup and content is available for testing.

Implications

The problem with this approach is that the time between feedback from the accessibility evaluation and the work done is too long. Proponents of agile development methods identified this a long time ago and it is typically illustrated with the cost of change curve:

In essence, rapid feedback is easier to act upon and incurs a lower cost of change. Getting the feedback later means that you as a developer may have implemented more functionality in an inaccessible way. There may also be more dependencies developed that affect the parts that you need to change based on the late feedback.

So, if possible we would like to have a tool that provides rapid feedback throughout the development process to all project roles. By “rapid” I am referring to near instantaneous feedback to minimize context switching for the developer.

Challenges with automated accessibility evaluation tools

The challenge with accessibility testing is that many things are difficult to automate. Content, for example, is hard to do an automated assessment of. You may calculate all the readability scores you want but only real user testing will give you enough information to conclude if your content is understandable.

Contrast and color is also difficult. Developers may have used combinations of javascript, css and markup to create the final look. To have a machine understand the actual contrast ratio for a specific text may be nearly impossible if you don’t roll your own browser implementation.

Other challenges include integrating a tool into your project’s continuous integration framework. This rules out many of the web based tools available.

A proposed solution

If you haven’t heard of Raakt (The Ruby Accessibility Analysis Kit) before, there is a quick introduction on the Raakt wiki. Raakt focuses on the developer role in a project and helps developers make sure that the created markup passes a set of basic accessibility tests. It integrates with many test frameworks to become part of the automated test cycle.

The ambition is to make basic technical accessibility testing a natural part of a development project’s test suite. This will hopefully improve markup quality and minimize the number of accessibility issues found in subsequent tests. It also helps developers with little or no accessibility knowledge to get on track faster.

I would be very interested in receiving your feedback on what you think about this approach. How can accessibility become a more natural part of a development project? In your experience, would a project benefit from rapid accessibility feedback? Have you tried Raakt and did you find it useful?

References

• Scott W. Ambler: Why Agile Software Development Techniques Work: Improved Feedback.

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?

If you work with accessibility guidelines you may find this useful. Suggestions are of course always welcome.

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?

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.

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.

In this article we will have a look at how you can test your content to see give a brief overview of formulas for measuring readability as well as an online tool to measure readability for your texts.

Content is commonly overlooked when working with a web site to increase accessibility. Even if your web site follows all W3C recommendations it will still be inaccessible if your content is difficult to comprehend. As previously mentioned here and elsewhere you can do a lot to increase accessibility by working with your content.

The technical aspects of accessibility is often more easy than the content aspects. If you are reading this you probably already know how to create an accessible web site by using the W3C recommendations. You also know how to use the W3C validator to test your templates before you put them onto your live site. Content, on the other hand, varies over time and is often created by a large number of people, each with their own personal style of writing. It is also more difficult to test using an automated tool.

Measuring readability of a text

There are a number of methods to measure the readability of a text. Most of them are based on multiple correlation analysis where researchers have selected a number of text properties (such as words per sentence, average number of syllables per word etc) and then asked test subjects to grade readability of various texts on a scale. By looking at the text properties of these texts it is possible to correlate how much “words per sentence” influence readability.

Some important facts about readability measurement methods:

1. Readability index formulas only work for a specific language.
2. Readability does not equal understandability.
3. A readability index score is not an exact science. For example, it does not consider disposition (paragraphs) or actual content (are the words from a specific domain?).

Having said that we can move on to testing our content.

The readability index calculator

I have created a simple tool where you can calculate a readability index score for a text of your choice. To see a comparison, please try it with a legal document such as an EULA (End user license agreement) which typically is difficult to read. The calculator uses the following formulas:

• English: Flesch-Kincaid reading ease and grade level.
• Spanish: Fernandez Huerta.
• French: Kandel & Moles.
• Swedish, Danish: LIX.

After you are done testing your own texts, come back here and read more on what you can do to increase readability of your content.

What you can do to improve readability

If you have a large web site with many editors you should make sure all of them have a basic understanding on how to write for the web. Implementing a publishing policy and making sure it is used will ensure that your visitors get a consistent style when visiting your web site. The policy could include the following guidelines:

1. Explain abbreviations and acronyms the first time they are used (do not rely on markup alone).
2. Provide a subset of your content in basic english or the corresponding basic version of your language. Sweden has an organization that provides training in easy-to-read swedish. Your country/language may have similar institutions.
3. Try to keep sentences short.
4. Avoid symbolic language (metaphors).
5. Avoid complicated words. Make sure you are writing from your user’s point of view. Use their terminology instead of your own.
6. Write for the web (see Seven Krug’s book Don’t Make Me Think). Writing for the web differs from writing e.g. a scientific report. Fore more information see the references section below.

References and more information

• How to write simple english articles (wikipedia).
• Writing for the web, John Morkes and Jacob Nielsen.
• The Easy-to-read Network, hosted by the Swedish Easy-to-read Foundation.
• Why is easy-to-read needed? A matter of democracy (PDF 130 Kb).
• Readability.info.
• Readability and its Implications for Web Content Accessibility.
• How to implement Flesch-Kincaid in PHP.
• Overview of readability analysis (University of Texas Accessibility Institute).