WebAIM recently conducted a survey of preferences of screen reader users. With over 1100 responses, the results of this survey provide much useful information about screen reader user demographics and preferences. Some of the results were quite surprising. This comprehensive survey of screen reader user preferences provides much needed insight into this diverse group of screen reader users.

Here are a few findings:

• The most common screen readers used are JAWS (74%), Window-Eyes (23%), NVDA (8%), and VoiceOver (6%).
• 75% of screen reader users upgrade to the newest version within one year.
• 12% of respondents use a screen reader on a mobile phone.
• 76% of users always or often navigating by headings.
• 36% never or seldom use text-only versions of web pages.
• 72% of screen reader users reported that Flash is very or somewhat difficult.

There is much, much more to be learned about this diverse group of screen reader users at the survey results page.

It’s great to see some actual data and feedback from real screenreader users, instead of always hearing anecdotal evidence and generalised assumptions from designers and developers. As the disclaimer notes, the actual user sample was not controlled, some of the questions may have been too technical, and some responses may have been tainted by previous experiences with badly-coded and inaccessible sites.

Perhaps the most significant conclusion we can make from these survey results is that there is no typical screen reader user.

One thing I’d like to see in any future survey would be actual testcases that respondents are asked to evaluate, which may give more representative results. In the meantime though I’d like to thank the WebAIM team for their effort and look forward to the more in-depth analysis of the data gathered from this survey.

Polish Translation

I think this tweet by caledoniaman sums up the level of anticipation:

WCAG 2.0 and a new Guns ‘n’ Roses album in the same year. What’s the world coming to.

Interesting comparison. They’ve each had about as many pre-releases. In any case, I can say, having spent over 8 years with it, that WCAG 2 is not as entertaining as Chinese Democracy. But I do think that it’s better equipped to stand the test of time.

If I had to pick one thing I’m most happy about, I’d say it’s that the HTML- and text-centrism in WCAG 1 is largely gone. In its place is a much more flexible (dare I say robust?) concept of accessibility-supported technology. So when newer technologies can show themselves to be directly accessible, they too can be used in WCAG 2-conformant content.

Over the years, many people have conflated “WCAG-conformant” with “accessible,” and that’s led to people making statements like: “Don’t use JavaScript–it’s inaccessible.” That’s bad for everyone, from users with disabilities who actually can work with JavaScript (which is to say, the vast majority), to Web designers and developers, to policymakers, to those developing new technologies.

With WCAG 2, “Don’t use x” is no longer valid. (Was it ever?) It is now up to you, the developer, to work on the direct accessibility of your content, no matter what technology you choose. I believe we’re about to experience a new wave of accessible design techniques, as a result.

But first, we need to flush “Don’t use x” out of our system. Some are accustomed to saying it about anything they’re not comfortable with. That’s only holding accessible design back. It’s time to learn what’s out there, today, and use it in everyday Web design. It’s time to make everyone’s Web more accessible. Have a look at the WCAG 2.0 Recommendation, and its supporting material. Then, start thinking about what a more accessible Web could be. We still have a lot of work to do.

BSI British Standards is inviting all interested parties, and in particular marketing professionals and disabled web users, to review and comment on the draft of a new standard on accessible web content. DPC BS 8878 Web accessibility – Building accessible experiences for disabled people – Code of Practice is applicable to all public and private organizations wishing to offer accessible, usable web content to their customers. [...]

Based on PAS 78: 2006, Guide to good practice in commissioning accessible websites, DPC BS 8878 informs organizations of their legal responsibilities in relation to web accessibility, calling on them to appoint a specific person or department to oversee activity. [...]

Julie Howell, Chair of the committee responsible for drafting DPC BS 8878, commented, “Once published, this standard will be a fantastic tool for organizations wishing to understand their responsibilities in enabling disabled people to use web content. DPC BS 8878 encourages the enhancement of the overall user experience – a much more holistic approach than we have seen previously and one that I hope will yield exciting results. Right now we want to encourage as many people as possible to read and comment on the draft standard to ensure it is as relevant as possible.”

Read the full media release: BSI British Standards invites comments on new draft standard on accessible web content.

WaSP Accessibility Task Force co-leads Bruce Lawson (Opera Software) and Patrick H. Lauke (University of Salford) — who have been jointly representing their employing organisations and the Web Standards Project itself on the committee responsible for drafting the standard on behalf of BSI — would like to encourage feedback on DPC BS 8878 through the BSI British Standards Draft Review system.

Deadline for review is the 31 January 2009. Publication of BS 8878 is expected in summer 2009.

Update

