Re: A brief analysis of dynamically generated web pages and accessibility and why a programmer might want to use XSLT, XSL, etc.

Scott,

In your previous post you suggested that a programmer who had created a 
dynamic page could more easily write a new subroutine than "dealing with 
postprocessors."  Your main concern was that if the data changed, then 
someone would have to go change the postprocessor.

If the data and structure of the page is appropriately separated from the 
presentation, then changes to data can happen independently from changes in 
presentation.

In your second post you used the example of a Table as a reason for why 
someone would want to use dynamically generated pages. There are quite a 
few ways to address this issue either on the client- or the 
server-side.  It will depend on how the data or content of the page is 
marked up, but a client-side tool could more effectively allow the user to 
interact with the data than a static presentation generated then served 
(i.e., querying a cell for information about its header(s) or table for a 
collection of cells).

There are also several client-side generated schemes that work well.  I 
have been working on a client-side script that uses style sheets to show 
and hide information in a dynamic way that also works when scripts or style 
sheets are not loaded.  It is dynamic presentation of content, but because 
of style sheets and scripting, it can either linearize into a table of 
contents and text, or be displayed with a "visual imperative."  I have 
chosen a blue horizontal menu bar, with orange submenus that pop up, and 
other text that is shown depending on which submenu is selected.  in other 
words, it transforms gracefully because content is separate from presentation.

I am anxious to investigate how I might use a combination of XML, RDF, and 
scripting.  Especially with data tables.


You are advocating server-side scripting.  As long as the content is 
separate from the structure, and the nature of the content is static, I 
don't think it depends where the generation (or transformation) happens - 
on the client, the server, or some gateway. Until user agents all support 
scripting consistently and adopt a common object model, some of that 
generation will more reliably happen on a server, but in the future it's 
really not going to matter where the presentation comes from: a subroutine, 
a style sheet, it happens on the fly as the user agent interprets meta 
information, etc.  It will depend on what you are doing and what is most 
effective.

therefore, your suggestion (if I understand it correctly) follows along 
quite nicely with the themes of WCAG: graceful transformation and 
separation of content from structure.  You are more than welcome to develop 
server-side strategies for inclusion in the techniques document.  We are in 
the process of restructuring it and adding new techniques before the end of 
the charter (30 Nov), so now is a good time to get something 
included.  Particularly, if you have examples for the checkpoints that 
specifically mention scripting.

thanks,
--wendy


At 06:03 PM 11/19/99 , you 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.

<>
wendy a chisholm (wac)
world wide web consortium (w3c)
web accessibility initiative (wai)
madison, wisconsin (madcity, wi)
united states of america (usa)
tel: +1 608 663 6346
</>

Received on Friday, 19 November 1999 19:51:24 UTC