PowerMapper Software Blog

Covers product updates, company updates and useful information on accessibility, browser compatibility and search engine optimization / SEO.

Government Accessibility Standards and WCAG 2.0

posted by Mark Rogers on Mar 22, 2012 |

Accessibility | Web Standards

This posting summarizes some detailed research into the state of government accessibility standards around the world, as of March 2012. 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).

In general, these standards apply to government agency websites (and not commercial web sites) with the exception of Australia where commercial sites as also required to comply. Other countries have disability discrimination laws which cover websites, but these don't specify the technical standards required to comply with the law.

This table shows government accessibility standards, and relevant legislation, in 17 territories:

Country	Standard	Legislation	Applies To
Australia	WCAG 2 AA	Disability Discrimination Act	All government and non-government websites should comply with WCAG 2 AA by end of 2013
Canada	WCAG 2 AA	Human Rights Act 1977	Common Look and Feel 2.0 required WCAG 1 up till July 2011 for all government websites. The Jodhan vs. Attorney General of Canada ruling requires the Canadian government to update the guidelines to WCAG 2, and this was implemented as the Standard on Web Accessibility on Aug 1, 2011.
EU	WCAG 1 AA	European Parliament Resolution (2002) 0325*	Required for all EU commission websites - see EUROPA - Web accessibility policy. Progress towards WCAG 2 is being done by the Mandate M 376 working group which started work in 2006.
France	RGAA 2.2.1 (based on WCAG 2)	Law No 2005-102, Article 47	Required for all French central government websites by May 2010. All other French public websites (public services, towns, public research, etc) are required to comply by May 2011.
Germany	BITV 2 (based on WCAG 2)	Federal Disabled Equalization Law (BGG)	BITV 2 came into force on Sept 22, 2011, and is required for all government websites. It is based on WCAG 2, but not identical.
Hong Kong	WCAG 2 AA		WCAG 2 AA became the standard for GovHK websites in March 2012.
India	Guidelines for Indian Government Websites (based on WCAG 2 A)		WCAG 2 Level A became the standard for Indian government websites in February 2009.
Ireland	WCAG 1 AA	The Disability Act 2005	All government websites - Code of Practice on Accessibility of Public Services and Information Provided by Public Bodies
Italy	Technical Rules of Law 4/2004 (based on WCAG 1 AA)	Law No. 4/2004 (“Stanca” Law)	Required for all government websites
Japan	JIS X 8341 (based on WCAG 2)		Based on WCAG 2 with provisions made for the Japanese language and input systems. Required for all local and central government websites. Commercial websites are also encouraged to use it.
Netherlands	WCAG 1 A		Government websites must comply with the government web guidelines, which include WCAG 1 A. There are no requirements for non-goverment websites.
New Zealand	WCAG 2 AA	Human Rights Amendment Act 2001	New Zealand Government Web Standards 2.0 (WCAG 2 AA) required for all government web sites.
Ontario	AODA (WCAG 2 AA)		Required for all new Ontario government websites by January 2012, and existing government websites by January 2016.
Quebec	SGQRI 008 (based on WCAG 2)	Standards sur l'accessibilité du Web	Custom made standard based on WCAG 2.0 with specifics covering websites, downloadable documents and multimedia.
Spain	UNE 139803:2004 (based on WCAG 1 AA)	Law 34/2002, Law 51/2003	Required for all government websites. No mandatory requirements on non-government websites.
United Kingdom	WCAG 1 AA or WCAG 2 AA	Equality Act 2010	The COI standard for inclusive websites requires WCAG 1 AA or WCAG 2 AA for all UK government web sites. Other UK websites need to comply with the Equality Act and provide equal access, but this doesn't specify technical standards (although complying with at least WCAG 1 A or 2 A demonstrates that accessibility issues have been considered).
USA	Section 508 (subset of WCAG 1 with a few additions)	Section 508 of Rehabilitation Act	US federal agencies' websites must comply with Section 508 guidelines. These are currently being updated - a draft update was released in March 2010 with another due in December 2011.

