Standards Schmandards

Swedish National Guidelines for Public Sector Websites

peter.krantz — Mon, 28 Apr 2008 18:57:44 +0000

The Swedish National Guidelines for Public Sector Websites takes an integrated approach to usability, accessibility and standardization. The purpose of the Guidelines is to support the procurement, development, and maintenance of a website by a public administration so that it offers equal opportunity usage for all citizens. The 2006 version has now been translated to english.

Quoting from the announcement: “The Guidelines are divided into chapters which can be read separately depending on the reader’s role and responsibilities. The order of the chapters is intended to mirror the lifecycle of a website.

Chapter 1 covers the overall communications objectives of a website, which should be used as the basis for its development.
Chapter 2 presents the development process as steps towards a defined objective.
Chapter 3 shows methods for website design and web page coding, along with web standards.
Chapters 4 and 5 describe the basic content and services a website should provide, giving additional information on how to write for web-based media as well as methods for keeping the website up to date.
Chapters 6, 7 and 8 cover the development of web content for mobile devices, Content Management Systems (CMS) / authoring tools, and assistive technologies (AT).

A survey carried out in February 2007 showed that over 90% of those responsible for public administration websites in Sweden were aware of the Guidelines, with 80% or more actively using them.”

The Guidelines are published under the Creative Commons Attribution 2.5 Sweden license.

RDFa - Implications for Accessibility

peter.krantz — Tue, 04 Sep 2007 21:26:05 +0000

Here are my initial thoughts on how I believe RDFa will benefit web accessibility. If you are new to RDFa I recommend reading the Wikipedia entry on RDFa and the W3C RDFa primer as an introduction.

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:


	My name is Jo Smith. I'm a distinguished web engineer at
	Example.org.
	You can contact me
	via email.

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:

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


	My name is
	Jo Smith.
	I'm a
	
		distinguished web engineer
	
	at
	
		Example.org
	.
	You can contact me
	
		via email
	.

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:

Position Title

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:

Browser opens the web page.
Screen reader parses the HTML and extracts references to all external vocabularies.
External vocabularies are fetched and parsed for labels and descriptions.
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:

Mental Workload for Paged and Scrolled Documents

peter.krantz — Sun, 24 Jun 2007 21:12:18 +0000

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:

Consumption of information is more efficient when information is presented on paper compared to presenting the information on a computer screen.
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:

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

Bringing Accessibility into the Development Process

peter.krantz — Fri, 30 Mar 2007 14:49:18 +0000

Web accessibility is, in my experience, often considered late in the development process. Typically, accessibility evaluation is conducted by outside experts after the application is delivered and content is produced. This leads to issues being reported to developers late in the project, at a time when changes cost more.

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.

Evaluation of WYSIWYG editors (2007)

peter.krantz — Wed, 07 Feb 2007 11:48:57 +0000

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:

EditOnPro by Realobjects. Commercial license.
XStandard by Belus Technology. Commercial license. Lite version free (also see special license for open source CMS projects)
FCKeditor by Frederico Caldeira Knabben. Open source (LGPL), commercial license available.
CuteEditor by Cute Soft. Commercial license.
TinyMCE by Moxiecode. Open source (LGPL).
New: Xinha. Open source BSD-style license.
New: WYMeditor. Open source (MIT and GPL). For an introduction to WYMeditor see Visually Editing Semantics - What You See Is What You Mean.
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?

Search Accessibility Guidelines for Web Sites

peter.krantz — Sat, 06 Jan 2007 00:08:12 +0000

I have created a Google co-op custom search engine with which you can search web accessibility guidelines. I have categorized each included page by country (for government guidelines) and I am adding more guidelines and categories. This means you can easily search e.g. the New Zealand guidelines for PDF recommendations.

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

Visually Editing Semantics - What You See Is What You Mean

peter.krantz — Tue, 05 Dec 2006 20:36:08 +0000

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.

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?

New Version of Guidelines for Swedish Public Sector Web Sites

peter.krantz — Tue, 14 Nov 2006 20:50:41 +0000

Verva, the Swedish Administrative Development Agency has released an updated version of the guidelines for Swedish public sector web sites. The document is used by public organizations when procuring new web sites as well as by developers as an aid in the development process.

No english translation is available yet, but I know there will be a summary in english in the beginning of 2007. In the meantime, here is an overview of the guidelines:

Efficient service - use technology as a tool to optimize your organization processes. Use standards for information exchange.
The development process - integrate usability in the development process and don’t detail requirements upfront.
Web site standards - use technical standards as well as standards for structure, navigation and design. Code for a markup standard rather than targeting specific browsers.
Web site content and services - minimum requirements for web site content. Provide basic information in sign language and minority languages.
Keeping the web site alive and up to date - write in a clear and simple lanugage (for a summary see my previous article “Working with content…”), monitor traffic statistics and learn user behaviour.
Considerations for mobile terminals - ensure the web site works resonably in a mobile terminal. Provide a stylesheet for handheld terminals. Use the W3C Mobile web best practices for more information.
Content management systems - guidelines for choosing a CMS: should handle web standards, should not force the editor to use a specific web browser, technology independent URLs, should have integrated support for accessibility checks.
Assistive technologies for web browsing - introduction to assistive devices and ways users may access the web site.

If you are interested in knowing more about a particular chapter, post a comment below and I will try to expand the translation in that particular area. I have contributed as a co-author to some of the guidelines in this version as well as the previous.

EIZO Releases Color Vision Deficiency Simulation Monitor

peter.krantz — Fri, 03 Nov 2006 10:59:26 +0000

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.

Don’t Provide an Accessibility Statement

peter.krantz — Sun, 22 Oct 2006 21:25:32 +0000

When I surf the web I see more and more sites providing an accessibility statement. Googling for “accessibility statement” returns over twelve million pages. What do these statements contain? Why would you want one? Who reads them? This article will try to make two points: 1. accessibility statements are often pointless and 2. you are better off with a “site help” if you think your target audience need it.

A recent study by Digital Media Access Group, Evaluating the Usability of Online Accessibility Information, came to the conclusion that accessibility statements often are difficult to comprehend for users. In fact, naming them “Accessibility statement” meant that many users did not look at them at all. This, of course, isn’t strange. The meaning of the word “accessibility” isn’t clear to everyone.

The Current State of Statements

Looking through some of the accessiblity statements you find on the web I can’t help noticing the amount of technical jargon. Many of them contain information about the accessibility testing procedures used when building the website. Why would a user want to know about that? My guess is that companies are trying to promote the image of themselves as being good net citizens. Looking through some of the pages returned from the Google search reveals some similarities. Sample fragments:

“All pages on this site are Bobby AAA approved.”
“WCAG AAA approved.”
“Valid HTML 4.01 Strict”

For the average user this means absolutely nothing. A page filled with technical jargon is likely to be skipped by many users. These types of accesibility statements are pointless.

Providing a site help instead

The report Evaluating the Usability of Online Accessibility Information shows that a “site help” is much more efficient compared to an “accessibility statement” provided you don’t fill it with technical crap. This, of course, is nothing new.

As with all other information you should start by defining your target audience. Depending on your audience and the functionality of your site you may come to the conclusion that there is no need for even a site help. If you know your target audience you can establish a baseline of technical knowledge. This baseline will aid you in making decisions on what should go into the site help.

This blog, for example, assumes that the reader knows that underlined text can be clicked and how to use the search field, hence the lack of an accessibility statement.

So, get rid of your “Accessibility statement” today and provide some useful information instead. Different opinion? Post your comments below.