PowerMapper Software Blog

This posting summarizes some detailed research into the state of government accessibility standards around the world, as of September 2011. Usually these evolve fairly slowly, although the recent Jodhan vs. Attorney General of Canada case may change that (governments don't like being successfully sued by their citizens).

This table shows government accessibility standards, and relevant legislation, in 11 countries:

* Irony Alert: the European resolution insists web site documents should be clear and simple, but kicks off with 22 paragraphs of incomprehensible bureaucratic text. Here's an example:

whereas the internet as a part of society is an instrument for society as a whole, so it is fundamental that technologically neutral access to public information is offered for all groups in society...

The key takeaway from this research: adoption of WCAG 2 is progressing steadily and becoming increasingly important:

• The Australian, French and New Zealand governments have already adopted WCAG 2.
• The Jodhan vs. Attorney General of Canada ruling means the Canadian government is required to adopt WCAG 2.
• UK government sites must comply with either WCAG 1 AA or WCAG 2 AA.
• In the US, Section 508 is being refreshed to harmonize with WCAG 2.
• The European Commission is investigating a move to WCAG 2 as a European government standard, but this is complicated by competing national standards in Germany (BITV) and Italy. 

Edit: originally published November 2010, updated November 2011.

As part of the online demo at try.powermapper.com we collect summary statistics about pages scanned by our service.

One interesting statistic covers versions of HTML and XHTML in common use. As of January 2011:

• HTML 4.01 DOCTYPEs account for about 12% of pages scanned (20% in 2009)
• HTML 5 DOCTYPEs account for about 7% of pages scanned (0% in 2009)
• XHTML 1.0 DOCTYPEs account for about 62% of pages scanned (50% in 2009)
• XHTML 1.1 DOCTYPEs account for about 2% of pages scanned (1% in 2009)
• About 6% of pages scanned have no DOCTYPE (20% in 2009)

HTML vs. XHTML Version Statistics

The HTML 4.01 standard was introduced in 1999, but 11 years later, no major vendor fully implements it.

Controversial, perhaps, but also true. A lot of flak is rightly directed at Internet Explorer's lack of standards support, but the other browser vendors aren't blameless either. Here's a partial list of some HTML 4.01 features not supported in Chrome, Firefox, Internet Explorer or Opera. 

In recent years the W3 has tightened up the process so that features have to be implemented by at least 2 different browsers before a standard can reach Proposed Recommendation status.

The new process is:

• Working Draft - specifications go through a series of working drafts, ending with the Last Call Working Draft
• Candidate Recommendation - the specification is ready to be implemented, although implementation experience may change the specification (e.g. some features may prove impossible to implement with acceptable performance) 
• Proposed Recommendation - each item in a specification has two separate verified implementations
• Recommendation - the specification is complete and all known issues have been addressed

Under the new process the HTML 4.01 specification would still be at Candidate Recommendation level because of the unimplemented features above. Although the new process is slower, it does ensure that W3 specifications never contain features that cannot be implemented. 

In addition to unimplemented features, errors in the specification itself were found after publication, listed in HTML 4.01 errata. The new W3 process makes this far less likely to happen since doing an implementation flushes out any ambiguities and errors.

October 14^th is World Standards Day: this year's theme is making the world accessible for all, which we're passionate about (both personally and as a company). 

Over 650 million people globally are affected by some kind of disability, and one quarter of the world population is over 60, so accessible products and services have a huge audience.

Remember, accessibility benefits everyone:

• Wheelchair ramps in buildings make them easier to get into with prams.
• If you're carrying heavy luggage, accessible public transport is easier to use.
• Accessible websites are easier to find on search engines (because their graphical content is available as text).

This diagram shows how web standards have developed since 1994. Originally HTML and related standards were discussed and agreed by a small group of interested parties on a mailing list. Later the W3 was formed, and it put in place increasingly rigorous processes, with increasing amounts of public consultation.

While solid process and consultation is a good thing, one striking point is how long it now takes to get W3 standards from Draft to Recommendation status. It took 8 years in the case of WCAG 2.0. It's taken 11 years, and counting, for CSS3 (the oldest CSS3 working drafts are dated 1999). The editor of HTML 5 recently forecast a completion date of 2022 for HTML5.

Sources: Dates for W3 standards were culled from the published recommendations and preceding drafts on w3.org. For JavaScript, dates were taken from the Wikipedia JavaScript article. 

This blog has been pretty quiet for the last few weeks because we've been busy releasing an online version of SortSite.

This lets you take SortSite for a spin without having to install any software. We've also started collecting some interesting statistics:

• How many pages with the W3C Valid HTML badge are actually valid
• Which versions of HTML / XHTML are in use
• What percentage of pages render in quirks mode

You can try the online demo and see the stats at http://try.powermapper.com/

About a year ago we converted our site from HTML 4.01 to XHTML 1.0. It seemed like it should be straightforward. After all, we reasoned, XHTML 1.0 is compatible with HTML so it should just be a case of changing the doctype from HTML to XHTML? Wrong.

Here is some legal HTML lifted from section 7 of the HTML 4.01 specification, which validates cleanly in the W3C validator:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML>
<HEAD>
<TITLE>My first HTML document</TITLE>
</HEAD>
<BODY>
<P>Hello world!
</BODY>
</HTML>

If you run the same example through the W3C validator but choose an XHTML doctype every line triggers a validation error.

Why? The bulk of the problems stem from the fact that XHTML is case-sensitive, and all XHTML tags must be lowercase. This means none of the tags above are recognized because they're uppercase.

HTML is case-insensitive and nearly all W3C HTML examples use uppercase tags, which means authors diligently following the spirit and letter of the HTML specifications have produced countless valid HTML pages, which are incompatible with XHTML.

I have some sympathy for the authors of standard: XHTML is based on XML so had to be case-sensitive, and no matter which element case they chose someone was going to lose out. But it was unfortunate that authors following the W3C coding style lost out.

There are a lot of good reasons for switching to XHTML, but there are some drawbacks as well.

Imagine you're responsible for a major e-commerce web site, and you make the decision to migrate the entire site from HTML to XHTML, serving it to standards compliant browsers (like Firefox) using the W3C recommended MIME type application/xhtml+xml.

A couple of months after the switch someone types <br> instead of <br/> when making a minor edit to the main site template. Before the switch from HTML nothing bad would happen. Now every page on the site is displaying an XML parser message in Firefox, you're losing thousands of dollars of sales per minute, and your CEO is asking some very difficult questions.

Why has a tiny change become so catastrophic?

When you're serving HTML browsers treat it as "tag soup" and are very forgiving of errors. Once you serve your pages as application/xhtml+xml Firefox treats them as XML and won't display them if they contain badly formed XML (in this case a <br> without an end tag).

If you've made the decision to go down the XHTML route you should consider a whole-site validation tool, like our SortSite product. After all, your job might depend on it.