- From: phoenixl <phoenixl@sonic.net>
- Date: Wed, 9 Apr 2003 11:30:41 -0700
- To: w3c-wai-ig@w3.org
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