The draft is now also available for download in PDF and Word format.

See also:

• Out-law.com: BSI consults on first British Standard for accessible websites

Though you may not have heard of the Accessibility Institute, you have been influenced by its work. Its late founder, Dr. John Slatin, was the former co-chair of the Web Content Accessibility Guidelines 2.0 (WCAG2), and was an influential mentor to many of the web standards evangelists, including myself and current WaSP group manager, Glenda Sims. If you’ve ever attended SXSW, you know Austin has one of the most vibrant web accessibility communities in the world, thanks to the hard work of Knowbility and the University of Texas Accessibility Institute. The knowledge shared by these groups has influenced web and software developers worldwide, resulting in a more accessible web used and enjoyed by all of us, disabled or not.

The importance of accessibility research and development was echoed this week by retailer Target’s decision to settle its web accessibility discrimination lawsuit by the National Federation of the Blind (NFB). The story was covered in many US and international news outlets, and the the outcome of the case is a timely wake up call to the business world that good design is accessible, universal design.

The Accessibility Institute’s influence for the greater good cannot be overstated. The decision to close it on the eve of the universal design revolution is a poor choice by the UT Administration. If you agree, please sign the petition to keep accessibility research and development alive and well.

http://www.petitionspot.com/petitions/SavetheInstitute

Update: This post has been translated into Polish.

Does the Americans with Disabilities Act apply to the web?

Sadly, accessibility’s ultimate cliffhanger once again reaches an awkward denouement, leaving us deflated, and looking at yet another boring sequel. The National Federation of the Blind v. Target lawsuit, which promised to be a landmark case in determining the applicability of the ADA, was settled on Wednesday. The key provisions of the settlement have Target paying $6 million in damages to the members of the class action (which consists of legally blind people who have been denied Target’s online services), and agreeing to remove accessibility barriers to blind users by February of 2009.

As with most settlements, however, Target admits no wrongdoing, and so the ADA’s applicability to the web remains fuzzy. (Especially to a non-lawyer such as myself; please don’t consider this as anything like legal advice.) The legal ramifications of this case may not be as clear-cut as some of us would have liked, but it’d be hard to argue that after this decision people with disabilities are in any way on shakier legal ground.

One twist in this case was the application of two California laws: the Disabled Persons Act and the Unruh Civil Rights Act. Both of these offer protections over and above those of the ADA, for California citizens, such as the named plaintiff, Bruce Sexton. Even if we ignore the ADA for a moment, this means that sites who do business in California could be liable under these laws for denying access.

Whatever the legal ramifications may be, those of us who advocate accessibility don’t want to make this into a series of legal battles. There are no winners there. (Okay, besides the lawyers.) We want people to realize that engaging with people with disabilities well before the threat of legal action arises is always the best approach. When a company stalls and takes a case to court, delays, public relations nightmares, and skyrocketing costs are all that happens. In this case, Target will pay out well over $6 million in damages, when one-tenth–maybe even a hundredth–of that amount could have paid a dream team of accessibility-savvy designers ready to solve the actual issues at hand.

The question that’s on our minds today–whether ADA applies or not–ultimately doesn’t make much difference. In fact, it’s a major distraction from the heart of the matter. People of all kinds want to participate in all the activities the web has to offer. And many disability advocacy groups are reaching out to site admins to raise awareness of the barriers they face. The best thing you can do is to prepare yourself and your site with a little education and some fine tuning. When you’re in a lawyer’s office talking about the ADA, or any other accessibility statute, chances are you’ve already missed out on the most important part of the conversation. And that’s going to cost you, whether you win or lose.

Update: This post has been translated into Polish.

Two years ago, the BSI was sponsored by the Disability Rights Commission to write a Publicly Available Specification (PAS) called PAS 78: Guide to Commissioning Accessible Websites. Publicly Available Specifications are written quickly and “expire” after two years, but because of the popularity of PAS 78, the BSI have decided to update it to become a full British Standard.

We’ve just started work on the draft, which doesn’t yet have a title, although our working title is “encouraging the development of fantastic user experiences for disabled people online”.

Consequently, it’s too early to say what will be in BS8878, which will be released next spring. I can say that it will not tread on the toes of whichever version of WCAG is live then, as it’s a document to help site owners rather than developers. Like PAS 78, it will encourage adherence to current web standards.

Neither can I say who else is on the committee, except that it’s chaired by Julie Howell, and there are representatives from all over industry—broadcasting, banking, legal, education and (crucially) representatives of disability groups, including groups working with those with cognitive disabilities.

