Re: A brief analysis of dynamically generated web pages and accessibility

One issue in generating dynamic pages tailored for the user,
is the ability of the server to have useful information on 
the user's needs.

It seems to me that the current state of HTTP doesn't allow 
to get enough information regarding needs of disabled people.

The mechanisms available now to the server are:
1. The client's "accept" "accept-language" and "accept-charset" request
headers,
2. The client's "user-agent" request header.

The accept-language and accept-charset are the most used by 
clients and servers, but they have no direct relation to accesibility.

The "accept" header may be of some use for accessibility, but if the server
wants to serve only different HTML pages, its use is quite restricted.

The user-agent request header has two problems. One is that using it is not
scalable
from the server's point of view: the server has to study the particular
abilities of 
a growing and diversified set of user agents. The second problem is that
even if the server
recognizes the user agent, this is insufficient to tell what the user
needs: I may very well
want a page crowded with images when I am using Lynx as I have configured
an external image viewer.

Style sheets offer a mechanism to discriminate by "medium". (Either via the
"media" 
attribute of the <link> and <style> HTML elements, or internally in the
stylesheet itself)

However as Scott suggests, sometimes complicated transformations (not
available in CSS
 but possibly available in XSLT) that are taken on the server side are
desireable.

It seems that a possible solution is to have a "user-agent-media" request
HTTP header.
(or "accept-media" ??) As it has a limited set of values it is much more
scalable 
than user-agent, and is a more natural way to apply style sheets on the
server side. 

Seems as an idea that fits the current slogan "CSS on the client and XSLT
on the server."

Regards,
Nir.

