Tuesday Jun 24, 2008

The Stalled Server Room

The Daily WTF has an interesting post today.

A company had to relocate from the second to the first floor in their building. Unfortunately their server room couldn't be moved.

Here's the letter from building management explaining the situation:

Hi all.

As you all are aware, we have new tenants that have moved into the 2nd floor suites. The access to the server room is now via the women’s bathroom.

There will be a sign on the woman’s door that can be changed from OPEN to CLOSED and vice versa.

Should you need to enter the server room, please change the sign to CLOSED. Once you are done, please change it back to OPEN.

Once you enter the bathroom, you will be able to access the server room via the handicapped stall. Please close the stall door prior to entry, just in case someone doesn’t see that the bathroom is closed.

I know this isn’t ideal, but if we adhere to this protocol, I don’t think anyone will be disrupted.

Thanks! Let me know if you have any questions.

I have one. Do the AAPD know about this? If they don't, they will soon.



Monday Jun 09, 2008

Eee PC With Ubuntu And Orca

I got an Eee PC for my birthday; one of those with 1GB on memory and 8GB of "solid state" disk. I played around with the kiosk-mode Linux that came with it. I know you can fairly easily get out of that mode, but as I really didn't want to learn yet another version of Linux, I decided to install Ubuntu Hardy on it.

I upgraded my previous created Ubuntu Gutsy bootable thumb drive to contain Hardy. These instructions helped out (thanks Ryan). I did the:

$ sudo lilo -M /dev/sdd

at the end just to be safe.

There's still some problems:

  • Battery Monitor: "Battery may be broken: Your battery has a very low capacity (1%) which ..."
  • Wireless connection not working.
  • Microphone not working.
  • SD card reader not working.
  • Webcam not working.

but I'll leave them for another day. Hopefully this page should be a great help in fixing some of them.

For now, I've just hooked up the Eee to an external monitor, USB keyboard and mouse. I'm using a wired network connection and I've plugged in a nice set of speakers. I've also installed all the updates from the network repositories to get this up to GNOME 2.22.2.

I followed the Orca setup instructions and installed the nice Cepstral Callie voice, and voila! I have Orca running on yet another computer.

The potential here is that it's running on such a nice small portable machine though.




Friday May 30, 2008

Links for 30th May 2008

Three accessibility related ones.



Wednesday May 28, 2008

A GNOME Lock Screen Accessibility Hack

One of the things I like about working on Orca, is the challenge of trying to make a poorly designed application accessible to blind people.

Here's the bug. The GNOME lock screen application has started on the user's desktop. When they press any key, it invites them to type in a password. If they type in their password incorrectly, they will first see some text appearing in a label under the password text area saying "Checking...". Then this is replaced with some more text saying "Incorrect password." It then wiggles the dialog box from side to side a couple of times, then removes that text. It also clears out the password text area.

I mean, even if you are a sighted person and you'd wandered away from the screen for a few seconds, it's distinctly possible that you wouldn't have seen these messages and have any idea what happened.

For a blind person it's even worst. Nothing is spoken whilst this operation is happening (i.e. those labels don't get focus). Orca also has this feature called "flat review", where you can examine the contents of a window or a dialog component by component and see what their states are. That's not going to help here because the gnome-screensaver-dialog designers have decided that that useful information isn't needed after they've finished jiggling the dialog.

So what can you do? Well, we can write a Python script in Orca specifically for the gnome-screensaver-dialog application, to try to work around this. Every time the text caret is moved to (i.e focused in) the password text area, Orca gets an "object:state-changed:focused" event. This gets passed onto the onStateChanged callback in the Script class. In our gnome-screensaver-dialog script, we override the default behavior for that method.

Here's where the fun begins. Several other different types of "object:state-changed:..." events also arrive here, so we need to check that it's a "focused" type and the it's for a text area that has a role of "password text". Luckily there's only one of them in this application, so we don't need to get any more specific then that.

If it isn't an event we are interested in, we just pass it on to the parent class.

If it's an "object:state-changed:focused" event for the password text area, we walk back up the accessible component hierarchy for this dialog and get the parent of the parent of the parent of the object that had the event (i.e. the password text area). We know that that object has six children, and two of them are labels. Those are the ones we are interested in. So we iterate over the children and if it's a label and it has a name, then we speak the name. The name in this case will be set to "Checking..." and "Incorrect password" when those states occur.