* 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 governments of Australia, Canada, France, Germany, Hong Kong, Japan and New Zealand have already adopted 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 March 2012.

tags: Section 508, WCAG2

Comment »

Desktop Quarterly Releases - Feb 2012

posted by Mark Rogers on Mar 21, 2012 |

PowerMapper | SortSite

The latest quarterly PowerMapper and SortSite maintenance releases are now available.

New features include:

View Source command added to right click menu
Updated W3 DTDs to match validator.w3.org (pulls in fix for usemap in XHTML 1.1 Second Edition)
Added compatibility checks for Firefox 9,10,11 and Chrome 16,17 versions
Added support for CSS3 properties that have reach candidate recommendation status

Fixes include:

Handle zero sized thumbnail images caused by buggy display driver
Avoid blank thumbnail images on pages that only contain Flash movies or META refresh directives
Don't detect broken anchors in non-standard CSS e.g. behavior:url(#default#savefavorite)
Various false positives
False negative: didn't detect empty headings
False negative: <A ONCLICK> with no HREF cannot be operated from keyboard

These are available to all customers with active support and maintenance contracts via the Update Watch feature in each application.

tags:

Comment »

W3 ARIA - why doesn't it validate?

posted by Mark Rogers on Mar 4, 2012 |

Accessibility | SortSite | Web Standards

The W3 ARIA recommendation specifies new HTML attributes (like "aria-describedby") to help screen readers identify relationships between elements. These new attributes tell screen readers about relationships that can't be derived from existing HTML semantics, and usually only obvious from the position of items on screen (e.g. a paragraph of help text next to a form field).

Most people who've tried adding ARIA attributes to HTML have noticed that documents don't validate unless the HTML 5 DOCTYPE is used: <!DOCTYPE html>.

Why is this - are the validators all broken? Unfortunately, the problem is worse than this.

What's the problem?

The validation rules used by validator.w3.org and the other validators out there (including SortSite) use a machine-readable description of HTML called a Document Type Definition (DTD). Prior to HTML 5, each version of HTML and XHTML was specified by a DTD describing which element and attribute names are allowed in a document.

Here's the problem:

