Archive for the ‘Web accessibility’ Category

BBC Online: Quite the challenge ahead

Tuesday, July 6th, 2004

The BBC Web presence has been reviewed by an outside consultant, Philip Graf. Press coverage has focused on the sections of BBC Online that will be shut down, and how “external content providers” can add to the site.

Torin Douglas writes: “Amazingly, Philip Graf seems to have pleased everyone with his report into the BBC’s online services.”

Well, except disabled people. The issue of accessibility is barely even mentioned in 290 pages of reports (including the Independent Review of BBC News 24), all of them published as tagged PDFs.

What do the reports say about accessibility?

Let’s check some of the references, taking care to sort out the disability sense of accessibility from others. Glancing references are excluded.

BBC Online Review, Module 1: Assessment of BBC Online’s Use of Technology (PDF)

The overall site design and accessibility of BBC Online has undoubtedly made the service easy to use… A number of features are also in place to help users with visual or certain physical impairments to navigate their way around the site relatively easily. Every page has a “Text only” link which, when clicked, redraws the page, removing all of the graphics and other objects, leaving just the text. This feature uses an application developed by the BBC called Betsie… which also allows the user to change the colour and size of the text, as well as removing embedded items, such as games and applets. All BBC Web pages have also been created so that the font size can be changed in the client’s browser to make reading easier. [...]

To date, there has been only one instance of BBC Online actively contributing to the “open source” community – an accessibility tool called BETSIE was developed by BBC Online to enable text within Web pages to be adapted in size to suit the needs of visually-impaired users.

  1. Text-only pages not only are not accessible, they’re a form of apartheid. The idea that text-only pages – no matter how presented or by what clever tool – are a form of accessibility is entirely wrong. This is quite the red flag to wave before accessibility advocates.
  2. Font properties and colour can be controlled much more finely with stylesheets; you don’t need Betsie.
  3. The ability to remove embedded items is of dubious merit, though I can see some applications. But why not make the embedded items accessible?
  4. Font-size alteration is only a problem using some kinds of px (pixel) sizing and only in Internet Explorer for Windows. Avoiding the problem on a commercial site is so rudimentary it’s not worth mentioning.
Report of the Independent Review of BBC Online (PDF)

[C]entral New Media defines and manages standards in a range of areas which include… [a]ccessibility standards, such as usability for visually-impaired audiences.

Separately, users and non-users of BBC Online ranked “services for specific client groups” like “people with disabilities” as “important” or “very important” about three-quarters of the time.

Under “content issues”:

…the need for accessible and appropriate services for the elderly, the partially sighted and people with learning difficulties. “…It is therefore of prime importance for the BBC to take full account of the issue of accessibility and to consider for themselves whether the information that they provide is truly accessible by everyone who needs it” – Disabled Living Foundation

Service objectives flowing from social purposes: [S]ervices considered to be of social value, but which the commercial market place is not providing and is unlikely to provide [such as] services for users with disabilities (e.g. Ouch!).

Did the authors know of the existing research?

Apparently not.

The BBC is one of the few organizations anywhere whose Web accessibility has been studied through usability testing with actual disabled subjects.

→ Accessibility study of BBCi: Problems faced by users with disabilities (PDF; previous mention)

The report found, in part, that:

  • BBCi was a “medium-compliance site” (but then again, it named Amazon.co.uk as a high-compliance site). Users with all disabilities tested, including deafness, had notable trouble using the site, but total inaccessibility and complete user frustration were rare.
  • Text-only versions were ignored. “None of the participants selected the text-only version of the site, despite the fact that some of our participants (those with partial vision and dyslexia) had used an ‘accessible version’ of sites before…. One reason for not selecting the text-only site may have been because they were unaware of this facility…. Many disabled people express a dislike of separate, text-only sites. There is a concern that the text-only site may be out-of-date compared to the main site and it may exclude certain information…. [S]ome disabled people regard it as disempowering because choices are being made on their behalf that result in less information. A frequently-repeated criticism of text-only sites is the dislike of ‘special’ provision, as it is felt to be stigmatizing.”

The current Graf report disregarded the existing research. It’s no surprise the report pretty much ignored accessibility, and, in a self-incriminating touch, presented text-only sites as a claimed accessibility triumph.

Does the BBC know what it is up against?

As mentioned before, the BBC plans to digitize an untold sea of audio and video material and make it available online (if only to British subjects).

