Content Copyright © 2010 Bloor. All Rights Reserved.
Think about a blind person using the Internet; most of the time most sites provide a bearable service: information can be retrieved, catalogues searched, and forms filled in; but every so often they break: important information is contained in an image without any alt text to describe it, a link has no useful description, the reading order is illogical, or the submit button is inaccessible unless you use a mouse. The 10% of problems make the experience extremely frustrating and time-consuming and in the worst cases mean that the user fails to complete what they had intended to. To avoid this, users would really like to know before using a website whether or not it has been designed to meet their particular needs.
Some sites may help a bit by including an icon saying WCAG AA compliant. This is only of limited use because it is not easy to search for sites that include this icon, it’s not always easy to find the icon on the page, and it is only an assertion by the owner of the page that it is in fact accessible.
What is needed is some formal machine-readable methods of being able to assert the accessibility of a page, have this certified by a third party, and be able to report any non-compliance.
Just as a blind user would appreciate this information, a website owner who has gone to the trouble of making their site accessible, wants to be able to advertise that in a usable way.
If the assertions and certifications were machine readable then this information could be used by:
- Search engines to prioritise page and sites that support the user requirement.
- Browser plug-ins to announce that a page supports their requirements (or that the site specifically does not support the requirement).
- Agencies that monitor accessibility of websites as they could quickly discover sites that have not made assertions and therefore may not be compliant.
Making assertions about accessibility of a web site or page is just part of a bigger requirement of making assertions such as: child friendly, contains adult content, scientific claims have been peer reviewed, etc.
This requirement has been known for many years and some attempts have been made to address it (notably PICS Platform for Internet Content Selection) but nothing has been sufficiently general and robust to really catch on, except in very specific areas, such as secure payments.
The biggest stumbling block to implementation was the lack of a standard format for encoding the assertions and certifications. This has now been removed by the publication of the W3C Recommendation POWDER (Protocol for Web Description Resources) http://www.w3.org/TR/2009/REC-powder-dr-20090901/ in September 2009.
The heart of POWDER is the Description Resource (DR) which is an XML document that defines:
- Who it is issued by.
- When it was issued.
- Which resources it covers (for example web pages).
- What it asserts about the resources.
- Who certifies the assertion.
Resources that are included in the DR will typically include a link to the DR, this will enable a user to know what has been asserted about the resource and what trust they can have in the assertion. If the issuer of the DR is unknown to the user and the certifier is also unknown then the level of trust will be low; but if either or both are trusted by the user then the level of trust will be much higher.
A company called Segala was one of the organisations involved in the development of the protocol. Segala span off a new company—MetaCert—that is now working (according to its web site in ‘stealth mode’) to take POWDER and build the necessary technology to implement the protocol and exploit its benefits.
When these technologies start to become commercially available the next hurdle will be to create an impetus for their use. If few websites use the technology then search engines will not provide the specialise search facilities that take advantage of them; and conversely if search engines and browsers do not support the technology then there is no incentive for web site owner and developers to add the extra function.
An ideal way way to create the impetus would be through legislation. For example Section 508 could be extended to say that companies wishing to do business with the US government authorities must have compliant websites and this must be asserted by the use of POWDER. This may happen in the future but I suspect it is unlikely to be the early impetus that is required.
Another option is a grass roots drive. In this scenario an organisation representing people with disabilities could create a DR repository which their members could search to find accessible sites. In the first instance this might be created by a reporting system, the users would report non-conforming sites or identify conforming sites.
A third route is through commercial benefit. The first example of this will probably be in the adult entertainment arena where ICM Registry are planning to set up a new Sponsored Top Level Domain (sTLD) .xxx ; MetaCert are in advanced discussions with ICM Registry to be the labeller of choice. The labelling will assert that the web site abides by a code of conduct for adult content, this should help to protect people from accessing inappropriate content.
My idea for the promotion of accessibility labelling based around POWDER is as follows:
- Reporting web site accessibility could be done through a browser plug-in (or by code integrated into the browser that supports POWDER). Whilst viewing a page the plug-in could be invoked and the user could report an issue or identify a page in a positive way. Firefox has a rudimentary version of this concept in the Report Broken Web Sites function under Help. If the user was willing, the plug-in could identify all the pages viewed and assume they are accessible if not reported otherwise.
- All the information collected could be collated and synthesised to create the DR repository. This method might quickly produce a useful and significant body of knowledge which could then be attractive to search engines to support. Its slightly arbitrary nature (those sites that the users had reported on) might encourage website owners to create their own more complete and reliable DR’s.
- I believe that the ability to report inaccessible pages in a consistent manner is fundamental requirement. If it is not available and a page claims to be accessible what is the user meant to do? Some sites might include a feedback option and I would recommend that sites do provide this facility. However, it is inevitable that each site feedback system will be subtly, or even grossly, different from other sites and therefore the user is less likely to use them. If the plug-in was used the central site could pass this information on to the relevant site owner, this would be easier if the site used POWDER.
There are several organisations that might be interested in pursuing this idea and I would be very interested in hearing from them if they do.