It's hardly an exact science. It's yet another hack. This all works because we get a couple more "object:state-changed:focused" events at the right time and can extract this other information out. If the dialog is redesigned, and the hierarchy is no longer the same, then our script won't work. The real fix here would be to get the gnome-screensaver-dialog developers to redesign their code so that we didn't have to jump through hoops, but from past experience we don't always have the success we would like with this approach.



Thursday May 01, 2008

My First Post On The design @ Sun Blog

A couple of weeks ago, Maya, one of the xDesign folks at Sun, asked me if I'd like to be one of the contributors to the design @ Sun blog. In particular, blogging about accessibility related design.

I accepted. Today was my first post. As this is a serious topic oriented blog, they have a different setup than I do with my own blog. The potential posts are vetted and then scheduled to appear. It felt weird waiting about ten days for the post to see the light of day, but I guess I'll get used to it.



Friday Apr 25, 2008

Getting Orca Working On OpenSolaris Developer Preview RC1

I've got an old Dell Dimension 8200 that's setup as a triple boot. As well as running Windows XP and Ubuntu Hardy, there is a partition available to install Solaris.

On Wednesday I burnt a copy of the OpenSolaris Developer Preview RC1 Live CD and installed that. I see that RC2 is now available. Doh!

(Serendipitously, the IPS network repository went live last night. This helped make life much easier and maybe even alleviates the need to do all of this again with RC2. Dunno).

Next I needed to download the Sun Studio 12 compilers. I just downloaded the compressed tarball (about 240 MB's), uncompressed it (about 950 MB's) and added a couple directories to my PATH and MANPATH. It sure would be nice if the compilers were packed with a finer granularity. I really don't want to have almost a gigabyte of stuff lying around if all I'm needing is a C compiler. Gnu compilers seem to have solved this problem.

Next I downloaded and installed the JDS CBE. From chatting with various folks on the #opensolaris IRC channel on freenode.net, I suspect I didn't need to do this. Anyhoo, I installed the SUNWhea and SUNWsfwhea package via the IPS network repository, then ran the CBE install script. I answered no for each of the extra packages it wanted to install for me, and then pointed it at the Sun Studio 12 C compiler that I'd just installed. This all seemed to install into /opt/jdsbld just fine. I added the /opt/jdsbld/bin directory to my PATH.

I then needed to install the SUNWsvn package to get a version of svn that worked (the one in /opt/jdsbld/bin needed libdb.so.1 which wasn't there). I moved the broken one out the way (renamed it svn.broken).

I then used svn to check out the latest Orca sources from SVN trunk and tried to run autogen.sh on it. This started to bitch because of missing pieces, so I ended up installing a few more packages from the IPS network repository for things like gnome-common devel, Gnu m4 and the Perl XML parser. (I think the package names are SUNWgnome-common-devel, SUNWgnu-automake-110, SUNWgm4, SUNWlibtool, SUNWaconf, SUNWperl-xml-parser -- thanks Joanie).

I was then able to successfully configure, build and install Orca (installing as root). When I ran Orca, it automatically went into setup mode and turned accessibility support on. I then logged out and back in again, and was able to run Orca.

With no speech.

This was because there was no sound. Before I started the operating system install, I ran the application that checks to see if all your hardware is supported. This complained that the driver for my sound card was missing. The sound device is an Ensoniq 5880 AudioPCI. One of the kind folks on #opensolaris suggested I try installing OSS. I then did just that, downloading the Solaris package and adding it and then rebooting. When it came back, I ran osstest and everything worked nicely.

I then installed a copy of Fonix DECtalk for Solaris, which I wanted to use as my text-to-speech engine.

After that, the next step was to check out the latest gnome-speech code from SVN trunk, and configure, build and install it. It found the DECtalk driver and when I restarted Orca, it burst into voice. Woo hoo!

I now have an OpenSolaris Developer Preview development environment for Orca.




Thursday Mar 06, 2008

Converting Orca to Python 3.0

Something we've got to be thinking about soon is seeing what needs to be done to get Orca to run with Python 3.0, which is planned to be available in Auguest 2008.

So I thought I'd give it a try now with the current Python 3.0a3 download.

Building it was trivial:

  $ cd /home/richb/Python-3.0a3
  $ ./configure --prefix=/usr
  $ make
  $ sudo make install

Guido and team have even made the conversion trivial. There is a tool called 2to3 in the Tools directory that will do the refactor for you.

I checked out a clean copy of the Orca sources from SVN and converted it with:

  $ cd /home/richb/Python-3.0a3/Tools/2to3
  $ python refactor.py /home/richb/gnome/orca/trunk/src >/tmp/diffs

This generated about 115KB of patch diffs on standard out which I then applied to the Orca source code:

  $ cd /home/richb/gnome/orca/trunk
  $ patch -p0 </tmp/diffs

I then configured, built and installed Orca with:

  $ cd /home/richb/gnome/orca/trunk
  $ ./autogen.sh --prefix=/usr
  $ make
  $ sudo make install

As it was byte-compiling all the Orca Python modules it bitched about the following two problems:

orca.py", line 1306
    + Q_("option|main-window") + "]", end=' ')