We have, as it stands now, a set of accessibility deficiencies with the BBC’s text-and-graphics sites and its relatively uncommon multimedia. Now add thousands of hours of multimedia. Is everyone aware of the enormity of the task of making the entire experience accessible? Do you have any idea what an undertaking is involved in captioning, audio description, and transcription of such clips, let alone configuring thousands of database-generated pages to serve them correctly?

Has accessibility even been considered?

Surmounting politics

BBC Online, with a reputed two million pages, is not a badly-run Web site. In fact, it is widely admired and even I like it much of the time. They do a lot of things right, and I know for a fact that smart people work there. It’s a pretty solid foundation, really.

Except:

The Graf report was politically motivated. It was only commissioned because of private-sector complaints that the public broadcaster was treading on ground the private sector coveted. The CBC hears the same accusations from time to time.

The response has been equally political, as, for example, in shutting down five BBC Web sites. I fear that the response will continue to be driven by superficial and ignorant misunderstandings of the Web – the sort of thing we suffered through in the dot-com era:

Imagine the scenario of a qualified developer attempting to present a really solidly built Web site to a manager who can barely type. All he (or, rarely, she) knows about the Web is that the brighter and more saturated the colours, and the more blinking and flashing, the better. That is his (or, rarely, her) sole method of evaluation. It’s very high-level if it can be said to have a level at all, and it has nothing to do with how real people, with and without disabilities, use the Web. It also ignores relevant expertise, as from usability, standards-compliance, and accessibility authorities.

If BBC Online really needs to be fixed, do so intelligently. Start with users, including users with disabilities. Do no harm to them. This will require an inclusion of usability and accessibility at the ground level rather than trying to tack it on later. We are dealing with a very large task of technical architecture; it’s necessary to build accessibility into the very fabric of the improved site. Doing so may require jettisoning some ideas attractive to non-experts that can’t be made to work, but on the other hand, it ensures that every idea that does work works for everybody who uses the site.

In other words, if this is the set of problems we’re given, let the experts solve them.

Version history

2004.07.06
Posted.
2004.07.15
Title changed (from “BBC Online: You’re in trouble”) because the latter was actually unrepresentative. Thanks to an esteemed colleague on that sceptred isle for yelling at me, which resulted in my realizing that.

OlympicWatch™

Friday, June 4th, 2004

Time to inaugurate a new feature here on Axxlog, the Media Access Weblog with the Vaguely Risible Name: OlympicWatch™.

Yes, that old fascist Juan Antonio Samaranch has finally been deposed, but how well are things really improving in the International Olympic Committee and the host cities for the various Games?

Seasoned readers will be aware that I refer to the now-notorious case of Maguire vs. SOCOG, in which a single blind person filed a discrimination complaint against the Sydney Organizing Committee for the Olympic Games – and won. His beef? The SOCOG Web site wasn’t accessible to him as a screen-reader (also Braille-display) user.

I am not unproud of my coverage of this case, which remains definitive four years later:

Right. Now let’s start with some news. Marco Battilana pigeonholed the CEO of the Vancouver Games committee concerning Web accessibility.

Mr. Furlong assured me that the Web site will certainly lead an example to the rest of the world. That once a team is in place to look after the related tasks, that certain guidelines will be followed. The site that you see right now will definitely change as the Olympics draw near.

The one actual quote from Mr. Furlong that had the most impact for me was “Never good enough.” Mr. Furlong assured me that this is the motto to be followed. That whatever is being built is continuously improved upon every step of the way…. When I can see that there has been some advancement on the accessibility of its design, I’ll have the satisfaction of knowing that maybe, just maybe, I made a bit of a difference.

I will be phoning around for official comments on plans for accessibility at the official Olympic site and at the Athens Games site. Managers of both those sites, and all their contractors, have had rather a long time to get their acts together. What’s gonna happen this year, I wonder?

Well, to start off, it seems that the Athens developers have drunk at least some of the erythropoietin Kool-Aid®, since their homepage actually validates. So did all but one page I dug through there. Welcome to the 21st century, Athens!

A few items on Web accessibility

Friday, May 28th, 2004