Patrick and I gratefully acknowledge our employers, Opera Software and the University of Salford, who are supporting us by paying our travel expenses and giving us time off to attend meetings and write the drafts. They have nothing material to gain by supporting us, and are exercising no editorial control, but are helping to make disabled people’s experiences of the web better.

As a procedural footnote, now that Derek Featherstone has moved role within WaSP to be Group Lead, I’m working with Patrick to be co-lead of the Accessiblity Task Force. Our main projects will be the British Standard, continuing to work with the microformats community testing various date-time patterns with screenreaders, and monitoring the developments in HTML5.

It’s not finalised, as the consultation doesn’t end until November 13 (my birthday, by the way …) but in its current state it’s not a bad document; it rehashes PAS 78, recognises that the only way to find out if a website is accessible is to test it and it says that the minimum acceptable level of accessibility is Level-AA of WCAG 1.0—so valid, semantic code becomes mandatory:

The minimum level of accessibility for all Government websites is Level Double-A of the W3C guidelines. Any new site approved by the Cabinet Sub-Committee on Public Engagement and the Delivery of Service must conform to these guidelines from the point of publication.

Continuing standalone sites must achieve this level of accessibility by December 2008. Websites which fail to meet the mandated level of conformance shall be subject to the withdrawal process for .gov.uk domain names…

If these requirements are ever policed (and there’s no guarantee; UK government websites have a sorry track-record), there are huge ramifications for their suppliers. For example, those who manufacture Content Management Systems will be required to ensure that their products produce valid, semantic code and comply with authoring tool accessibility guidelines (ATAG) so that members of staff with disabilities can publish with them:

In order to build an accessible website, authoring tools must produce content that upholds web content accessibility standards. This is especially important if the organisation will be using a Content Management System (CMS) to produce content automatically. This must be taken into account during the procurement of authoring tools and CMS.

So that content authoring is possible for people with the widest range of abilities, it is also important that the interface to the content authoring tools or CMS is also accessible. Accessibility criteria must therefore be specified in the choice and procurement of these systems, in the same way that accessibility is taken into account when commissioning websites.

I confess that I’m rather sceptical that this will see a dramatic change in governmental websites, but it does give an indication that the more clued-up people in the UK government understand that grudging compliance with WCAG 1.0 level A does not constitute “accessibility”.

It should also cause a few discussions within vendor organisations. Microsoft have been commendably open in a discussion about Sharepoint 2007, acknowledging that it won’t be WCAG level A or ATAG-compliant out of the box until the next release in 2009 or 2010.

How many other CMS vendors can really claim to be ATAG-compliant or produce valid code without significant customisation?

(This article translated into Polish by Sebastian Snopek.)

WCAG 2.0 went through several Public Working Drafts in recent years, and a Last Call Working Draft in 2006. Each Working Draft was sent out for public review — altogether to hundreds of individuals, organizations, and lists around the world where people had expressed interest. You’ll see the results of these comments in an updated Public Working Draft in the next month.

It’s been over a year since the request for review on the Last Call Working Draft of WCAG 2.0 (April 2006) originally went out. Many readers will remember the general level of dissatisfaction, or just plain bewilderment, that it provoked. So, has the latest version — Public Working Draft of WCAG 2.0 (May 2007) — taken on board the comments and criticisms that were raised?

Note: this article only looks at the differences between the previous and the current working draft of the guidelines. It is not meant as an introduction to WCAG 2.0, nor as an analysis of how it differs from WCAG 1.0.

Process, structure and language

In a very welcome move towards clarity and transparency of process, the WCAG working group has published its Summary of Issues, Revisions, and Rationales for Changes to WCAG 2.0 2006 Last Call Draft. This is an excellent starting point for evaluating how work on the guidelines has progressed over the last year, and most importantly why certain decisions, which are reflected in the latest version, were taken.

It’s worth noting first of all that the working group seems to have realised that there’s still work to be done on these guidelines, and has therefore “demoted” them from “Last Call Working Draft” to just “Working Draft”.

It’s clear that the guidelines have undergone quite a bit of reorganisation and editing. Many elements that were present in the previous version have been removed or split out to separate documents. The internal structure of the document has also been streamlined — all the conformance information has now been moved to the end of the document, meaning that readers get to the actual guidelines and success criteria much quicker.

Purely from a layout point of view, the guidelines and success criteria themselves are far easier to skim read. Each SC is denoted by a short term or sentence that signals what it applies to (for instance Use of Color). Though, at their core, most guidelines and success criteria remain unchanged, their wording has been revised to make them more immediately understandable, aided in no small part by the fact that all the bizarre new terminology of the previous document (Web Unit, Authored Unit, Authored Component, etc) has been removed in favour of clear, simple, and commonly used words.