The W3 specifications of HTML 4.01 (1999), XHTML 1.0 (2000 revised 2002) and XHTML 1.1 (2001 revised 2010) all pre-date ARIA (2011) so weren't aware of ARIA at the time of writing.
The W3 specifications all contain DTDs that are marked as normative (i.e. the DTDs are a prescriptive part of the specification, so cannot be changed and aren't open to interpretation).
This means that ARIA can't be added to these DTDs without revising the underlying specifications

In retrospect, including DTDs as part of the normative specifications of HTML and XHTML was probably a mistake by the W3 working groups, and one that's been avoided in HTML 5 which doesn't use DTDs. HTML 5 also has the advantage that it's still draft, which allowed ARIA to be added relatively easily.

Don't expect the W3 to add ARIA to DTDs for old versions of HTML any time soon. Even fixing obvious bugs in the DTDs takes a very long time, because it requires a specification revision. The usemap bug in the XHTML 1.1 DTD took 8 years to fix - prior to the 2010 revision of XHTML 1.1 you had to choose between working image maps or valid code.

Does HTML 5 fix this?

Going the HTML 5 route isn't a panacea: the validation rules for HTML 5 never quite match the current HTML 5 draft specification because the draft is constantly changing, as do the HTML 5 validation rules. The HTML 5 validator is quite up front about this, when you validate HTML you see this message:

"The validator checked your document with an experimental feature: HTML5 Conformance Checker. This feature has been made available for your convenience, but be aware that it may be unreliable, or not perfectly up to date with the latest development of some cutting-edge technologies."

This situation is likely to continue until HTML 5 reaches Candidate Recommendation status - probably sometime in 2012/2013.

What else can I do?

The ARIA working group are aware of the problem, and have produced two unofficial DTDs that do allow ARIA to validate:

XHTML 1.1 with ARIA
http://www.w3.org/TR/wai-aria/appendices#xhtml_dtd

HTML 4.01 with ARIA
http://www.w3.org/TR/wai-aria/appendices#html_dtd

These DTDs are both available in validator.w3.org and SortSite 4.6, but as the ARIA recommendation notes, using the DOCTYPEs for either of these DTDs cause significant problems in browsers (such as character entities like   not working correctly).

In SortSite the other option is to to selectively ignore validation errors for aria- prefixed attributes using Ignore Rule menu command. To do this right click on the Rule Options link next to an error for an aria feature, and choose Ignore Rule.

Catch 22?

If you want to use ARIA and be standards compliant you're in Catch 22 situation:

Use the HTML 5 doctype (but be aware that what validates today may not validate tomorrow because the HTML 5 validator isn't stable yet)
Use ARIA in HTML 4.01 or XHTML 1.x and live with the validation errors and the fact you're no longer compliant with the XHTML and HTML 4 specifications (plus you risk missing real validation errors in a sea of ARIA validation errors)
Use a validation tool that lets you disable ARIA specific validation errors

tags:

Comment »

How disabilities affect website use

posted by Mark Rogers on Feb 4, 2012 |

Accessibility | Web Standards

This post follows on from the one on Disability Statistics, and shows how the most common disabilities affect website use.

Reading Difficulties

Reading difficulties and dyslexia are extremely common, and affect 15-20% of US adults. Some groups (such as entrepreneurs) have rates approaching 40%.

This group often finds problems with:

large blocks of text
very high contrast text*, such as black text on pure white affects people with Scoptic Sensitivity Syndrome (which makes the letters dance about)
fully justified text aligned to both left and right margins (contains rivers of whitespace which break up the text)
flashing or moving elements, which attract the eye and make it hard to concentrate on reading text

* Note that the high contrast required by WCAG 2 checkpoint 1.4.3 can actually cause problems for people with Scoptic Sensitivity Syndrome, and also some low vision users who need to read the screen very close up (put your face next to your screen for 30 minutes on a very high contrast page to see how unpleasant this feels).

Color Blindness

Color blindness is also very common, and affects around 8% of caucasian males in the US, but only 0.5% of females. Color blindness comes in many varieties with red-green and blue-yellow color blindness the most common, and inability to see any colors (monochromacy) the rarest.

This group often finds problems with:

text and background colors with little difference in brightness
red text on a green background, or green text on a red background (looks like brown text on a brown background to someone with red-green color blindness)
blue text on a yellow background or yellow text on a blue background

Dexterity Difficulties

Problems using hands and arms affects around 7% of the population, and can make using a mouse hard or impossible. Older people are more likely to have dexterity problems due to the onset of arthritis. Even if users can use a mouse, they'll find it hard to click on small link targets (such as single character links).

This group often finds problems with:

pages that can only be operated with a mouse (e.g. many street mapping websites)
very small links that need very precise motor control to click (e.g. the single character links often used for paging)

Difficulty Hearing

This affects around 4-5% of the population, and becomes more common with age. Relatively few websites use audio, so the majority of sites are unaffected. Many office workers are in the same position, since they have no way of hearing website content at work (speakers are very uncommon in offices, and headphones are frowned upon in some corporate settings).

This group often finds problems with:

videos where the audio track is needed to understand the content (e.g. a recording of a TV news bulletin)
standalone audio (e.g. a radio play)

Difficulty Seeing

This affects around 3-4% of the population and includes people who are blind and those with low vision who need large print and/or high contrast to read (e.g. people with cateracts or retinal damage caused by diabetes).

Blind people (and some dyslexics) typically use a screen reader, which read out the words on web page, but reading each word out individually is very time consuming so:

they use the <title> tag to find out what a page is about before going to the effort of reading it (so the same title on every page is not useful)
they often read out all the headings and link text first to figure out what a page is about (screen readers have shortcut keys for this)
the use headings inside the page to navigate to the section they're interested in (so pages without headings are hard to use)
they need a quick way to skip navigation links at the top of the page (you don't want to have to listen to 100 navigation links before hearing the page content)

People with low vision:

often use browser zoom feature to enlarge all the content (normal text enlarges well, but text inside graphics becomes pixelated)
may use a custom CSS stylesheet to enlarge text and provide color combinations that work for them (e.g. 24 point yellow text on a black background). This poses difficulties if your pages are unreadable without your site's CSS stylesheet.

tags:

Comment »

Picking Christmas Cards for People with Limited Vision

posted by Pam Nairn on Dec 13, 2011 |

Accessibility

Well, it’s that time of year again. While I consider myself one of life’s formidably organised Christmas present buyers (I started in August) I seem to fall sadly short when it comes to finding the time to write and post my Christmas cards.

I know that to many, card writing seems an outmoded way of sending Christmas greetings, but for many of my ageing relatives, some of whom now live alone, a hand written card arriving in the mail is still much appreciated. Besides, I still enjoy choosing the cards - I fancy I always find something pretty tasteful!

Recently, a close friend paid me a compliment which really cheered me. Her mother has very limited vision - she's been registered blind for as long as I’ve known her. When choosing her card, I’ve always made certain that the design is simple, bold and very colourful. To me that just makes common sense. Surprisingly, few others do, and my friend tells me that her mother always enjoys my card arriving in the mail - it’s one of the few she can see.

Since accessibility plays a large part in what we do here, I was pleased to know that I was practising what we preached.

tags:

Comment »

Having something important to say always beats slick presentation

posted by Mark Rogers on Oct 29, 2011 |

Accessibility

Today is World Stroke Day, which aims to raise awareness of the condition. Earlier this week I saw a conference keynote speech by Clayton Christensen, author of The Innovators Dilemma and a Professor at Harvard Business School.

He introduced himself by apologizing for hesitating while speaking because he'd suffered a stroke a few months earlier. In spite of this he was an engaging speaker - much better than the other professional conference speakers. His points came across so well because he's been thinking about them for decades and backed them up with well-researched evidence. His only concession was asking the audience to interject when he couldn't remember a word, but this made the presentation more interactive and memorable.

At the end of the day having something important to say always beats slick presentation.

tags: aphasia

Comment »

PowerMapper and SortSite Quarterly Releases

posted by Mark Rogers on Sep 12, 2011 |

PowerMapper | SortSite

The latest quarterly PowerMapper and SortSite maintenance releases are now available.

New features include:

BlackBerry, Firefox 5 and Chrome 12 added to browser compatibility tests
Autocomplete for forms
Enhanced spell checking options

Fixes include:

Performance improvements
Handle Arabic character encoding in content rules
Handle pages with contradictory character encoding in HTTP headers and META charset

These are available to all customers with active support and maintenance contracts via the Update Watch feature in each application.

tags: Release

Comment »

SortSite OnDemand August 2011 Release

posted by Mark Rogers on Aug 29, 2011 |

SortSite

SortSite OnDemand has just been updated for all subscribers. New features in this release include:

Mobile browser compatibility checks for BlackBerry
Added Firefox 5 and Chrome 12 to browser compatibility tests
Added self-service password recovery
Added delete scans and delete scan history
Added scope option to quick scan on home page

Bug fixes include:

Expand All button in reports was slow on large sites with lots of errors
Correctly handle pages that specify different charsets in HTTP headers and META tags
Handle windows-1256 (Arabic) character set correctly in rules
Fixed false positives and false negatives

tags: Release

Comment »

Website Accessibility: Disability Statistics

posted by Mark Rogers on Jul 21, 2011 |

Accessibility

This post is a compilation of disability statistics from government agencies and researchers in the US, UK and Canada. The statistics shown have most impact on website use, and help assess the impact of accessibility problems, in terms of numbers of people affected, and likely commercial impact.

Incidence of Key Disabilities

Reading Difficulties		15%-20% of people in the US have reading difficulties, including dyslexia (source: nih.gov). A recent study by Cass Business School showed that around 20% of UK entrepreneurs and 35% of US entrepreneurs are dyslexic (Bill Gates and Richard Branson are textbook examples).
Color Blindness		8% of males in the US suffer from some form of color blindness, compared to 0.5% of females. (source: aao.org). Incidence of color blindness differs between ethnic groups - from 1% in Eskimos to 10% in Caucasian males.
Dexterity Difficulties		7% of working age adults have a severe dexterity difficulty (source: The Wide Range of Abilities and Its Impact on Computer Technology - Microsoft / Forrester). Severe dexterity difficulties mean users are unlikely to use a mouse, and rely on the keyboard instead.
Difficulty Hearing		4%-5% of people in the US, UK and Canada suffer from difficulty hearing (sources: census.gov, Statistics Canada, UK ONS) Incidence increases sharply in over-60s, with more than 20% of over-75s affected.
Difficulty Seeing		3%-4% of people in the US, UK and Canada can't see well enough to read (sources: census.gov, Statistics Canada, UK ONS) Incidence increases with age, with more than 10% of over-70s affected.

Note: Government statistical agencies produce these numbers from questionnaires, but questions aren't standardised between countries, so figures are not directly comparable from country to country. For example, the questions "do you have difficulty seeing" and "do you have difficulty seeing newsprint" produce different response rates.

Incidence of Disability by Age

Reading, hearing and cognitive difficulties affect less than 5% of population under 55. Incidence increases with age: 10% of over 65s are affected, and more than 15% of over 75s are affected.

Hearing and sight becomes poorer as people get older, but these same people often have large amounts of disposable income and leisure time. This presents particular challenges for web sites selling items which appeal to an older demographic, such as travel and cruises (source: census.gov).

tags: statistics

Comment »

Can website accessibility declarations be trusted?

posted by Mark Rogers on Jun 19, 2011 |

Accessibility

The Design for All Research Group at Middlesex University have produced a report called Declaring conformance on web accessibility asking the question: can website accessibility declarations be trusted?

Sadly the conlusion was no, for both self-declared and thirdy-party certifications, confirming the findings of earlier studies. Using a sample of 100 European government and commercial sites claiming accessibility standards conformance, more than 95% were found to have accessibility issues. The study used our automated tool, SortSite, in conjunction with manual testing performed by the accessibility group at the Shaw Trust (see the report for details on methodology).

The results on accessibility conformance mirror results we see with sites claiming to be valid HTML. About 30% of sites displaying the W3 "Valid HTML" and "Valid XHTML" badges fail validation. Although false validation claims are a smaller proportion than false accessibility claims, it's more surprising since:

the validation test is completely automated so should be easy to run
using the W3 "Valid HTML" badge on invalid pages is a breach of the W3's terms of use

In practice ensuring entires sites are accessible and conform to standards is tough to do manually. Even a medium sized site with 10,000 pages takes over 200 days to test manually, assuming an 8 hour working day, and 10 minutes spent testing each page for accessibility and web standards compliance. To underscore this point, the original version of the report was published as an untagged PDF, making it hard to use in a screen reader. A quick run through an accessibility checklist or automated checking tool could have prevented this.

tags: WCAG 2.0, accessibility

Comment »

In this section

Free Online Demo

Test websites for accessibility, broken links, browser compatibility, SEO and over 450 quality issues:

PowerMapper Software Blog

Government Accessibility Standards and WCAG 2.0

Desktop Quarterly Releases - Feb 2012

W3 ARIA - why doesn't it validate?

What's the problem?

Does HTML 5 fix this?

What else can I do?

Catch 22?

How disabilities affect website use

Reading Difficulties

Color Blindness

Dexterity Difficulties

Difficulty Hearing

Difficulty Seeing

Picking Christmas Cards for People with Limited Vision

Having something important to say always beats slick presentation

PowerMapper and SortSite Quarterly Releases

SortSite OnDemand August 2011 Release