Busy week or two.

  1. French-language sites in Quebec (“and Canada”) flunk accessibility specs. What a surprise!

  2. 89% of 408 California municipal Web sites surveyed flunked Priority 1 (in automated testing). 75 were manually tested, also with poor results, though the report goes into no detail at all on that point. (In fact, it’s only mentioned on the blog [other entry].) And the actual report is, of course, in a PDF (tagged, with three minor access errors).

  3. Why the ‘statistics defence’ doesn’t stand up:

    The case against accommodating Netscape 4 users is invariably backed up with statistics about how few people now use this admittedly-flawed browser. I’ve heard “the statistics defence”… so often over the years that this latest evocation prompted me to think about why I don’t agree with this approach. [...]

    We can’t argue that we won’t accommodate disabled students because they only make up a small percentage of the student population. Equally we shouldn’t argue that we won’t accommodate users with particular browsers because they are part of a minority. In relation to the particular case of Netscape 4, it is legitimate to ask users to upgrade so that they get both the content and the good design – but not legitimate to argue that they won’t get the content if they don’t upgrade.

    This is a non-starter, really. Disabled people can’t stop being disabled (save for rare cases); anyone using Netscape 4 can upgrade. That browser is hideously broken and outdated and is a thing; we can shun it if we want. We can’t do that to people.

    Besides, any competent standards-compliant designer knows you can use @import to hide stylesheets from Netscape 4 so that a page works adequately in that cœlecanth of a browser and very well elsewhere.

  4. MC May Techno Dance Remix:

    Netscape 2.0 introduced both frames, added in HTML 4.0, and JavaScript, which for the first time allowed client-side forms validation, and later meant the death of us all. CSS, introduced in Internet Explorer 3 and refined over the next seven years, allowed pixel-level control over the display, causing unreadable documents to become the norm, and further blurring the line between Web page and application.

  5. A few surprising facts from an accessibility presentation (edited):

    Users who listen

    1. 2 hours each, typical usability testing scenarios,
    2. Took about twice as long as usual usability tests, which seems typical

    Skipping the navigation

    1. All wanted to skip the navigation
    2. Discovered that they often did not know how to do that with their software
    3. Two jumped to the bottom and read from bottom to top
    4. All sites had a skip navigation link
    5. Most did not know about the link
      1. “skip navigation” is jargon
      2. “skip to content” Jaws mispronounces
      3. “skip to main content” seems best

    Listening only to links

    1. Everybody knew how to listen to links
    2. Jaws can bring up a window with just the links
    3. Example: Looking for “diabetes” when the word “diabetes” is in a sublist of “Diseases and Conditions”
    4. One problem is many blind are poor spellers because they have little practice
    5. Screen readers also pronounce words even if they are incorrectly spelled
    6. Can set Jaws to spell the letters out as you enter them

    Content for users who listen

    1. Do not understand words when the software mispronounces words with more than one pronunciation – content
    2. Web words – homepage
    3. Unususal words – preparedness
    4. Made up words – MedlinePlus, LiveHelp
    5. Acronyms – FY (fiscal year) pronounced “fi”
    6. Get confused if the alt [text] and the words on the page differ
    7. What it said on page was “print answer” but alt [text] on printer graphic said “Printer friendly version”. When wanted to find that location searched for “Printer” which was not found (not in text)

    About forms

    1. Can’t find form if it’s buried on the page or way on the right
    2. Jaws has a command to go to the form, but nobody knew it existed
    3. Do not know there is a form on the page until you encounter it
    4. Users want to stay in Edit mode so you can tab from field to field
    5. Can’t use the form if the field labels aren’t “well behaved”
    6. Need to move from hearing mode to entry mode and back again
    7. Many users had mode problems, hard to do

    We are doing it backwards

    1. Hard to provide guidelines for people who magnify
    2. Today, assistive technologies go on last, on top of regular sites
    3. First build site for most people
    4. Then fix so site works with “special software”
    5. Reverse it
    6. Flexibility
      1. Let people set up personal profiles
      2. One column is very helpful for some people
      3. Some people can handle dense information,
      4. others go into cognitive overload
      5. Wheelchairs are composed of components
      6. Can swap in different components as your body and needs change

WAI self-examination

Tuesday, May 4th, 2004

I was surprised and delighted to read last week that the Web Accessibility Initiative commissioned a usability study of its Web site. Done pro bono by the American Institutes for Research, the study demonstrated what we knew already – and then some.

It was commendable for WAI, which is behind the times in Web development in so many other ways, to use state-of-the-art evaluation methods to assess its site. As I’ve argued for ages, WAI will not be taken seriously by designers until WAI takes design seriously.

