Axxlog

In “Big, Stark & Chunky” (Axxlog passim), I described a set of design guidelines authors could use to transform their multicolumn sites with small type into single-column sites with big (and usually reverse) type. The resulting site is more usable to low-vision people who blow up the screen display to a nice big size – and you avoid the disadvantages of “alternative” sites that aren’t updated as frequently as the main site. It still is the main site, merely with a different graphic design.

Now, how do we implement these zoom layouts?

(more…)

Five long months in the making, Big, Stark & Chunky teaches you how to use CSS to automatically redesign and reorder your Web site for low-vision people.

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.