RIAs, information architecture and accessibility

I've been talking to some friends in the RIA (Rich Internet Application) field recently about accessibility issues around Flash-based richly interactive clients.

Flash has had something of a bad name for accessibility (to disabled people) for a long time, but recently Macromedia has added a number of features to the Flash development environment and Flash Player in this department, making it possible for visually-impaired people to access content via screen-reader software, for example (although only on Windows XP, to date...). Steven Webster of iteration::two assures me, also, that Macromedia are taking further steps to enrich Flash's accessibility, which is clearly a positive thing.

I would like to look at this issue from a slightly different angle here, however. It seems to me that if we clearly differentiate the user experience information architecture (which I'll call UEIA for brevity) from the UI-specific implementations of that UEIA, we can subsequently envisage an app that deploys a UI—predicated on the UEIA—tailored to the preferences and requirements of each user not only in terms of interactive modalities (i.e. mouse or screen-reader operated), but also in terms of which discrete facets of the UEIA are made accessible, and whether separately or in combination, via various interactive metaphors.

The UEIA of the app could be defined in an XML document. As well as expressing the options available to the user in each app usage scenario, this document would classify each option according to its sense-specific nature (if applicable): for instance, a content layout option would be tagged "visual", but a multiple-choice menu "informational".

Given such a framework, it would be relatively easy to construct the app so it auto-generated machine-readable image-free html pages as a UI alternative to a Flash-based visually-focused one, with text boxes and links substituting as necessary for visually-specific interactive metaphors in the Flash UI (for which read "drag and drop"). The Flash-based UI would cater for all sighted users, whereas the html UI would be for screen-reader access by non-sighted/sight-impaired users and for spidering by search engine bots.

Let's take an example app where the UI for sighted people allows me (a sighted user) to drag a block of text around within a certain area of the window and drop it in the layout position of my choice—here drag and drop functions as a visual layout tool. However, I may also drag the text block onto a "Favourites" icon to add it to my favourites list—now the same drag and drop has become an information tool.

Because drag and drop is not a binary-state function like a button, nor necessarily tied to a single, discrete data field like a text box or menu item, but more analogue and multi-faceted, it can combine visual layout functionality with information organisation and app control functionality. In our example, two discrete facets of the information architecture of the user experience have become "hard-wired" together in a single UI modality. This is a good thing for sighted users (it's intuitive), but a bummer for a non-sighted or visually-impaired user, who want to be able to access just the aspects of the app that are not exclusively visual.

Now, because our example app gives these users the option of accessing alternative html-based pages tailored to their particular requirements, they can navigate the app content and options relevant to them via a screen reader. So when such a user wished to add the same text block to their favourites, they would choose a "move to favourites" option; the irrelevant "reposition within layout" content layout option, tagged as "visual" in the UEIA schema, would simply not be presented to them.

Perhaps we can have the best of both richly-visual interactive and accessible worlds, after all?