We can now dare to dream of a future in which the WAI portion of the W3C site actually looks professionally designed, with proper information architecture, multiple selectable styles available, and full WCAG compliance. (Curiously, the WAI site itself only claims to comply with Priority 2. It seems impossible for an entire site to comply with Priority 3 if the authors of the spec cannot do it.)

The AIR study isn’t available in a convenient single page yet, though I assembled a single HTML file and single PDF (at a svelte 98 pages) if anyone needs something to print.

Highlights

Participants

[W]e recruited a total of eight persons involved in Web development to serve as usability evaluation participants. One of the participants was a Web development professional who is blind. That participant kindly brought a personal laptop to our lab space in order to facilitate exploration of the WAI site using a Jaws setup customized to her needs. Another participant had a hearing disability. In addition, one of our participants self-reported as colourblind.

Tasks

Subjects were asked to carry out a selection of plausible tasks that was quite well-considered. Some included:

  • Your team at work is developing a Web site and you have some concerns about how accessible the Web site might be to people with disabilities. Using this Web site, determine whether or not it contains information about the basic things Web developers need to know about Web accessibility.

  • A few of your colleagues are interested in finding out how to be a part of WAI’s effort to develop guidelines for Web accessibility. Using this Web site, determine whether or not opportunities exist for becoming involved in WAI Web Content guideline development.

  • You have just been handed a report, generated by a Web accessibility evaluation tool, which informs you that your company Web site contains complex information graphs that do not meet “Checkpoint 1.1.” Using this Web site determine how you would meet Checkpoint 1.1 and make the graphs accessible.

  • Your company is revising the online forms on its Web site. Find specific information on how to make the online forms accessible.

Task success

It’s hard to fare worse than this: “Participants were largely unable to complete these tasks. With the exception of the WAI mission task, no more than five of eight participants were able to complete any task without assistance from the test administrator.”

Too much information

A common complaint (even voiced on Slashdot) holds that there’s just too dang much to read on WAI pages. It’s true.

Perhaps the most significant finding of the WAI Web site usability test was the observation that the Web site users consistently stated that they were overwhelmed by the information available to them.

They stated that the WAI developers “had not parsed” the information for users, hadn’t provided adequate “information and technique summaries” and asserted that using the WAI Web site was like “walking into a firehose.” They repeatedly suggested that the information they were receiving could be “summarized” into “manageable chunks” for easy, or quick use.

Participants uniformly stated that the WAI Web site information that was most relevant to their work was always “hidden.” They described the process of using “a W3C site” as: “you go to the page, scroll down, scroll down, scroll down, about four or five screens, past all the useless stuff, and then you get to the good stuff. Which is great. But it’s always in the middle part of a really, really, really long page.” [...]

They uniformly suggested that the WAI development team consider ways to parse the Web site’s information rather than giving it to them “all at once.”

Graphic design

Participants were asked to rate various factors on a scale of 1 (“Disagree strongly”) to 7 (“Agree strongly”). Graphic design fared poorly:

  • “The homepage is attractive”: 4.0
  • “The overall site is attractive”: 3.4
  • “The site’s graphics are pleasing”: 3.3
  • “The site has a good balance of graphics vs. text”: 3.2
  • “The colours used throughout the site are attractive”: 4.6
  • “The typography is attractive” [!]: 5.6
Complaints to address

The study quotes some free-form complaints by participants. My suggestion to WAI is to work to counter every single one of these, plus each of the later comments and “words or characteristics” participants used to describe the site.

  • There should be a category for myths about accessibility so designers know they don’t have to sacrifice style.
  • There should be examples of pages that are accessible.
  • It would contain a set of guidelines for developing Web sites. It should have test tools, information about troubleshooting….
  • There should be hot topics to be aware of, industry specific issues. It should provide recommendations or experiences other people have.

A great place to start

WAI still has a desperate need for participants. There’s too much work for too few people, and some of us simply aren’t experts in important areas.

Still, the AIR study amounts to a galvanized, wheelchair-accessible nail in the coffin of WAI’s history of being ignored by professional developers. WAI now has a full catalogue of documented issues it can fix, along with ways to do the fixing. Based, in addition, on further information I have, I expect that the WAI site at the time of release of the Web Content Accessibility Guidelines 2.0 will be a total shock to anyone used to trudging through what we’re stuck with now.

As they say in the Maritimes, good on yez. Now don’t blow it!