SyntaxError: invalid syntax

orca_prefs.py", line 636
    os.close(os.open(initFile, os.O_CREAT, 0o700))
SyntaxError: invalid syntax

For the second one, it looks like "0o700" should be "o0700" but I couldn't work out what was wrong with the first one. The original code was:

    print "-e, --enable=[" \\
        + Q_("option|speech") + "|" \\
        + Q_("option|braille") + "|" \\
        + Q_("option|braille-monitor") + "|" \\
        + Q_("option|magnifier") + "|" \\
        + Q_("option|main-window") + "]",

and it refactored it to:

    print("-e, --enable=[" \\
        + Q_("option|speech") + "|" \\
        + Q_("option|braille") + "|" \\
        + Q_("option|braille-monitor") + "|" \\
        + Q_("option|magnifier") + "|" \\
        + Q_("option|main-window") + "]", end=' ')

According to the What's New in Python 3.0 web page, that seems okay. For now I've just removed the "end=' '" part and I have a successful install (with a minor run-time formatting error when you print out the usage message).

When I run Orca, everything seems to work fine. No tracebacks and Orca is happy brailling and speaking away.

What worries me is that when I check the version number of /usr/bin/python (which is the same binary as /usr/bin/python3.0) I get:

  $ /usr/bin/python3.0 --version
  Python 2.5.2

So I'm not convinced I've done everything correctly.

Still it was nice to know that the conversion should hopefully be fairly trouble free when we do it for real. I guess that comes from pylinting the code to within an inch of its life.



Monday Mar 03, 2008

GNOME Outreach Program: Accessibility - List of tasks published!

Lucas has just announced that the list of tasks in the GNOME Accessibility Outreach Program has now been published. If you are interested, consider signing up.

Interesting logo. It made me think of those Little Green Men Squeeze Toy Aliens that worship The Claw in Toy Story.



Tuesday Feb 26, 2008

Links for 27th February 2008

All accessibility related ones.

  • YouTube videos from India on Orca and Open Source Accessibility:

    Video #1

    Video #2.

    See the much more extensive commentary by Peter and Will on why this is great.

    Congratulations to Krishnakant Mane, (who is also an Orca community member) for his leadership in helping to bring free accessible solutions to India.

    Unlike Peter, I will comment on the start of the second video, which is a promotional video by ELCOT. There was a mail thread a little while ago on an internal bloggers alias about a post from a Sun employee that made you cringe. Well the start of this video (and the very end of it) made me cringe, but for a completely different reason.

  • GNOME Foundation Announces Program to Sponsor Accessibility Projects

    "BOSTON, Mass—February 27, 2008 — The GNOME Foundation is running an accessibility outreach program, offering USD$50,000 to be split among individuals. This program will promote software accessibility awareness among the GNOME community as well as harden and improve the overall quality of the GNOME accessibility offering."

    Hopefully this will attract quality GNOME individuals. Those interested should check the project web site.

    (thanks Will).

  • Is Your Sidewalk Accessible?

    You learn something new every day.

    (thanks Calvin).



Thursday Feb 21, 2008

Linux Journal Orca And Accerciser Articles Now Online

Due to "high demand", the two March 2008 Linux Journal articles mentioned in a previous post are now online.

(thanks Eitan).




Friday Feb 15, 2008

GNOME Accessibility Bugs

