If you want to help out with RAAKT testing, please have a look at the online web interface. With it you can test accessibility of remote web pages in a similar fashion to the W3C validator tool. As mentioned previously, one of the design goals is that RAAKT will only test machine measurable accessibility issues. In practice, this means that all web pages should pass all the time, there are no “if applicable” results.

Testing it with Google Labs’ new product Google Accessible Search yields some interesting results. RAAKT reports three errors for the page http://labs.google.com/accessible/.

If you find a bug, please report it at the RAAKT project page. For more information about RAAKT, see the previous entry Automated Accessibility Tests with RAAKT in Ruby on Rails.

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.

Currently I am working on an accessibility analysis kit which you will be able to use as part of an automated test procedure in the Ruby on Rails framework. RAAKT is a Ruby port of PAAKT (the Python Accessibility Analysis Kit) and can be used for assessing basic accessibility of HTML documents. The focus is on machine measurable aspects which means that there is a huge disclaimer with regards to content. Just because you pass all tests in RAAKT does not mean you are completely accessible. It will, however, be possible to get a feel for basic accessibility issues in your web application. The idea is to make it possible to integrate RAAKT into your automated functional testing framework.

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.

The digital divide in China is closing with computers per capita steadily increasing (for more details see The Digital Divide: Lessons from the People’s Republic of China (PDF) by Jonathan Harrington). China has undertaken massive investments in the ICT sector. It is therefore interesting to see what the Chinese government will do within the area of government policy for public web sites.

Background

The EU-China information society project seeks in particular to assist Chinese government in copyright, telecommunications law and information security issues as well as in access to e-government. The four-year project is cooperatively financed by the European Union and the PRC. Five Chinese cities has been chosen as pilot areas for the project, including Chengdu in southwest China’s Sichuan Province, Yantai in east China’s Shandong and Baotou, the second largest city in north China’s Inner Mongolia Autonomous Region. The project is being implemented by a consortium of the Emerging Markets Group and the German consulting firm GOPA.

Access to government information on the web is relatively new in the PRC. However, a recent report (quoted in an article in People’s Daily Online) said in China, 96.1 percent of government departments at the state level and 81.3 percent of local governments had launched portal websites.

I have gathered links to 80 government web sites from the Chinese Central Government’s Official Web Portal. These have been checked with the W3C validator to see if headings were used and if they were using the W3C HTML recommendations.

Test disclaimer

Please note that the automated test has only tested the start page of the site. Also, usage of the W3C recommendations is only an indication of accessibility. A site that does not validate may still be more accessible than one that does. I have not tested every site manually and you may find that some of the valid ones have a valid splash page but fail miserably for the rest of the site.

The validation result

The validation result details shows that none of the tested sites use valid HTML. More worrying is that only one site is using headings. A common problem with the tested sites is that encoding has been used incorrectly.

Although tests of other countries have shown similar results (USA: 2.4%, New Zealand: 5.7%) having no valid sites indicates the absence of a central policy for government web communication.

It will be interesting to see if the EU-China information society project can help provide a foundation for the Chinese government to implement web guidelines that will help citizens to access information in a better way.

References

• Validation result for Chinese government web sites
• Validation result for US government web sites
• Validation result for New Zealand government web sites
• EU-China information society project. The official web site of the project.
• Chinese Central Government’s Official Web Portal.
• EU official hopes European experience in e-government can help China in People’s Daily Online.

I finally managed to get some spare time to update and re-package Fangs to work with Firefox 1.5. If you feel that Fangs is useful for you, please do not hesitate to check out some of the ads that appear on this page.

The new version can be downloaded from the Sourceforge project page.

Please note that you manually have to uninstall the previous version and install the new version from your local disk.

Update: If you didn’t have Fangs installed earlier you will not see any output until you add the following preferences strings:

• extensions.fangs.output.defaultlang, with the value “en” (remove quotes).
• extensions.fangs.output.style, with the value “default” (remove quotes).

To edit Firefox preferences type about:config into the browser address bar and press enter.

Update 2:There is also a version for Firefox 2 at the Sourceforge download page. In the future I won’t be writing a blog post for every new Fangs release.

An update to make Fangs compatible with Firefox 1.5 is in the works. It almost works, but Firefox 1.5 broke the default setting for how developers can access the document object in javascript. I will try to update it as soon as possible. To receive a notification when the new version is available, please sign up to the Fangs mailing list over at the Sourceforge project page.

For those who are adventurous I can report that if you manually recompile the Fangs extension XPI and update the maximum allowed Firefox version number you will get an almost working version (you will have to click the Fangs reload button every time).

Thank you for all the encouraging emails. If you want to support the development of Fangs, please take a while to look at my Google ads (maybe you find something interesting you want to click on…) or please consider making a donation via PayPal.

