Re: Alternative Interfaces for Accessibility

Hi, Nick

The issue that I wish the article had addressed more clearly is what is
needed in the design of web pages so that blind people aren't penalized
in terms of efficiency, ease of use and accuracy when the use web pages.
One of the executives of Freedom Scientific just made a posting on a mailing
list that it can take 33% longer for him to get his worked done compared to
sighted executives.  Why is that happening?

Does transformation of HTML really provide the most optimal interfaces
for blind users?  I just had a situation where a web page would be
considered accessible by various standards, but a number of screen
reader users had problems because of the way the information was presented
which included various punctuation marks.  Many screen reader users
turn off punctuation pronounciation.  A solution had be be developed
which would present screen reader interpretation lines.  The web site
is at:

    http://members.aol.com/criptrip/command_control


Mark up is unfortunately limited when it comes to rearranging a web page
according to a user's semantic desires, e.g. putting first on the web page
what he/she is most interested in.  Similarly, in the problem just
mentioned, there was no way in HTML to cue sceeen readers that certain lines had
to have all the punctuation pronounced.


I tend to question the limits of automatic transformation.  The
automatic transformation of HTML would not been very useful in address
the problem we had.

I strongly believe that a fair amount of testing needs to be done to
confirm that automatically transforming HTML web pages provide blind
users efficiency, ease of use and accuracy.  Without this type of
testing, the decisions are being based more on wishful thinking rather
than repeatable research results.


My suspicion is that multiple versions based on semantic content rather
than multiple renditions based on HTML will give web pages which are
more efficient for blind users.  However, I'm open to reviewing
any usability testing which indicates the opposite is true.

Scott


> 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 Wednesday, 9 April 2003 14:30:43 UTC