Bruce Lawson’s personal site

The Disability Rights Commission (DRC) is an independent body established in April 2000 by Act of Parliament to stop discrimination and promote equality of opportunity for disabled people.

In April 2004, it conducted a formal investigation into the state of web accessibility in the UK, discovering that 81 percent of sites failed to uphold the simplest WCAG recommendations (level A). As a direct result of this rather shocking finding, the DRC then commissioned the British Standards Institute (BSI) to produce Publicly Available Specification (PAS) 78, which “outlines good practice in commissioning websites that are accessible to and usable by disabled people.”

This specification was initially authored by Julie Howell, a respected accessibility campaigner who works for the Royal National Institute for the Blind, in conjunction with representatives of the BBC, UK Cabinet Office, IBM, the University Professionals Association and Tesco.com. It was then reviewed by a large team of stakeholders (including me).

The PAS is intended to help people who commission web design, rather than developers themselves. It is written as a document that commissioners can understand and can discuss with web design project managers. Reference is made to WAI guidelines, usability testing,

Tesco and Legal and General got great ROI from their accessible sites, almost as side-effects

In short, you’re daft if you don’t do it.

The Launch bash

The launch bash was jolly enough; there was discussion of the PAS itself and speeches by luminaries such as Anne McGuire MP, Minister for Disabled People, and case-studies from organisations who have put accessible design into practice.

The most interesting for me of these was the presentation by David Rhys Wilton, Head of Internet Marketing at the Legal and General finance house.

The Financial Rewards of Accessible Web Sites

Legal and General aren’t a fluffy charity, but were worried by their exposure to litigation under the DDA. They identified their major problems as

• Content not web-friendly: PDFs
• JavaScript dependency in forms and navigation
• Too much industry jargon
• Developer’s knowledge of accessibility inadequate

After a program of re-design using third party testers, they reduced their risk of legal action and found, as side-effects:

• A 30% increase in natural search-engine traffic
• “significant improvement” in Google rankings “for all target keywords”
• 75% reduction in time for page to load
• Browser-compatibility (not a single complaint since)
• Accessible to mobile devices
• Time to manage content “reduced from average of five days to 0.5 days per job”
• Savings of £200K annually on site maintenance
• 95% increase in visitors getting a life insurance quote
• 90% increase in Life insurance sales online
• 100% return on investment in less than 12 months.

March 2007: Further presentation from Legal and General on these results.
April 2007: Presentation by Isolani, lead developer at Legal and General.

The Guidance

PAS 78 is not compulsory. The DRC’s announcement explains:

A PAS is not a full British Standard but is developed using the same rigorous processes. We are supporting a PAS on website accessibility as it can be introduced more quickly than a British Standard which can often take several years to be introduced. The other advantage of supporting a PAS is that it can be updated frequently.

However, at the launch event, the Director of Legal and Operations at the DRC, Nick O’Brien, explained that the DRC had hitherto been “conciliatory” rather than litigious, but that could change now the PAS has been launched. I asked him specifically whether the PAS would be a document which they would cite in a court case and Nick replied that it would.

Here’s some edited highlights.

Relationship between PAS and W3C specifications

The PAS makes the following recommendations:

• Developers should follow the lead of the W3C and Web Content Accessibility Guidelines 1.0: WCAG are the most important accessibility guidelines for web commissioners to be aware of, as they are considered to be the de facto standard for accessible web design (6.4.2.1)
• All relevant W3C guidelines and specifications should be used(7.1.1) and Additional accessibility provisions are not essential and should never replace upholding W3C guidelines and specifications(4.6).
• CSS is explicitly advised:Content should be separated from presentational attributes . . . Content should be coded using structural languages .. Presentational attributes should be coded using style sheets (7.1.2–4) .

PDF and Flash

The PAS notes that PDF and Flash are proprietary (but published) formats that have significantly increased their accessibility in recent releases (7.5.2), but cautions:

PDF and Flash should only be used if it is determined that these are the most appropriate formats for content delivery in each case (for example if they enhance understanding and functionality for a group of users at whom the material is primarily aimed) and used in accordance with available authoring tool guidance.(4.2.2.2)

I would like to emphasize that the PAS suggests that PDF/Flash should be used to benefit the end user, not the content authors. It is generally accepted that well-thought-out Flash can benefit some users with cognitive disabilities, so this is a point well made.

Of course, there are times when the PDF format does benefit the user (government forms, for example, where layout integrity is vital). But a very a common reason for using PDFs is to quickly repurpose printed documents to be “on the Web”, without all that tedious HTML coding. Additionally, some organizatons favour PDFs because they believe that format can preserve branding, corporate typefaces, and the like. These particular reasons may very well benefit the originating organization, but generally are of no benefit over HTML to the end users, regardless of their disability.

User testing is central

The PAS draws the distinction between technical accessibility and real, usable accessibility, and advises involvement of users at all stages of the design process. It advocates the publication of an accessibility policy: The website commissioner should ensure that an accessibility policy is in place for the website and this policy should be prominently displayed on the website(6.1.1). The policy should be a working document: All contractors should be asked specifically to commit to helping the organization meet its accessibility policy and this should be reflected in all contracts(6.1.4).