How the test was carried out

In a previous article I wrote about how you can script a local installtaion of the W3C validator tool using Python. I have since modified the validator to do more checks apart from making sure the HTML is valid. Links to US government web sites were obtained from FirstGov.gov: the U.S. Government’s Official Web Portal. Only the first page of the web site was checked. The test was carried out on September 25.

Test disclaimer

Please note that usage of the W3C recommendations is only an indication of accessibility. A site that does not validate may still be more accessible than one that does. I have not tested every site manually and you may find that some of the valid ones have a valid splash page but fail miserably for the rest of the site. If you find errors, please post them below and I will update the table.

Results

The validation result is presented in a table here. Out of 546 tested web sites only 13 (2.4%) were using valid HTML. No web site used Dublin Core for meta data and the majority of the web sites are using tables for layout. The 13 web sites that did use the W3C recommendations are:

• Bureau of the Public Debt
• Centers for Disease Control and Prevention
• U.S. Commission of Fine Arts
• Commodity Futures Trading Commission Homepage
• United States Court of Appeals for the Federal Circuit
• Federal Emergency Management Agency
• Federated States of Micronesia
• Food and Drug Administration Home Page
• Industrial College of the Armed Forces
• Joint Board for the Enrollment of Actuaries
• The Library of Congress
• Missouri State Government Home Page
• U.S. Sentencing Commission

Coming soon is a look at how New Zealand government web sites use the W3C recommendations.

References

• FirstGov.gov: the U.S. Government’s Official Web Portal.
• Validating an entire site. A modified version of the W3C validator and Python scripts to perform mass validation.

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

Searching for information on how you can increase accessibility in ASP.NET will give you a lot of information on ASP.NET 2.0 (Whidbey) features. It is like Microsoft is trying to hide the fact that the first generation of ASP.NET has issues with accessibility and standards compliance.

Anyway, all is not lost. Here are some tips on what you can do right now to increase accessibility in your existing ASP.NET 1.1 applications. If you are an experienced ASP.NET developer, but new to the field of accessibility make sure you check out some of the other articles here.

1. Try to create standards-compliant pages

If you are using the W3C validator to validate your ASP.NET pages you will notice that no matter what you do in Visual Studio .NET 2003 they will not validate. This is because ASP.NET will ouput hidden HTML to manage view state. However, it is possible to rewrite the output before it reaches the browser. This of course has some impact on performance but if you are using your output cache correctly the performance hit will be of minor importance. There are several ways to rewrite output to make it standards compliant:

1. A C# class to make your ASP.NET pages XHTML valid. A short tutorial with code samples.
2. Valid XHTML within .NET.
3. Ensuring XHTML compliancy in ASP.NET
4. Producing XHTML-Compliant Pages With Response Filters
5. XhtmlWebControls.NET. This is a commercial product. It is a rewrite of all the web controls to make sure they are Xhtml 1.1 compliant.

If you decide to not use any of the above you can still make sure that your web pages use proper semantic markup. You can still use the W3C validator to check for other validation errors. If your application can’t be reached from the internet you can use the Web developer toolbar Firefox extension to validate single pages. If you are working on a large scale project you can set up a validation server and automate testing (instructions in my previous post “Validating an entire site“.

2. Update to .NET Framework 1.1 Service Pack 1

Service pack 1 includes an important update of the datagrid control enabling output of real table header elements and table captions. After the upgrade you can set the UseAccessibleHeader property to true and your datagrid will use the <th> element for the grid headers.

This service pach also contains a fix for the asp:label control. More on that below.

3. Use real labels for your form fields

When designing web pages in Visual Studio .NET 2003 it is easy to quickly set up a web page with form fields. However, using the asp:label control to create field labels is bad as it will be translated to a simple <span> element. You are better off writing the HTML for the label yourself as the visual designer will give you no help. Switch to the HTML source view and use the following code to create a label for your form element:

<label for="<%=TextBox1.ClientID%>">My label text:</label>

You may wonder what the “TextBox1.ClientID” is doing there. As you may know, ASP.NET creates a unique id for all elements that have the attribute “runat=server”. So, to make sure your label is properly connected to your form field you can use “TextBox1.ClientID” which will be translated to the rendered client id of your TextBox1 field.

If you have applied Service Pack 1 you can use the AssociatedControlId property of the asp:label element and get the same result.

4. Do not rely on client-side validation

ASP.NET enables you to easily add client side validation to forms. This method relies on javascript and will be hard to use for vision impaired users (see previous discussion on AJAX and accessibility). It is likely that they will not get any information at all about validation errors. You can still use the server side validation functionality of ASP.NET. Make sure you present your validation errors in an accessible way.

If you have any more tips you feel would be valuable for ASP.NET developers, please post them below.