At 03:03 PM 11/19/99 -0800, Scott Luebking wrote:
>A dynamic web page is one which is created just before being sent to the
>user.  The server which creates the web page basically gathers
>information from one or more data sources like databases, XML documents,
>real time data suppliers, dynamic data generators, etc; analyzes the
>information as appropriate; decides the format to present the
>information and then creates the web page in the format selected.
>
>A key advantage to this process is that each web page can have such
>aspects like content/information, layout/organization, etc, customized
>or tailored to each user's needs or preferences.  This technology will
>be playing a key role as the web starts developing the more
>personal/individual focus that Bill Gates described in his talk at the
>recent Comdex conference.
>
>The flexibility of generating web pages dynamically can be used to
>benefit blind users to improve their efficiency when using web pages.
>As Len Kasday has written:
>
>    " ... you can get optimal accessibility by generating pages
>    dynamically, tailored to the needs of the particular user "
>
>This optimal accessibility is extremely important to blind users when in
>competitive environments like work or school.
>
>Static web pages, i.e. web pages which are created at an previous time
>and then retrieved from storage when users request the pages, have an
>inherent disadvantage in that it takes much effort to maintain different
>versions of static pages.  When information on one version is changed,
>all the other versions also need to be changed.  Unfortunately, this
>provides opportunity for version skews to develop when accidently the
>changes don't get added to all the versions.
>
>The alternative to providing multiple versions of static pages is to
>have a single static version which can support different types of users.
>This strategy works unless the needs/preferences of the users are in
>conflict with each other.  For example, by the nature of web pages, they
>have what could be called a "visual imperative", that is they often need
>to be visually attractive/interesting and use the functions of vision to
>navigate about the page.  The web page designer usually relies on
>aspects of layout, color, font, images, alignment to address the needs
>arising from the visual imperative.
>
>Unfortunately, some of those those attributes which web page designers
>need to create visually interesting web pages can be in conflict with
>the accessibility needs of the blind web page users.  A significant
>example of this type of problem is the use of tables, especially nested
>tables, when creating visually appealing pages.  Sometimes tables are
>used to create visual symmetry where the left and right columns have a
>similar structure and function while also serving as a frame around the
>middle.  Another example of tables is to create a particular construct
>that is repeatedly used on the page.  The repetition gives visual cuing
>about what the construct would be used for while at the same time
>enhancing the feeling of unity in the design.  (Kind of like
>alliteration in writing with the same sound being used repeatedly.)
>
>When tables are used for layout, they add to the complexity of the
>layout and can be hard for blind users to understand what is being
>displayed in the tables while at the same not being very beneficial to
>blind users.  Blind web page users often prefer a layout which is single
>column with the most important information at the beginning of the page.
>A conflict here is that the extreme simplicity of the layout which is a
>benefit for blind users is often limited in being visually interesting
>and therefore at odds with the visual imperative of web pages.
>
>
>On web pages where there is this type of conflict, decisions need to be
>made.  However, often the decisions are not in favor of accessibility
>for blind users.  The visual imperative is so compelling for a number of
>reasons including business needs, small size of the blind user base,
>etc, that it will be hard for a web page designer to give up what they
>believe is visually appropriate for a web page in order to accomodate
>blind users.
>
>Dynamically generated web pages can help avoid these conflicts which can
>occur in the development of "static" web pages.  When a sighted person
>requests a web pages which is generated dynamically, the server can
>present the information in a format which is very graphically appealing.
>Similarly, if a blind user requests the information, the server can
>present the information in a format which will be more efficient for the
>blind person to use.  As a result, dynamically generated web pages avoid
>the problem of compromising the visual imperative of web pages or the
>accessibility needs of blind users.
>
>
>It is helpful in a dynamically generated web page which is being
>customized for a blind user that the layout take in consideration the
>following:
>
>  1.  a very linear format where information can be in order of
>      importance and grouped by functionality
>
>  2.  Searching in a web page is much slower for blind people than sighted.
>      If the page is new, knowing what to search for is harder.
>      The page should be designed to help minimize the need to search.
>
>  3.  Jumping back and forth on a page is much easier for sighted people
>      than blind people.  The page should be structured to minimize
>      the need for that.
>
>  4.  A sighted person can scan over a page which a blind person can't.
>      It is harder for a blind person to search a page based on concept
>      rather than eaxct words.  If a web page is divided into categories,
>      it is easier for a blind person to decide what to look at.
>
>  5.  Sighted people can often find the end of the form by some
>      visual cuing.  Blind people often assume that encountering
>      a submit button is the end of the form.  This can be in error
>      if there is more than one submit button or if there are more
>      form elements after the submit button.  Blind users can benefit
>      from clear indication about the end of the form being reached.
>
>  6.  A sighted person can quickly skip over a group of radio
>      buttons or identify which radio button is selected.
>      A blind person often prefers a drop-down selection list.
>      It is easier to skip over and the user can quickly identify
>      what the current choice is.
>
>  7.  Decorative images can be left out since they can be distracting
>      to blind users with little useful information.
>
>   8. If the page is from a catalog where description is important, the
>      dynamically generated web page could have a detailed description of
>      the coat instead of an image on pages for sighted people.  The
>      description should be integrated into the text flow for easier reading.
>
>
>However, not only can the format/layout be chosen to be more effective
>for blind users, additional features can be included when the browser
>supports them.  Here are some examples:
>
>
>  1.  Both sighted and blind people need to get a sense of context from
>      each page.  A sighted person can quickly scan to see what the page
>      is about.  A blind person has to grope through the page
>      to get a sense of what is there in order to get a better understanding
>      of the context.  This approach is slow and cumbersome.  Also,
>      a blind person may jump to a conclusion to early.  A blind person
>      can benefit from being able to hit a key and a summary of the page
>      appears in a pop-up box.
>
>  2.  Sighted people can often find links more easily than blind.
>      If a page has some very popular links, it might be easier for blind
>      users to have keys activate the popyular links to reduce the
>      time searching.
>
>  3.  It is often easier for sighted people to find forms on a
>      page than blind people.  Blind users can benefit from having keys
>      which will automatically scroll the page to a particular form.
>
>  4.  While sighted people can quickly skip over links at the top of
>      a page, it is harder for blind people to do that.  An alternative
>      design would be to put groups of links at the bottom and have
>      keys which will scroll the page to the desired group of links.
>      
>  5.  Informational images might be better handled by having alert boxes
>      which have a long description that can be accessed on demand.
>
>
>A question that could be asked is whether these suggestions listed above
>make the web pages easier to navigate.  The best way is to take output
>from a search engine and rewrite it using the suggestions above.  Then
>try using the two versions with a screen reader and see what the
>differences are.  One way to measure efficiency is to count how many
>keystrokes are needed to operate the browser/ screen reader combination
>for each of the versions of web pages.  (Doing a visual comparison of
>the web pages can be informative, but will not show the full impact of
>changes on blind people when using the web pages.)
>
>
>A programmer who has programmed dynamically generated web pages will
>find it fairly easy to program dynamically generated web pages
>customized for blind users.  If existing software is being used, it is
>probably already set up to dynamically generate web pages of different
>types.  The structure of the web pages is usually fairly simple
>consisting of text with form elements sometimes.  Most of the time, the
>programmer doesn't need to worry about such things as colors, fonts,
>images, alignment of parts of the web page, etc.  The simplicity of the
>web page customized for blind users also means that teaching programmers
>what is needed shouldn't be that hard in most situations.
>
>Having dynamically generated web pages customized for blind users will
>ease the burden of the web page designer.  The designer won't have to
>make compromises for accessibility, plus try to write the HTML so that
>the results are accessible.  It might even be a time saver since the web
>pages for blind users are so simple.
>
>
>Instead of the programmer creating alternate formats for blind users,
>some combination of CSS, XSL, XSLT, XPath could be used.  However, since
>dynamic pages are generated to be used once and then discarded, it might
>be easier to just generate the page initially in the desired format.
>This would avoid problems of having to maintain different versions of
>CSS, CSL, XSLT, etc, files.  Also, it avoids problems of differences on
>how developers may have written each tool, e.g. Internet Explorer
>inplementing CSS differently than Netscape Navigator.
>
>
>Why won't screen readers be able to do the same thing?  The answer is
>related to a current core limitation of computers.  (My apologies to the
>non-technical readers.)  Computers have a hard time working with
>concepts, especially given little information from which to extract the
>concepts.  Since computers have a hard time with concepts, they are
>limited in what they can do in determining the purpose or intent of
>something.  This in turn means they have problems grouping things by
>related functions or assigning importance to the functions.  Until this
>kind of problem is solved for computers in general, access technology
>will have the same problems.  Screen readers will have a hard time
>deciding what is the most effient way to present the information since
>it will have a hard time determining what is important.
>
>For example, a web page has 40 links.  Screen readers will have problems
>categorizing the links functions.  The result is that the blind user has
>to slog through the links.  It can be argued that blind users can do
>that, but each time they are confronted with issues like that they will
>be less productive and therefore less desirable in the workplace or less
>competitive in academoic environments.
>
>The issue of the concept-limitation of computers is often a hard one for
>most people to recognize.  This challenge is a key reason why the
>concept of an expert system has migrated more to one of an assist
>system.  Computers are better at searching and conducting comparisons.
>They are not as good at determining what should be searched for or what
>needs to be compared.
>
>I believe that web pages which are customized for blind users can help
>avoid that "concept barrier" which will cause blind people to be less
>productive and less competitive.
> 
===================================
Nir Dagan
Assistant Professor of Economics
Brown University 
Providence, RI
USA

http://www.nirdagan.com
mailto:nir@nirdagan.com
tel:+1-401-863-2145

Received on Friday, 19 November 1999 22:12:23 UTC