Over the last three or four weeks I've been triaging the huge number of GNOME accessibility bugs that we currently have. You can find the current list here.

It was even longer a month ago. There are several that have been closed out as they are no longer reproducible and, after a gentle prod, a few others have been closed as fixed using the patches that were attached to them (or a slightly modified version thereof).

But there are still a lot that remain. Here's the totals by product:

  1. orca
  2. gok
  3. gnome-themes
  4. Evolution
  5. atk
  6. at-spi gtk+
  7. nautilus
  8. gnopernicus
  9. metacity
  10. gnome-panel
  11. gnome-control-center
  12. epiphany gdm
  13. gnome-applet gnome-mag gnome-speech
  14. at-poke xscreensaver
  15. ekiga tracker vte
  16. gnome-media gtkhtml2 HIG
  17. gnome-desktop gnome-games gnome-screensaver GtkHtml rhythmbox
  18. balsa dasher f-spot glade3 gnome-main-menu gnome-session gnome-terminal libgnomecanvas libgnomeui libwnck planner totem
  19. accerciser anjuta bug-buddy bugzilla.gnome.org conglomerate devhelp dia doxygen evince Evolution.Data-Server gcalctool gconf-editor gdl gftp glade gnome-alsamixer gnome-user-daemon gnome-utils gnome-vfs gtkmm gucharmap java-gnome libglade libgnomedb ORBit2 printman sawfish system-monitor Tomboy xchat-gnome

Here's some notes:

  • The bug/enhancement list is generated by looking for bugs which have a keyword of "accessibility". There will be a lot of accessibility bugs out there which have omitted this keyword and therefore don't show up on this list. For example, there are 28 accerciser bugs and enhancements filed, but only one of them has the requisite keyword.

  • The Orca bug/enhancement count is misleading. There are currently 160 bugs/enhancements filed against Orca, but 59 are what we call "tracker" bugs. This is where we file an Orca bug that tracks another accessibility bug. The other bug might also be in the GNOME bug tracking database, but it could also be for other products like OpenOffice or Firefox, which use their own separate bug tracking systems. The Orca tracking bugs have "[blocked]" prefixed to their Summaries.

  • Some of these accessibility bugs have been open for almost six years.

So, for any GNOME maintainers reading this, I encourage you to try to get these bugs fixed. We (the accessibility team) quite often see "but I know nothing about accessibility" as comments on the bug reports. That's okay (well it isn't really, but let's not go there) and if that's the case, just let us know (via a comment on the bug) and we'll try to help you.




Tuesday Feb 12, 2008

Orca On Cover Of Linux Journal

There is an article by Will Walker on Orca in the March 2008 edition of Linux Journal. I was able to proof-read this a little while ago, and it's a great introduction to GNOME Desktop accessibility.

The same issue also features another accessibility related article by Eitan Isaacson on Accerciser.

Congratulations to both Will and Eitan.





Tuesday Dec 18, 2007

Orca Magnification Improvements

Joanie and I have recently been improving magnification support in Orca. Mostly Joanie. I was just hooking up the Glade UI. You can read all the details in her blog post from yesterday.

The latest Orca tarball has all our good work in it.

As somebody who probably wishes to remain anonymous flippantly mentioned yesterday, "this now brings Orca magnification support into the twenty-first century".

We are only as good as the underlying magnification technology and there are still several problems that need to be addressed and we've unfortunately just lost the maintainer.

Still, it's a vast improvement over what was there two weeks ago.




Thursday Oct 18, 2007

Linting Orca

The Orca team is in the process of porting the code to work with pyatspi. This is a glue layer that allows Python applications to work with AT-SPI. Several other applications already use it and it will mean that future changes in this area are confined to one place, which will make maintenance and future enhancement easier.

It's a big change for Orca. We had our own wrapper methods to the AT-SPI interfaces and they were different in so many subtle ways.

To try to help find mistakes as we port the code, we've started using some lint like tools for Python. In particular:

They are all nicely in the Ubuntu network repository, so downloading and installing them is trivial and only takes a copy of minutes.

(Aside: Anybody who has kids in the U.S. has probably watched Between the Lions at some point. One of the characters on this show is Cliff Hanger. There is a little ditty that goes with this, something like:

"Cliff Hanger, hanging from a cliff. That's why he's called Cliff Hanger!"

Anyhoo, whenever I hear the word pychecker, it makes me cons up a variant of that. Lifehacker has the same affect. Senility is setting in).

