Re: Alternative Interfaces for Accessibility

On Mon, 7 Apr 2003, phoenixl wrote:

> This is a recent article on Jakob Nielsen's web site.

A good one:-)

> http://www.useit.com/alertbox/20030407.html
> 
> Jakob Nielsen's Alertbox, April 7, 2003:
> 
> Alternative Interfaces for Accessibility
> 
> Summary:  The key difference between user interfaces for sighted users
> and blind users is not that between graphics and text; it's the
> difference between 2-D and 1-D. Optimal usability for users with
> disabilities requires new approaches and new user interfaces.

That is precisely the underlying principle of mod_accessibility:
to help overcome the difficulties of linear presentation by offering
users a choice of views and overviews.

> The typical advice for making websites accessible is to create a single
> design for all users, then ensure that it complies with additional
> guidelines for use by people with disabilities. This is also the
> approach we take in our own guidelines for accessibility: They aim at
> improving usability for users with disabilities by tweaking traditional
> websites and intranets to take special needs into account.

Agreed; that's the basic principle.  It's good advice because it's
the level of accessibility that's built in to HTML from the beginning,
and so works naturally on the Web, except when it's subverted by
ignorance and defective tools.


> The main reason for this single-design-for-multiple-audiences approach
> is the assumption that most companies are unable to keep two different
> designs up-to-date. Thus, if they optimized a separate design for users
> with disabilities, they'd risk it rapidly becoming out of synch with the
> "main" website.

That's fair comment up to a point, but I'd take issue with describing
it as the "main reason".

> For most websites, this assumption is probably true. The average company
> allocates very limited resources to serving users with disabilities, so
> their best approach is to use these resources to improve the main
> design, rather than to design, implement, and maintain a separate site.

Again, I'd take issue with that.  Markup does not *inherently* have
any dimensionality.  Good markup contains the information it seeks to
convey *and* describes structural relationships between different
things in a document, and can therefore be rendered in any number of
dimensions.  This is really an instance of what accessibility guidelines
refer to as being device independent.

The limitation of my argument - and the justification for Nielsen's -
arises where the *principles* of good markup are compromised.  This
may be for good reasons - to work well with the capabilities of available
browser technolgies, but more often happens for bad reasons, based on
the fallacy of markup as DTP.

An example of a Good Reason (in my argument) is the classic navigation
bar.  In principle it is wrong, because navbars should use the HTML
LINK element in the HEAD.  In practice it is a necessary compromise
due to the failure of popular browsers to support LINK.  This presents
a problem in one dimension, and leads to the uneasy compromise of the
"skip navigation" link as an accessibility aid.

> However, perfect usability for users with disabilities requires separate
> designs optimized for each of the main access modalities. An interface
> for blind users, for example, should be designed for auditory
> presentation. Such a design is inevitably better than simply reading out
> loud something designed for screen-based visual presentation, even if
> that presentation is modified to take blind users into account. Of
> course, in an ideal world, separate and equally targeted designs would
> also be available for low-vision users, users with motor skills
> challenges, and so on.

Multiple presentations is of course one of the Big Promises of XML,
and has been with us for many years in SGML.  It works.  Markup offers
a far more powerful solution than Nielsen admits.  The problems he
describes are down to shortcomings in implementations (browsers and
authoring/publishing tools), not the underlying medium.

> Optimize for Linear Access
> 
> The biggest potential gains reside in creating a special design
> optimized for auditory presentation. A good 1-D audio design not only
> serves blind and low-vision users, but will also help users in cars and
> other settings as auditory access to Internet content increases.
> There's a fundamental difference between visual and auditory
> presentations in terms of dimensionality: screens are 2-D and depend on
> layout for presentation, and audio is 1-D and relies on sequence for
> presentation. Linearizing a 2-D layout is simply not as usable as having
> a good designer create a targeted 1-D layout.
> 
> In a 2-D layout, a good graphic designer organizes blocks of information
> to provide a visual of the website's structure and to prioritize the
> most important tasks by their relative size and 2-D location. For
> example, designers typically place the most important Web page elements
> in the center of the top screenfull, since that's where sighted users
> tend to look first. Although a targeted 1-D audio presentation should
> start with the most important information, most audio translations
> simply read a 2-D page aloud, starting at the top left, which mainly
> contains information that sighted users typically skip. Also, simply
> reading aloud eliminates size distinctions, which are key elements in
> 2-D designs.