Refreshingly, the PAS cautions against over-reliance on automated accessibility testing, noting, they can be useful for analysing a whole site for technical accessibility (8.3.1). It warns, Website commissioners should not rely solely on automated conformance testing tools to assess conformance with the relevant W3C guidelines and specifications . . . Automated tools may be used as part of the validation process, but additional manual checks and user testing with disabled people are essential to be confident that your website is accessible to disabled people(4.3.1–2) .

The PAS also recommends designing for accessibility, rather than attempting to retrofit a website after it’s built: Website commissioners should test for accessibility compliance throughout the website’s design lifecycle. The earlier accessibility problems are found, the easier and cheaper they are to fix (8.1.6). It states that accessibility is a process, not a product: Website commissioners should ensure a regular programme of accessibility testing after the website launch to maintain the desired level of accessibility (8.5.1).

Considerable emphasis is placed on involving disabled people at all stages of design and testing, using a user-centered design methodology, and this was reinforced by every speaker at the launch jolly.

Responsibilities of Suppliers and Users

Not all the responsibility for accessibility is placed on the author, however. Annex G is a checklist for those purchasing authoring tools to ensure that it is even possible for proposed off-the-shelf content management systems to separate the content and styling, add alt-text, and so on. Suppliers are referred to an organization’s accessibility policy: describe how your proposed package will ensure generated web pages meet the accessibility targets outlined within our accessibility policy (Annex C3) and Describe any scenarios where the package application will not generate compliant WCAG [level] web pages and what will be done to correct this non-compliance(Annex C3) .

The PAS also recognizes that it takes two to tango—if you do your bit to author accessibly and design to meet the standards, the user must come equipped with a browser and any necessary assistive technologies that are smart enough to understand your pages. It is the responsibility of the disabled user or their purchasing agent (eg an employer) to ensure that access technology and techniques purchased and deployed uphold W3C User Agent Accessibility Guidelines and specifications (5.1.3). It is not the responsibility of the website commissioner to ensure that the browser used upholds W3C guidelines and specifications, including UAAG (6.4.4.4). (Not that any browsers I can think of do uphold UAAG …)

Policy and process

All sites should have a public accessibility policy, explaining the level of accessibility supported, who to contact with problems and an honest statement of what is inaccessible along with a reasonable estimate of when the repairs will be made and how disabled people can access this information or these services via alternative means (6.2.4).

The PAS sensibly recognizes that accessibility is a process rather than a product and that continued checking is required but all organizations, regardless of size, should ensure that those testing the website are different from those developing it.

PAS annoyances

It’s an old cliché that a camel is simply a horse designed by a committee, and with a 160+ member committee behind the PAS, there’s going to be a few humps.

It’s pretty repetitive and densely worded, which makes me slightly nervous about whether its target audience of management will be prepared to spend the time to read and absorb it. The structure is odd, with important information scattered around; for example, the section titled “PDF” (7.5.2) does not mention the important advice that it should only be used if it is more appropriate to use it over html, which is found in 4.2.2.2. Would a manager, leafing through the document for advice on pdf note this important caveat?

HTML and XHTML are defined as w3c standards, although (weirdly) there is a note on HTML, that says Note, this is generally used as a development format. What does that mean? HTML is used for prototype, XHTML for final product? Patently inaccurate if that is what it means.

The mentions of JavaScript are somewhat woolly; Any website that relies on scripting languages such as JavaScript should be tested thoroughly (so non-JavaScript sites don’t need thorough testing?).

The public accessibility policy should avoid jargon and be written in clear and appropriate language so people understand its implications (6.2.2), yet (contradicting itself), you should include details of the accessibility level to be upheld, with the jargon-free example ‘conformance to W3C WAI WCAG 1.0 Level AA’ (6.2.4.d).

Impact of PAS

The impact of the PAS is yet unknown, as it’s so new. The prestige of the BSI, the DRC and the authoring steering group gives it an impressive pedigree, but it is – after all – voluntary guidance.

I am unsure about how “publicly available” the PAS actually is, as it is priced at £30 per copy (from http://www.bsi-global.com/ICT/PAS78/).
While I accept that the British Standards Institute need to recoup their costs (and £30 is hardly a great burden for any commercial organization), the paid-for nature means that the text can’t be put up on the Web and openly discussed. Julie Howell was adamant that the document needs the oxygen of publicity and debate if it is to gain momentum; it may be the closed nature of the document that inhibits this.

Nevertheless, I believe it offers some good advice, including practical checklists on how to choose prepackaged software and how to choose a developer. I think it makes an important contribution to the awareness of the need for accessibility here in the UK, and the information contained has practical application anywhere, not just within the United Kingdom.

In a personal bit of egostroking, I was delighted to find two books I wrote (one with Molly Holzschlag) in the recommended reading list!

Ladies and Gentlemen (and Pat Lauke), I commend this document to you, and urge you to brandish it at bosses, colleagues, suppliers and domestic pets.

Also, the fearsome but lovely Joe Clark has a great critique.

---

Added 14 March 06: A poster on the accessify forum suggests I might not be disinterested when recommending the PAS, so to set the record straight, I should point out that I was invited to review the first draft (with a hundred other people) but received no financial reward for it, except for free copy of the document and an invite to the launch conference and disco. The two books it recommends were developed by me and a team of salaried employees of glasshaus, which went bankrupt in 2003; hence I receive no royalties from sales of these books.

This entry was posted on Thursday, March 9th, 2006 at 12:39 pm and is filed under accessibility web standards. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.