Baselines

One of the big points of contention of WCAG 2.0 was the newly introduced concept of baselines. Although the intention behind the concept certainly had a lot of merit, many reviewers felt that it was ripe for abuse by developers and site owners. The latest draft ditches baselines, but reformulates the underlying idea in terms of choosing technologies that are accessibility supported. Rather than saying “users must have user agents and assistive technology that can deal with these technologies we’ve chosen”, the onus is now more explicitly on developers to ensure that the technologies they’ve chosen are in fact known to be supported. The concept is the same, but it’s been turned around far more explicitly in favour of the users, and it’s far less likely to be misinterpreted (maliciously or not) by developers.

Cognitive disabilities

The previous version came under criticisism for failing to adequately address the needs of users with cognitive and learning difficulties. Although the situation still isn’t much better in the new version, this is at least aknowledged in the introduction.

Although some of the accessibility issues of people with cognitive, language, and learning disabilities are addressed by WCAG 2.0, either directly or through assistive technologies, the WCAG 2.0 guidelines do not address many areas of need for people with these disabilities. There is a need for more research and development in this important area.

The introduction is also quite realistic in stating that:

These guidelines [...] are not able to address the needs of all people with disabilities.

Levels and conformance

A holdover from WCAG 1.0, the new version finally does away with the unnecessary dual system for categorising conformance levels (A, AA, AAA) and individual success criteria levels (1, 2, 3), adopting the former for SCs as well. The definitions for these three conformance levels have also been rewritten and expanded. Rather than simply stating that one level achieves a minimum level of accessibility while another results in an enhanced level of accessibility, as was the case in the previous version, these definitions now focus on the impact that a certain level has on end users. The definitions further aknowledge that conformance with a certain level may require certain aspects of a web page’s visual presentation and content to be changed or adapted.

In a note on conformance, the previous version stated that:

Because not all level 3 success criteria can be used with all types of content, Triple-A conformance only requires conformance to a portion of level 3 success criteria.

The new version reverts back to the original WCAG 1.0 model, requiring all AAA success criteria to be fulfilled in order to claim conformance to that particular level. However, it concedes that the AAA criteria place tighter limits on both presentation and content, which means that some types of content may not be able to satisfy this level of conformance (emphasis added).

The guidelines still attempt to make the point that, despite the use of the word levels, there is no implication about the relative importance of success criteria. However, this passage from Gez Lemon’s article WCAG 2: The difference between a level and a priority (posted in January last year, in reference to the pre-Last Call version) still rings true:

For any given level, all success criteria for that level, and the success criteria for all levels below, must be met before a conformance claim can be made. Therefore, each level is inferred a level of importance; otherwise, they would all be considered equally important, and ranked only as to whether or not they can reasonably be applied to all web resources.

It may be that the only way around this conundrum is for the guidelines to accept that, by their very nature, levels imply a hierarchy, and that in most cases authors will focus on fixing any major bloopers (failures of level A success criteria) first, as they are more important in order to make a site more accessible to a potentially larger percentage of visitors, before going on to the higher levels (particularly if, by admission of the guidelines themselves, these levels may actually have an impact on the overall design of a web page).

Scoping

Still on the subject of conformance, the explicit section on the Scoping of conformance claims — with its ill advised example A site has a collection of videos for which it is not required to and does not want to claim accessibility which seemed in direct contradiction to the preceding line Scoping cannot exclude a particular type of content (for example, images or scripts) since it would allow exclusion of individual success criteria — has disappeared. There are still references to a site’s ability to specify which URIs a conformance claim applies to (and, by inference, which URIs are effectively out of scope) and the possibility of excluding certain web pages or sections with a Statement of partial conformance, particularly when dealing with user contributed content and aggregation. The loophole is still there, but it’s not served on a silver platter to the casual reader.

Accessible alternatives

Speaking of loopholes, Guideline 4.2 – Ensure that content is accessible or provide an accessible alternative is gone from the latest version. Nonetheless, the concept of alternative versions is still found in the Conformance Requirements section. As with the previous point, it’s an improvement not to have an explicit guideline that sanctions a perceived “easy way out”, as was the case in WCAG 1.0 — although, in fairness, even then checkpoint 11.4 clearly stated If, after best efforts, you cannot create an accessible page, provide a link to an alternative page (emphasis added). The editorial note in WCAG 2.0 relating to this part of the Conformance Requirements does explicitly elicit further suggestions and comments on the whole alternative content issue, as the working group recognises that, in its current form, it may not be ideal.

Validity