Here Nielsen appears to be falling somewhat into the doctrine of DTP.
The tool of the good graphics designer is a presentation kit that
describes how the document contents will be rendered on a particular
device, typically a visual browser.  This is not just the classic HTML+CSS
distinction; it can equally (and more powerfully) describe XML+XSLT+CSS,
SQL+PHP+CSS, and a host of such publishing systems.

The graphic designer should have *read-only access* to the structure!
Of course in practice the same individual will work on both HTML and CSS,
but they should cast away all thoughts of graphic design whilst dealing
with the HTML.  A decent publishing system would enforce that.

> The fundamental difference between user interfaces for sighted users and
> blind users is thus not the distinction between graphics and text, but
> that between 2-D and 1-D. Unfortunately, we don't know much about good
> 1-D layout for interaction design (we know how to produce good radio
> shows, but they are not interactive forms of audio content). However,
> it's quite likely that an optimal linearized presentation would make
> more use of hypertext than we find in 2-D layouts that benefit from
> visual scannability. Thus, a design for auditory use might end up being
> more N-dimensional than purely 1-dimensional.

Increasing dimensionality is what hypertext gives us.  Harnessing this
for the benefit of blind users seems to me a perfectly feasible goal.
But it doesn't have to be a matter of design at all: it can be
automated by technology.

The different Views offered by mod_accessibility are my best attempt at
this to date.  By purely mechanical means, it works around many of the
problems with 1-d presentation on the Web.  For example, the structural
overview of a page enables the user of a speech device to skip over
tedious navigation bars/logos/etc to the main contents without faffing
about with ad-hoc "skip navigation" links, and extends the capability
further to enable easy navigation of long and complex pages.

> Blind users might also benefit more from a 3-D user interface than
> sighted users. I imagine a gestural interface, where users are
> surrounded by different types of information located at different spots.
> They'd access this information by poking at points in space. Thus,
> designers could "park" search results and other key pieces of
> information in particular locations, where users could retrieve them
> with a gesture. For sighted users, such an interface would be useless:
> There would be no words floating in space -- unless they used a clumsy
> VR helmet. For blind users, however, gestures and unseen (but easily
> remembered) 3-D locations might beat linear read-outs.

That seems an interesting idea for a radically new web browser.
Anyone got a development budget?

> Expanded Possibilities
> 
> Just as optimal 1-D design benefits sighted users needing hands-free
> content access, so, too can designs for users with other disabilities
> expand other users' options. Users with low vision, for example, can
> only see small amounts of information at any given time. Optimizing the
> design to suit their needs also benefits users of mobile devices or
> other small-screen devices, who essentially have the same limitations.
> Regardless of the targeted user group, all designs must offer the same
> functionality and provide access to the same content. A good content
> management system will be necessary to ensure that all versions are kept
> in synch and no one misses out on updates.

All the good content management system needs to do is to ensure the
contents are there, and properly described by the structure.  It should
deal with multiple renditions, not multiple versions.  In practice - 
though not necessarily in principle - that means the "master" contents
being held in some more flexible manner than HTML.  SQL is probably
the easiest, and of course XML offers the promise if we can improve
the tools for mamaging it.

> Of course, the approach I advocate here is overly Utopian. I doubt at
> present that companies will spend enough money on users with
> disabilities to create sufficiently good alternative designs --
> especially when such designs will require a completely new set of
> usability guidelines. However, the future is more promising: Once
> auditory access to Internet content becomes more mainstream, I expect
> that resources to create optimal audio designs will be more readily
> available.

Aural CSS already exists - what more do you want? :-)

Seriously though - once we have devices that support aural CSS, and have
learned and dealt with(!) its shortcomings, we'll have solved that one.
Provided we're not still abusing poor old HTML.

-- 
Nick Kew

Received on Tuesday, 8 April 2003 04:57:56 UTC