head shot of Peter Korn
Peter Korn's Weblog
The collected occasional commentary by Peter Korn, Accessibility Architect at Sun Microsystems, Inc.
Large Print   

20070818 Saturday August 18, 2007

A view of Linux as introduced by a blind user via Orca

Darragh Ó Héiligh, a blind Linux user in Ireland, has just posted an audio introduction of Fedora Linux with Orca. In his recording, Darragh acts as a tour guide showing some highlights of his Fedora Core 7 desktop through the Orca screen reader. Using the TTSynth text-to-speech engine (the only commercial software he is using), he invites you to listen in as he explores his desktop, reads some of his e-mail via the Evolution e-mail application, browses the web with Firefox, reads through an Excel (.xls) spreadsheet in OpenOffice.org, and reads through a Word document (.doc) also in OpenOffice.org. Both the spreadsheet and word processing document are files from his employer (with no confidential data revealed).

Darragh is a longtime JAWS users, and throughout his Linux introduction, he makes comparisons to the JAWS computing experience in Windows. In a posting last month to the Visually Impaired Computer Society of Ireland, Darrah describes his first experience using Orca on Linux to interview people at work - something he used to do on Windows with JAWS and MS-Office, but last month started doing with Linux, Orca, and OpenOffice.org. Darrah describes the process of reading through the interview script file (a '.doc' file), and writing notes in another window (saved as a '.doc' file to share with his work colleagues).

"Windows is still not my preferred operating system" reports Darragh at the end of his audio tour. "With the recent advances in Orca in GNOME, and the fact that with the work of the people on the Speakup Modified group, Fedora 7 makes it very easy to set up, and with the combination of everything it's just so fast to use; it's really becoming just a pleasure." His final comment, after noting the responsiveness of Orca with TTSynth and OpenOffice.org: "It's just getting the job done faster than it is in Windows."

In September he starts a new job with Novell, where he will be using Linux full time. (2007-08-18 10:07:49.0) Permalink

20070807 Tuesday August 07, 2007

"Involving People with Disabilities in the Standardisation Process" - booklet by Dr. John Gill

Dr. John Gill, Chief Scientist of the Royal National Institute for the Blind (and head of the RNIB Scientific Research Unit) has published a booklet titled "Involving People with Disabilities in the Standardisation Process" (there is also a PDF edition here). The booklet is both a good primer on the standardization process in general, the ways in which standardization can impact accessibility, and a discussion of the mechanics of being involved in a standardization effort as a person with a disability (along with notes for those setting up standards meetings on what you should do to enable such participation).

Published this past June, it is also incredibly timely. The issue of involving accessibility expertise and people with disabilities particularly into document standards efforts is gaining particular prominence at the moment. At one end of the spectrum is the OASIS ODF accessibility subcommittee's imminent publication of their Accessibility Guidelines for Implementations of Open Document Format v1.1. On the other is folks like the University of Toronto Adaptive Technology Resource Centre questioning whether OOXML should be accepted as an ISO standard without first undergoing an accessibility review.

I particularly enjoyed the booklet's Chapter 4 - Meetings. The discussion of the careful planning needed for including people with disabilities in a standards meeting - or an advisory committee meeting - have become a way of life for the Telecommunications and Electronic and Information Technology Advisory Committee. In the TEITAC plenary meetings I participate in, we always have a CART (Communication Access Realtime Translation) system in place for the deaf participants. In our subcommittee conference calls, we always arrange for U.S. Federal Relay Conference Captioning. One of the rules we follow in both sets of meetings is that we must announce our name and affiliation prior to making our remarks - so that deaf and hard of hearing participants can know who is speaking through their reading the simultaneous transcription. Another rule is that any presentation we give at the plenary meetings must be provided sufficiently in advance of the meeting so that large print and Braille editions can be produced for those who need them. Accessible electronic editions of the presentation materials are posted as quickly as possible to further aid in accessibility as well as being a public record of the meetings.

For anyone considering involving people with disabilities in a standardization process, Dr. Gill's booklet is an excellent overview of the subject, and I highly recommend reading it. (2007-08-07 23:59:49.0) Permalink

Flash accessibility challenges, noted by Niqui Merret

Niqui Merret, a Flash developer focusing on accessibility issues, has a nice writeup of some Flash accessibility issues she has run into. Of the issues she cites, there are two I would like to highlight and comment on:

No tabbing between Flash and HTML elements:

This occurs in plug-in based browsers such as Firefox, Safari, Opera, etc. This is not an issue in Internet Explorer. This needs to be solved by the Browser manufactures.

As Aaron Leventhal notes in blog comment, this is an existing bug in the Mozilla bug database and in fact, we've known about it for over 6 years. The problem is an interoperability issue - browsers and their plug-ins need to cooperate on keyboard traversal.

The other issue:

Flash does not take the high contrast settings on Windows:

If the user sets the system to High Contrast in Windows then all text and images are effected but no SWFs are. On a Mac the SWFs are displayed in high contrast. This is how the OS works but it would be nice to know if the user has set the PC to High Contrast.

The problem occurs on Windows and not on Mac because of how the feature is implemented on the two platforms. Windows defines a rich set of display attributes that should be respected (as does GNOME on UNIX), whereas the Macintosh applies an output filter to the pixels. The latter approach works more places, but is limited in the kinds of things it can do (e.g. there is no way to define the size just of text in buttons, or the thickness of a visual focus indicator, or the color and thickness of a text caret).

Interestingly, both of these topics are being discussed in the Section 508 Update effort's Web & Software subcommittee. The fundamental issue is that a web browser is both an application and a platform. As a platform, it must define a set of accessibility information to things running on it (e.g. web applications, plug-ins, etc.). Yet, as an application, it must respect the accessibility settings of the OS it is running on. And when it comes to accessibility APIs (Niqui also notes some MSAA issues with Flash in Firefox on Windows), it has the tricky job of either translating those between one platform and other (as we do with Java apps on UNIX, translating the Java Accessibility API to the UNIX accessibility API) or getting out of the way and allowing that communication to happen through/around it. (2007-08-07 22:28:34.0) Permalink


archives
links