One final point to note is that, despite much uproar about this in the previous version, validity (the requirement to create web pages that, to use WCAG 1.0 parlance, validate to published formal grammars) is still out. Reading the summary of changes, the rationale for this move is explained as follows:

The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification.

[...]

The working group must work within its charter and only include things that directly affected accessibility. Some aspects of use technologies according to specification and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter.

Although the working group cannot require validity, it recommends it and it is our #1 sufficient technique listed for conforming to SC 4.1.1.

There is no doubt that the final decision was, at least in part, politically motivated (and pushed through) by certain influential members of the working group. Personally, I would have loved to see validity enshrined in the normative guidelines, rather than just in the informative techniques documentation … yet the pragmatist in me aknowledges that the guideline isn’t all that bad, requiring well-formedness and adherence to a language’s general syntax rules — albeit in a very clumsy fashion, by way of elements with complete start and end tags and nested according to their specifications. The wording is certainly an improvement over the vague requirements for Web units or authored components to be parsed unambiguously.

Summary

There are many more aspects of the guidelines that have changed since last year’s version — I’d strongly recommend that interested readers go through the summary of changes and compare the last two versions of the guidelines side by side. Overall, things may still not be perfect, but this latest draft can, without a dobut, be seen as a marked improvement. Though it will still be a while before we see WCAG 2.0 become a stable and official W3C Recommendation, the signs are good that it’s on course and heading in the right direction. Have a look for yourself, and make sure you send your comments and suggestions on the current version of WCAG 2.0 to the working group by 29 June 2007.

Addendum on techniques and community involvement

This short article only concentrates on the core guidelines document itself, as this is the only normative document in the WCAG 2.0 suite. Once developers get down to implementing the new guidelines, they’ll mostly be referring to the Techniques for WCAG 2.0 (by way of the WCAG 2.0 Quick Reference) … and those are admittedly in a less than optimal state at present. We’ll be posting more on this soon, but it’s worth reiterating that the techniques are only informative. The intention of WAI is to update these regularly (around once a year) to reflect current best practices, based on material submitted by the developer community — a process that WaSP, working closely with the WCAG WG, will be actively involved in.

Further reading

• Web Content Accessibility Guidelines 2.0 – W3C Working Draft 17 May 2007
• Summary of Issues, Revisions, and Rationales for Changes to WCAG 2.0 2006 Last Call Draft
• Mike Davies, May 2007 WCAG 2.0 draft
• Jack Pickard, WCAG 2.0: Woeful to Wonderful in One Easy Draft?
• In German: Einfach für Alle, accessCast – Neuer Entwurf der WCAG 2.0
• Henny Swan (RNIB), WCAG 2.0 – where to start?

Documents and articles relating to the previous version of the guidelines:

• Web Content Accessibility Guidelines 2.0 – W3C Working Draft 27 April 2006
• Lisa Seeman, Formal Objection to WCAG 2.0
• Joe Clark, To Hell with WCAG 2
• Bruce Lawson, WCAG 2.0: when I want a beer, don’t give me shandy
• Jack Pickard, The WCAG 2.0: What a Whopper
• Derek Featherstone, What to do with WCAG 2?

Her chapter in Friends of Ed’s Web Accessibility: Web Standards and Regulatory Compliance, Understanding Web Accessibility is an excellent practical introduction into the barriers disabled people face when using the web. One point in particular stood out for me: Allowing text to increase in size is not enough, sometimes content can be more accessible when text size is allowed to be reduced. Take for example a person suffering with tunnel vision, the range of view is limited, so a smaller font-size allows more content into their field of vision.

The RNIB Web Access Team are hosting Shawn’s accessibility talk which covers recent developments, current issues, tools, web applications, ARIA, and the WCAG-complementary guidelines ATAG and UAAG.

The talk is on Tuesday 5th June 2007, at the New Cavendish Street campus of Westminster University, London, UK. The nearest tube station is Goodge Street. Starts at 7pm. Book your place now! (hat-tip: Stuart Colville)

His vision-impairment is caused by a lack of muscle control due to cerebral palsy, effectively making him vision-, mobility-, and dexterity-impaired. The mention of the screen reader is a minor note in the story but I note it here because, people (including many professional web designers and developers) too often assume accessibility is only about blindness.

Sumner Spence has cerebral palsy, but this evening he is set to get his degree and will address fellow graduates at the University of Delaware in Rehoboth Beach… (source, including audio archive)

Although the story doesn’t mention which screen reader he uses, it is a testament to the importance of work done by all assistive technology vendors. Thanks guys, you know who you are. Keep up the good work.