This new report from the excellent Demos stable covers a facet of digital exclusion that affects a group who often experience social exclusion or discrimination and who also often require better accessibility  The internet has the potential to address some aspects of social inclusion through  electronic communication and participation. As more of life moves online we need to ensure none are excluded.

the overall proportionof adults who are digitally excluded is only expected to decline from 39 per cent in 2005 to 31 per cent in 2015

it explores what ‘digital exclusion’ means for older people and seeks to illuminate wider questions about how to support other social groups who are also likely to be on the wrong side of the digital divide.

Dr. Randy Pausch's last lecture at Carnegie Mellon is excellent. And enabling the childhood dreams of others.

This round of work on Jambu concentrated on developing 'direct in application' control from switches and other limited gesture Alternative Input devices. The idea is to provide a mechanism to operate a program's User Interface directly with without having an intermediate overlay (or OSK). This direct navigation and selection of applications provides access to all features and should therefore be attractive to users who are confident computer operators but have (or have developed) restricted movement. Mozilla have again provided funding through their accessibility grants scheme and I'm very grateful to them for making it possible. This is both a work report for Mozilla and a personal commentary of my experience developing an AT.

Eitan Isaacson has acted as a mentor and brought his invaluable experience with pyatspi from his work on accerciser and Orca. He kindly provided some example code (hacked on a domestic flight) that demonstrated a technique for minimal caching, suggested using GTK TreeView to give a starting MVC architecture and also help 'knock up' a proof-of concept of the code to draw over an application. I'm very grateful for his input during a time when he was very busy working on improving Orca's performance. In addition members of the wider Open Source accessibility community provided great help and ideas (this is one of the really positive features of Open Source and one I should tap into more).

So what can it do? It provides access to most of Minefield's UI and so proves the concept as well as providing a firm bases for further development into a polished solution. There are a couple of bugs to fix (they always appear after you've made a release). Some improvements to make and a few temporary work-arounds waiting for Mozilla bugs to be fixed or where work is in progress on a feature. One of the practices of Open Source development that I find mildly disconcerting is releasing early, warts 'n' all, so others can (potentially) test and review it. Being a bit of a perfectionist I naturally want a highly complete solution before I release it on an unsuspecting world. You do have the same tension in proprietary development too, as at some point you have to get it out the door, but my experience is that you usually wait as long as you can, largely as the user is paying for it and releases are less frequent.

The most important lesson I learnt is that creating an AT is a challenging task with many complexities and subtleties to deal with ( "Nuff R'spect" to the Orca and GOK devs). Accessibility APIs are rich and application structures and behaviours are complex systems with a few 'gotchas' to be worked out. I endeavoured hard to avoid lots of case specific logic and keep to generalisations that minimized dependencies but that is hard to achieve. In hindsight I could have just hacked it all out and then worked out the emergent rules (the would still have hit the same problems, but saved time trying to get good code). A certain amount of 'scripting' is going to be inevitable to handle application differences (I plan to use a template design pattern).

At times it gets frustrating as you yet again revisit code that you thought was working but breaks when implementing a new feature or fixing a bug. This reminds me of the old Windows development saying of how 'when you empty the ashtray the wheels fall off'. I don't mean to sound negative as this is all part of the learning curve for developing accessibility and you develop techniques to avoid it. If it was easy then everyone would be doing it already (there's plenty of technical fun to keep us fully engaged). The curve proved much steeper than I expected and so took longer than investigative test scripts indicated. The trick will be to help new AT developers to short circuit the learning curve.

I started out on the wrong foot to some extent, suffering endless desktop lockups and apparently non-deterministic behaviour. The code was initially created as an accerciser plugin as that gave a useful environment and easy ways to explore with the possibility of links to accerciser functionality. I was also using the excellent Wing IDE debugger to explore and step through the code (and I love the DebugProbe feature that lets you modify and prod the live system). At Eitan's suggestion I started with GEdit as the target because GAIL is pretty stable and that would would provide better visibility on what issues were infact Firefox bugs.