Where was I? Oh yeah, Python linting. The first one we tried was pychecker. It found about 950 errors and warnings in the Orca code. We've now reduced that down to about 20 warnings. Several of these will just go away as we refactor the code for the pyatspi port. There are about 3-4 that we currently haven't a clue how to "fix".

Next was pyflakes. Even after running Orca through pychecker it found about another 100 warnings; mostly for imports of modules that weren't being used in certain source files. Why pychecker didn't flag these is anybodies guess. Each of the tools seems to have their own agenda. What was even more frustrating was a second run of pyflakes found a couple of different problems that the first run missed (and no, I didn't create these problems with my "fixes" from the first pass through).

So we fixed up all the pyflakes warnings and were onto pylint. This generated over 10000 lines of output. It also gave us a score out of 10. We have base Orca code and scripts for applications. Here were the initial scores:

  • Base Orca files: 3.81 out of 10.

  • Orca application scripts: 5.45 out of 10

With all the output it's hard to see the wheat from the chaff. We fixed up three simple kinds of "errors" first:

  • Line too long - by default, it doesn't like lines greater than 80 characters long. One could argue that it's only old fossils like myself that care for this kind of thing. And pylint.

  • Bad indentation - we use 4 space indentation. pylint was very good at finding these. pychecker and pyflaky didn't even twitch for this problem.

  • Operator not preceded by a space - it objected if you wrote "a=1" instead of "a = 1". Yes Virginia, there are people out there who write this sort of crud and think nothing is wrong. Hah! pylint catches those evil perpetrators.

It's easy to also suppress or adjust for lots of different coding styles as the pylint man pages show. By using some adjustments to the default regular expressions for variable names, we were able to drastically reduce the output.

After about 2-3 hours hacking away, the output is now down to 5681 lines with the following scores:

  • Base Orca files: 5.94 out of 10.

  • Orca application scripts: 7.63 out of 10

I'm sure a few more simple command line options to set some different defaults will get rid of quite a lot more. Then we will need to carefully check over what's left.



Tuesday Oct 02, 2007

Finding Some Firefox Accessibility Problems With GreaseMonkey

After learning GreaseMonkey and doing a fun project for myself, I thought it would be a good idea to see how useful it was for something job related.

As you probably know, I'm part of the team working on Orca, a Python based screen reader for Linux and Solaris. One of the things we are trying to do is make sure the Firefox 3 browser is accessible to people who are blind or have low vision.

As it currently stands, Orca does a pretty good job with most Firefox web based content, but occasionally there are some elements that are problematic. If a web page contains elements which have a style which has:

  • position:absolute;

  • floats: (float:left; float:right;)

then Orca goes into a tizwas.

Here's where GreaseMonkey can help. I've put together a simple first version of a script that will, for every web page, look to see if it contains these style properties. If it does, then it adds an element to the top of the web page to indicate that this web page sucks and a couple of links are provided, to allow the user to either remove the offending elements, or to highlight them.

There are a couple of things I'd like to change, but I haven't worked out how to do it yet. Suggestions would be most welcome.

  1. For highlighting problematic elements, I currently set their background to red. If they already have a red background, then they aren't going to show up. It would be nice to either use a red dashed box around the offending elements and/or make them blink to show exactly where they are.

  2. For certain web pages, Bugzilla for example, the new elements I'm inserting at the top of the page aren't showing up properly. They are being overwritten by the rest of the web page. There must be some magic to "push" the rest of the web page down below them.

A couple suggestions for the next version (thanks Joanie) are:

  1. When the user clicks on the new link at the top of the page to remove the offending elements, then when that's finished, that link should be replaced with a message that says "offending elements removed".

  2. As well as 1. above, provide a new link to restore the offending elements. Probably the easiest way to do this is to add some Javascript code that will do a new XMLHttpRequest() call on the current page.

One thing that should be noted is that most web pages have one or more elements that match the problematic ones above. Our own Sun blogs main page and Google are good examples. My own blog is another offender. In fact, if I use this GreaseMonkey script to remove those elements, it completely removes the two outer columns. Whereas this script is useful for tracking down web pages that are causing us problems, it's not the solution for making them more accessible.









« April 2014