W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2001

A paradigm shift (was FWD: CHI-WEB: Amazon's version for the Visually Impaired

From: Scott Luebking <phoenixl@sonic.net>
Date: Mon, 17 Dec 2001 09:51:38 -0800
Message-Id: <200112171751.fBHHpc6i018584@newbolt.sonic.net>
To: w3c-wai-ig@w3.org

The consensus item:

     S1 - serving content in different forms is an acceptable way to comply
     with the guidelines as long as equivalents for all of the information
     are provided in the different forms and it is all available through the
     same URI (though it may be linked to it) (server side solutions are
     acceptable - as specified)

is a paradigm shift with some interesting aspects and ramifications.

For example, users of the guidelines will want to know what is needed
for a web page which will primarily be used by blind people.  Web pages
whose audience will be blind people are actually quite easy to format.
One general overall layout could be linear with some introductory
information at the top, followed by a document index which starts with a
skip link, followed by significant elements in order of importance.
There probably needs to be some usability testing on possible formats
to recommend in guidelines.

If a separate version is provided without all the flashy items which
makes use of web pages harder by blind users, this could simplify the
demands on browsers for handling accessibility issues.

The burden would then move more to authoring tools to produce multiple
versions of web pages.  However, it might in a way actually simplify the
task of authoring tools.  An authoring tool could keep track of
significant elements in a web page and could check that the same
elements are in the blind version.  Or the authoring tool could generate
a web page with additional information stored in comments about how the
web page should be generated by a server for blind users.

A slight more complicated approach would be to use self-configuring web
pages using configuring statements, macros, symbols, etc.

A more complicated approach could be using XML for situations where the
content of various documents have a similarity.

I believe the correct tools to produce multiple versions of web pages
would improve efficiency.  For one version of web page, developers can
go crazy and not have the additional work of making sure that
accessibility requirements are being met.  In another version, the
design will be simpler which means that there can be more focus on

Another that efficiency could be improved is that the simpler version
could have its accessibility checked more easily.


> Hi
> Looking at the further discussion, I have some revised thoughts.
>       Speaking for myself only, the ends are more important than the means.
> Therefore, from my pperspective, if the means to provide increased accessibility (and usability) to a wider range of users is by creating multiple versions (at the site or page or page element level) on the fly, then
> that is perfectly fine.  It's hard to say, in the general case, if there is such a thing, how practical this is.  
> As long as 
> 1. equivalent information is provided via all the different versions 
> and 
> 2. all the versions are kept equally up to date, 
> then the end is achieved.
> The phrase "universal design" to me simply means to take different groups into account.  It seems to me that both Scott's design outline and that expressed in WCAG are both 
> "universal design" and the differences is at
> the implementation of the design.  I hope I'm not muddling up the distinction, I'm just trying to see where precisely we disagree, if we really do disagree.
> For example, Scott's step 4
>     4.  for each group of users, identify approaches which can be
>         used by users in the group to meet their needs given their
> 	characteristics.  (here's where the creativity in pushing bounds
> 	and coming up with original solutions can come into play)
> iterates over "groups of users" whereas that expressed in WCAG seems to iterate over something like "information chunk" which mostly corresponds to "page element" as opposed to entire page or site.
> (e.g. For each element, provide an equivalent...)
> Could this difference in the early design phase account for the difference?  Am I making any sense?
> Steve
Received on Monday, 17 December 2001 12:51:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:15 UTC