It turns out that AT-SPI events are synchronous (direct procedure calls, not asynch RPC as I sort of assumed). So you have to do as little as possible in the event handlers and return ASAP. (this is rather like the good old days of Interrupt Service Procedures or Real Time, without the reentrancy and latency issues). GAIL is also a little sensitive to what you call when and can easily go into a sulk. Anyway once I made a stand alone application, desynchronised with a queuing mechanism, stopped using the debugger and reverted to good old print statements things got a lot more stable. There are still timing issue when printing a lot of data and other timing funnies but these will get resolved with attention to the structure and state processing.

Popup menus and windows are the most complex and sensitive to work with and of course I started with them. Most user actions make them disappear (by design) so they are hard to work with and monitor in accerciser. Little exploratory test scripts help. The massive effort on Orca (and other screen readers) means that the keyboard driven, focus monitoring dynamics are well understood and debugged. However Jambu works by calling the doAction function without focus setting the context and this uncovers a few strange behaviours (aka bugs) which had to be understood, bugs raised and workarounds found. Sometimes events just don't seem to happen or happen in different orders so you need to code around that. You also don't see all of the events that you might expect. Working on the trunk also exposes you to changing features which can be confusing at times (it's a trade off to wanting bug fixes and wanting to be isolated from other changes).

Accerciser, GOK and Orca code provides examples and inspiration (though I initially missed the significance of the event queues). You can also look at the Gail and Firefox code to try to understand what is happening but it is complex anda little obtuse (Ieven attempted to fixed a Firefox menu bug but  with no result yet).

Future work includes cleaning up the code and structure, possibly introducing a formal state machine to handle the dynamic behaviour better and definitely adding per toolkit/application scripting. A better story is need for web documents, in particular dealing with scrolling large documents and handling large sets of links/fields. Multicolumn lists (table/tree widget) needs some TLC in order to have sensible navigation and for selection to work. Text input needs integration with Dasher/GOK or OnBoard (someone has said they are interested in looking into Dasher). To be a usable AT more scanning options are needed as well as clever navigation schemes and smarts as it is clear that the current simple scheme can be long-winded at times.

In response to Eitan's suggestion of regular releases I spent a little time setting up a source release (using distutils and providing NEWS, ChangeLog etc), bringing this forward as I had it planned as a future task. There's also a jambu google group to aid communication. This has the benefit of making it more accessible project, with clearer progress and so hopefully attracting others who can bring their ideas, experience and help (hint, hint).

Preview from Lachlan Hunt, including the new structural markup tags which:

By identifying the purpose of sections in the page using specific sectioning elements, assistive technology can help the user to more easily navigate the page. For example, they can easily skip over the navigation section or quickly jump from one article to the next without the need for authors to provide skip links.

In a previous post I noted that pyatspi events are synchronous so you need to do as little as possible in your handlers before returning. Plus you probably want to avoid calling certain pyatspi functions/methods in case you invoke further events and have not created re-entrant code. As this means that you need to queue events I hacked up a simple queue based message dispatching system to call function's in GTK idle time in response to events. After this I spotted the Queue standard Python module which provides a pukka thread-safe (re-entrant) solution.

Peter Parente (author of pyatspi and LSR) has kindly pointed out that pyatspi has built in support for queuing application events (using the Queue module). To use this you simply pass True as the first parameter (async) of Registry.start which puts it on Registry.queue. You can then later dequeue and pass to Registry._dispatchEvent (I can't see a public interface for this). This doesn't apply for device events.

I'll rewrite to use this, partly so I can remove my extra code and partly as I'm still getting the odd issue which perhaps useing the Queue module will resolve.Apart from queuing the dispatch mechanism I created maps pyatspi to logical events that add some abstraction (like MenuClosed) so I'll repro that.

[Update] I created a bug and supplied a patch to add pyatspi code to process queued events.

Ability Net's channel on YouTube features a recently reorganised playlist of videos. There's a new accessibility topic that includes web 2.0 and one on Ultra Mobile PCs that includes the Nokia N800.

[UPDATE] Thanks to  David Poehlman for pointing out that the University of WASHINGTON's  DO-IT program also has a number of free streaming videos amongst the many useful resources.  The 'Working Together' series are interesting with a strong user perspective, for example Working Together: Computers and People with Mobility Impairments covers nearly all of the technology options for alt input. Those I looked at are video described and have subtitles.

This video shows how to use a wiimote to access Linux using the Compiz window manager (it's a bit heavy on the bling). It demonstrates that UI access is workable but the screen comments indicate it's not easy. 

I'm sure that tune is a midi version of 'Popcorn' which I remember as corny (hehe) moog electronica tune on TOTP from my youth (I also seem to  recall a video of people bouncing on trampolenes, even if it was before videos).

Some useful examples of transport maps from the MySociety folks (who produced the invaluable FixMyStreet). The interactive ones present the data well. You can browse or grab the source.

For those new to open source it's not always clear how the development process works and how it is different to a proprietary situation. Well it just occurred to me that a recent experience neatly shows how the open exchange between several people brings a fast solution to a problem found in the software used by another project, even when those people are in different time zones (UTC, UTC-6 UTC-8). It's also makes a nice little story.

While working on Jambu it became clear that events I received from the a11y API pyatspi need to be placed in a queue so that they can be processed asynchronously. I blogged about this and my solution and Peter Parente (LSR and pyatspi developer) dropped me an email (having spotted the post) to say that pyatspi could do this for me. He explained the feature I had missed and then when I spotted that the code to dequeue the events was missing he requested that I raise a bug. This I did and submitted a working patch based on code in LSR that had not got copied into pyatspi. This code was also used as a temporary local fix in Jambu (python makes that sort of thing easy to do).

Meanwhile Peter and Eitan Isaacson (pyatspi, accerciser and Orca developer) discussed it in depth and proposed a more general solution allowing the specification of the number of items to dequeue and returning an indication of if any events are left in the queue. Eitan requested that I update my patch so he could commit a solution. Due to a bit of stupidity on my part I only did half the job, but Eitan quietly completed it and committed the code to the trunk in version control.

So now the temporary Jambu code can be removed and as Jambu is a developer release it can be used now without waiting for a release of pyatspi to hit the distribution channels (as devs are happy to get code from version control).

So there you go, a fast fix made available in a few days. In a traditional proprietary world you would be stuck with creating a work around, reporting the bug and waiting and hoping it gets included in a future release according to their priorities. What's more other developers would be in the same situation.

Oh good grief, here we go again...

..hold on...

No it's ok, phew!

I rather like the way this one came out. FIrst Microsoft say IE 8 supports ACID2 and then they say it is fully backward compatible. A few soles spotted the problem with that and pushed hard 'till all was revealed.

Oh I just tested the latest Minefield trunk (Firefox 3) and acid2 looks almost perfect with just a small sizing difference observed when switching between the reference and back ;-)

The OpenDisc and OpenEducationDisc offers a collection of the best of FOSS software. Especially usefull now the OpenCD project has frozen.

One to download, burn and give away to all your friends. It is about 3 months old.

ISO32000

Having used OpenOffice.org and  Firefox for a while the Gendarmerie will now migrate all 70, 000 PCs to Ubuntu over 4 years. Linux has been selected for independence, security and cost. Plus they'll also get all the great accessibility features of GNOME.

As tanslation by Babel Fish:

It becomes thus one of the largest administrations in the world to be passed to the free operating system

During this advertisement, the gendarmerie made a point of reaffirming its "confidence in the model of the free software" and advanced three explanations to its choice of Linux. The annual saving in seven million euros was evoked besides there only in the last. Before that, it is the diversity, to depend only on one supplier - Microsoft in fact - and the independence, to have a better control on safety, which made the difference.

Linux from now on is regarded as a "mature" systems of the market for a professional use".

My emphasis.