The application is still at alpha stage with more features at the task list and wish list stage. There’s also an interview with its creator, Dennis Lembree, over on the Accessify blog, which will give you a good insight into how the design came about.

Whilst most Web 2.0 apps are initially inaccessible, once they become mainstream, there does seem to be a drive by independent developers to try make them accessible (providing they can hook into the relevant bits of the backend code). So is this almost collaborative approach to producing accessible, usable apps the way forward rather than trying to do everything in-house?

The hour long podcast was conducted in the form of an interview by Jonathan Mosen with Freedom Scientific’s Chief Technical Officer, Glen Gordon, who gave an overview of what it does. Following the interview, Mosen gave an example of it in use.

Gordon started off by talking about Web 2.0 and how web pages are becoming more and more like applications and suggested that, in a way, we were returning to days of the dumb terminal. The distribution model has also changed. Nowadays, many applications are free to use, with funding either from advertising or as “pay-as-you-go” or “pay-in-chunks”. Web 2.0 has various benefits including centralisation of documents, which can be accessed from anywhere in the world via multiple device types, and ease of collaboration.

However, there can be accessibility issues. Prior to the development of the ARIA suite, there was no standard way of displaying web pages. Although HTML (Hypertext Mark-up Language) is a standard way of presenting content, it doesn’t actually cover concepts relating to the layout of applications or the web page itself (e.g. trees, the difference between a navigation menu and a list of resources in the content, etc). Therefore, it is difficult for other applications (such as screenreaders) to understand the layout of the page itself.

Most web pages are divided up into separate areas (e.g. navigation, content, banner, etc), but it is not always easy to tell where one area ends and another begins. ARIA, however, allows each area to be labeled as a “landmark” of a particular type (such as navigation, main content area, search, etc) so that other applications know how to interact with different parts of a web page. In a way, it allows web page developers to annotate pages in a standard way, which can then be interpreted by other applications.

ARIA consists of “roles” (“document” or “application”) for each page, with each role containing “attributes” (e.g. “menu item”), which are applied as an HTML tag. Changes in “state” can also be identified, e.g. whether a tree view is open or closed, and “alerts”, such as a change to an advert or a new contribution to an online chat, can be described as important or not important.

Mosen then demonstrated an example of an alpha version of an online player for Radio New Zealand, which includes an ARIA-enabled slide control for the volume (only usable in an ARIA-enabled browser or with other ARIA-enabled software, such as JAWS 10.0) and also allows the user to move forward in the programme.

At present, only the latest version of Firefox 3 supports some of ARIA’s features, although other browsers such as IE8 (Internet Explorer), Opera, and Safari are following suit.

There were some interesting comments and if you don’t get chance to listen to the whole thing, here’s a brief run-down of some of the ideas and issues, which I thought were particularly salient.

* Social networking sites can take the place of face-to-face networking, particularly where the user has motor or visual disabilities. However, many sites often require the user to respond initially to a captcha request, which can be impossible for people with visual or cognitive disabilities.  Some sites do allow people with voice-enabled mobiles to get around the captcha issue, but not everyone has such technology. Once the user has got past such validation, they then have to navigate the content which, being user generated, is unlikely to be accessible.

* One of the panellists felt that people with disabilities did not complain enough about inaccessible websites and that a greater level of user input would help web based content be more accessible.

* Jonathan Chetwynd, who has spoken to the CETIS Accessibility SIG in the past (see Putting the User at the Heart of the W3C Process) stated that users were not involved in the specification and standards process, because it was led by large corporate companies.  He also felt that users with low levels of literacy or technical ability were being overlooked in this process.

* There was some interesting discussion about W3C (World Wide Web Consortium) and the way in which their accessibility guidelines are developed.  Anyone can be involved in the W3C process but as a fee is charged for membership, it is mostly companies, universities, and some not-for-profit organisations who take part.  As some companies don’t want their software to appear as inaccessible, it may be that their motive in joining the W3C is less altruistic.  It was stated that it was actually easier to “fight battles” within the W3C working groups than to take them outside and get a consensus of opinion. As a result, there is not enough engagement outside the W3C working groups which has resulted in a lot of dissatisfaction with the way in which it works. 

* We are now in a post-guideline era, so we need to move away from the guideline and specification approach to an approach which considers the process.  This means taking the audience and their needs into account, assistive technology, etc.  Accessibility is not just about ticking boxes.  The BSI PAS 78 Guide to Good Practice in Commissioning Websites, for example, gives guidance on how to arrive at the process and to ensure that people with disabilities are involved at every stage of the development.  However, developers often want guidelines and specifications to take to people who don’t understand the issues regarding accessibility.

* It is important that everyone is given equivalence of experience so there is a need to separate what is being said and how it needs to be said for the relevant audience.  The web is moving from a page-based to an application-based approach.  One panellist likened Web 2.0 applications to new toys with which developers were playing and experimenting and he felt that this initial sandpit approach would settle down and that accessibility would start to be considered.

* Assistive technology is trying hard to keep up with the changing nature of the web but is not succeeding.  Although many Web 2.0 applications are not made to current developer standards (not the paper kind!), many of the issues are not really developer issues.  For example, multimodal content may have captions embedded as part of the the file or as standalone text, which both browsers and assistive technologies need to know how to access.

* People with disabilities are often expected to be experts in web technology and in their assistive technology but this is often not the case.

After the discussion, the panel members were asked what they felt would advance the cause of web accessibility.  My favourite reply was the one where we all need to consider ourselves as TAB (Temporarily Able Bodied) and then design accordingly.  The rationale behind this was that we will all need some sort of accessibility features at some stage.  So the sooner we start to build them in and become familiar with them, the better it should be for everyone else!