Axxlog

The better part of a year in the making, and created in conjunction with the TILE project, I’ve written 21 chapters on the topic of best practices in online captioning.

Among many other things, you’ll find:

• A list of every known method of using embed and/or object with valid code
• Illustrated examples
• And a host of guidelines on how to handle exceptional cases (how do you caption a videoclip that’s also audio-described?)

These files have been ready for a while, but there was some question as to their ultimate home. I have decided to cut bait rather than fish and am posting them myself.

Last week, I enjoyed the superexclusive megaprivilege of teaching blind kids HTML. Yes!

My esteemed colleague Bryce Johnson, whose company has done some development work for the CNIB, canvassed for volunteers to teach advanced HTML to a group of 19 teens attending the SCORE camp. And by gar, I was the only one who volunteered (and could make it).

Bryce and I underwent mild cardiac arrest at the existing lesson plan, which teaches the kids 1997-era tag-soup HTML. Since I know Bryce from my Webstandards.TO social club, which, to this day, has no real Web site, clearly we weren’t about to teach the kids font and bgcolor.

CNIB staff were politely annoyed when we announced early on that we’d be teaching correct methods – and deprogramming the kids of every other method. The class, which included two youths each from Trinidad and Australia, were totally flummoxed when we informed them that, yes indeed, every HTML document starts with html, then a head that includes a title, and then, after you close those two, only then do you get to put everything you want people to read inside body. And when you’re done you have to close body and html.

The truth hurts, babies! We gotta teach youse the correct code if you want to make accessible pages. But after the first ten minutes, the kids all caught on. We enjoyed two two-hour sessions, teaching the kids only one new HTML concept ([un]ordered lists) and getting their feet wet with CSS.

Curious factoids

1. We had the full range of visual impairment, from none to total.
2. Two kids with guide dogs (one of them a senior from a previous camp). It was great watching the low-vision kids with canes guide the blind kids!
3. Experience was not an indicator of HTML success. Some of the total newbies caught on immediately. One lad had taken HTML before and forgotten it. (Then again, he complained he had to telnet into his Linux box from his Windows box because the former didn’t have enough power to compile speech output, and he had a whole stack of vintage computers that I insisted he safeguard at any cost.)
4. There was no difference in aptitude between girls and boys, which is what you expect when you provide equal opportunity.
5. When exploring CSS, it was the totally-blind kids who insisted on learning how to make words in different colours. Only one of the low-vision kids seemed to care.

Unexpected factoids

Chat works just fine in screen readers

We keep being told, over and over again, that chat programs are inaccessible to screen-reader users because they cannot control the unpredictable flow of text. (In fairness, researchers tend to consider all kinds of chat when they make that assumption, not just instant-messenger programs.)

Well, that’s crapola. MSN Messenger (used by all the kids and one of the instructors!) works perfectly with Jaws. (So, apparently, does AIM.)

In fact, we had to tell the kids “Log out of messenger!” before every instructional segment. And the minute our backs were turned, the kids suddenly transformed from plodding hunt-and-peck HTML coders to rat-a-tat-tat touch-typists. Whatever could they be doing?

Image-editing programs have to be accessible

I have assumed, but not been able to prove, that digicams are a great invention for visually-impaired people because they can go around taking photo after photo (kaching-kaching-kaching), then look at the pictures nice and big on computer. (We’re aware of blind photographers using film, but the cost of mistakes is somewhat high there, don’t you think? And tiny printed photos aren’t much good.) Since low-vision people are taking pictures, the software they use to edit the photos has to be accessible. Right?

Definitely. This isn’t theoretical anymore. We had at least three kids in camp who brandished digicams and used spare moments (when not busy with messenger?) fiddling with photos.

In fact, one of the teens and I engaged in mutual digicamatio. (The photo he took of me on my camera is terrible. SUPPRESSED.)

Looking forward to next year. We’ll have a better lesson plan, and, hopefully, so will CNIB.

Boy, it’s been a while since I did one of these. A couple of research papers on Web accessibility and one on audio description:

“Comparing Website accessibility evaluation methods and learnings from usability evaluation methods” from Peak Usability (195 K PDF)

Tania Lang’s paper states: “The aim of this paper was to determine the most effective accessibility evaluation method to determine Web accessibility and concludes that a fully integrated approach (combining automated and manual evaluation and accessibility testing) is… best.”

The paper states that accessibility and usability evaluations share such measures as:

• number and severity of problems
• task completion (yes/no)
• user satisfaction
• duration

Lang makes note of the following (excerpted):

• Whilst there are relatively few papers comparing accessibility evaluation methods, there are numerous papers discussing usability evaluation methods (UEMs). There are many similarities between UEMs and AEMs. For instance, accessibility testing with users generally appear to use similar measures as those used in usability testing such as task completion, satisfaction and efficiency (although user satisfaction is often excluded as a measure in accessibility testing).
• [A]ccessibility evaluation methods often limit measures to efficiency and effectiveness whereas usability testing usually also includes a measure of user satisfaction (as highlighted in Table 1). The workshop consensus was that accessibility testing should measure efficiency, effectiveness and user satisfaction – the same measures typically used in usability evaluations.
• May be difficult to determine if issues are accessibility issues or usability issues applicable to all users – need to test with people with no disabilities first to establish a baseline…. Generally if an issue is only experienced by users with a disability, it can be categorised as an accessibility issue.

And by far the best part (also excerpted):

• Colwell and Petrie… conducted an experimentwith 12 students who were learning HTML. Students were asked to adapt an existing Web page making it accessible by following the WCAG 1.0. Results suggested that several improvements could be made to the WCAG 1.0…: “their structure and tone; navigation within and between the documents; the content and presentation of examples; and additional information to be provided.” [...]
• Of perhaps greater significance was a second experiment conducted by Colwell and Petrie… which involved accessibility testing of the pages developed by students using WCAG 1.0. 20 visually impaired participants used a wide variety of browsers and screen readers and performed the test in their own environment. Results showed that even though the Web sites were designed using WCAG 1.0, some major usability issues still existed for some participants with specific browsers…. Other results showed that some design changes made by the developers that were not based on the WCAG 1.0 actually appeared to improve accessibility more than some of the changes outlined in the guidelines….

This article, by the way, is in dire need of copy-editing. Among many errors, the man who won a complaint against the Sydney Olympics is Bruce Maguire, not Brian Maguire. (My Reader’s Guide to Sydney Olympics Accessibility Complaint is still online, and was slightly expanded in my book.)

“Assessing the accessibility of fifty United States government Web pages: Using Bobby to check on Uncle Sam” (great pun there) by Jim Ellison

You know, we really don’t need any more papers – not a single additional one – in which Web accessibility is tested using some automated method, let alone Bobby. Automated testing can never prove your site is accessible and misses a large number of important criteria. And these papers actually admit those limitations, which are crippling and which undercut the entire project.

I know it’s convenient as hell, but can we stop pretending that automated accessibility checking has any real meaning whatsoever?

En tout cas, this paper is useful for its massive list of references of previous papers. Beyond that, well, we know that even sites with a requirement to be accessible occasionally aren’t, and most of the errors found in this limited survey bordered on the inconsequential.

“A comparative assessment of Web accessibility and technical standards conformance in four EU states” by Carmen Marincy and Barry McMullin

This one’s got a bit more going for it, despite also using automated testing. Excerpts:

• The typical practice of many Web content developers is to test Web site functionality only against a small number of “popular” Web browser platforms in “normal” configurations. Although the content might seem to be rendered correctly in these tests, this does not guarantee that it is designed correctly. By definition, users of specialized assistive technologies are not using “popular” platforms – or at least, not using them in “normal” configurations. Rather, they must depend on equipment tailored to their particular needs. As a result, it frequently happens that sites are poorly accessible, or completely inaccessible, to such users….
• However, because they do not conform to technical standards for interoperability, their rendering is – at best – unpredictable. This is likely to have a disproportionate affect on users who rely on specialized, tailored, client technologies – specifically, users with disabilities. Content may thus fail to be rendered, may be garbled, or may be otherwise inaccessible to such users. Worse, precious development effort in individualizing assistive technologies may have to be spent on attempting to compensate for these server-side defects, rather than improving the client-side functionality that the user really needs. In the worst case, this effort may have to be wasted repeatedly for each different client accessing each different (non-conformant) server. Obviously, conformance to technical interoperability would substantially reduce or eliminate this waste.
• Only four U.K. sites (less than 0.2%) and six German sites (less than 0.4%) had completely valid HTML markup. No Irish or French sites had completely valid markup…. Additionally, even after reducing the samples on the basis of usable DOCTYPE information, just one Irish site (3%), 29 U.K. sites (4%), 16 French sites (4%) and 29 German sites (2%) had valid HTML markup in the remaining pages….
• The site capture mechanism used in this study suffers from significant limitations with respect to sites which require user “registration.” More generally, automated evaluation of “interactive” sites is fundamentally problematic. This is particularly important given the growing number and diverse roles of such sites. A special issue relates to those sites that allow users to “personalize” site appearance or behavior. In those cases, it might be argued that such a site’s content can be tailored to the needs of each user, and is therefore fully accessible even though this may be invisible to an automated mirroring robot. However, since a user needs to access the default Web presentation in order to “personalize” it in the first place, the default configuration – the one that would be automatically retrieved – should be conform to WCAG 1.0.

“Sight into Sound” by Lisa Gibson (232 K PDF; text-only)

My esteemed colleague Lisa Gibson was in town from Oz last year on her Drowned World Tour researching audio description. They don’t really have DX in Australia, you see, and her stated goal was “to study and compare different mediums relating to audio description and gain an understanding of the impact of relevant disability access policies in USA, Canada and UK.”

It was curious indeed not to read of Lisa’s triumphant viewing of X-Men 2 here in Toronto. Hey, I was there. It happened.

Also, the section on CRTC audio-description requirements is not quite up-to-date, but then again, even I am not maintaining a centralized list. (I really should, I suppose.) There’s also been a bit more “consumer feedback” on “film-based art” like TV and movies than the report suggests. (I have most of the studies, actually.)

A finding of note:

Discussion was held as to whether the accent of the describer and use of colloquial terms should match the country of origin or the international viewing audience. Many highlighted the need to educate the viewer to new terms, if country-of-origin terms were used (flat vs. apartment [as a rudimentary example]), and a contrasting accent to their unaccustomed ear. In all countries, debate surrounded the use of politically-correct terminology. Whether identification should be made regarding things like race, physical appearance, people with disabilities, etc., and which terms to use. In essence, even censorship [sic] finds its way into audio description in some parts of the world.

And some of the implementation plans are of interest:

• To hold an annual conference to share, discuss and develop the different facets of audio description with practioners, stakeholders and users.
• To work towards inviting international speakers to the annual conference. [...]
• To establish accredited training guidelines and an accreditation process for audio description as a whole within Australia.
• Incorporate voice training into the training programme to enhance the delivery of the description.

Dedicated readers will have slogged through my turgid War and Peace of an exegesis on the accessibility and usability failings of the Scientific Atlanta Explorer 8000 PVR. Curiously, somebody else in town has been all up PVRs’ noses: Teehan + Lax (not Tegan & Sara), a small hive of graphic designers–cum–usabilitistas.

You may wish to download their inaccessible, untagged PDF report on usability failings of Bell ExpressVu and Rogers PVRs. (Curiously, ExpressVu was an early client of mine.)

I visited the duo of Geoff Teehan and Jon Lax and their three staff last week, and, in a frequently-pleasant conversation, we discussed usability, accessibility, and graphic design. As you can see on their Weblog, the company is arse-deep in plans for some supersecret new technology that has to be either a new software platform or another PVR- or Windows XP Media Edition–like product. Certainly they have no interest whatsoever in improving existing products.

So I told them they’d need to include accessibility, and I intended to hold them to that. Tons of my friends and I can help.

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.

• Independent Review of BBC Online
• More-convenient PDF links on this page of BBC coverage

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.