Re: Re : NEW Checkpoint 4.S.1 (taken from S-1. Goes in Section 4. )

Hi,

This semester the computer science department at Berkeley is offering
a graduate seminar on assistive technology.  The students are basically
coming from a more technology background.  A number of  questions
have come up that really show the gap in understanding between the two
worlds.

In the technology world, the assumption that different versions of a web
page are delivered to different people is quite reasonable.  Various
PhD theses nationally are based on this assumption.

Within the disability world, the view of multiple versions of something
is not consistent.  For example, how would someone explain to
a student that multiple versions of a page including braille and audio
are expected while multiple versions of a web page is not acceptable.
It really is a matter of perception.

A number of the points that were brought up in the note are really more
technological.  For example, how does the right group get the right
page?  This is a question of user modelling and how to present the
user modelling in such a way that a lay person can readily identify
what selection to make.  I suspect that there probably doesn't need
to have that many versions provided in order to cover a wide range
of users.  There definitely needs to be more empirical research done
in this area.

One strategy might be to provide a sampler of versions.  So that a person
can see what they like,

The phrase "text only" is probably not that helpful.  I've been toying
around with "generic browser web page" which is kind of awkward.

Another approach might be to have a link to the generic browser web page
and a link to background information on generic browser web page.
(The same approach could also be used for "text-only".)

With regards to 'Link for Blind and Visually Impaired People',
is "Braille format" discriminatory?  It is a matter of perception.

With regards to the google example, there is nothing that prevents
a person from landing on a web page with accessibility problems.
Accessibility is a convention which needs to be adopted.  One
related convention could be that at the top of the page there's a link
to information about alternate formats.


The skills aren't there in many situations for creating accessible web sites.
I think that can be better addressed as there is greater understanding on
what would be needed for different versions.


I believe that again there are tecgnological answers for producing
multiple versions of a web page and keeping them in sync.  I've been
doing some anlalysis of what is basic functionality for a program to do
this and recently posted something on chi-web about this.  I'll
include it later on this note.


I think that there are ways to improve ease of testing.  It is one of the
things I've been looking into.

Scott

-----------------------------------------------------------------------------

NOTES TO CHI-WEB


While looking at basic functionality for dynamically generated pages, I broke it
into various levels.

The first level of functionality I was considering uses strings and string
variables, but no conditional control like "IF".  This is probably the
most basic level of abstraction and probably requires the most minimal amount
of abstraction that a web page developer will need to be able to manage.
(There are probably some developers who may not be able to look at web pages
from this approach though.  They may not see the benefit.)

Two key functions at this level would be setting and referencing string
variables.  String variables could be specified in a tag like:

    <DP :help_label="Assistance"  :table_background="green" >

where a ":" is used to indicate that a variable is being set.  The string
variable can then referenced later in the file by being surrounded by
symbol indicators '<<' and '>>' , e.g.:

    <A HREF="help.html" > <<help_label>> </A>

    <TABLE BGCOLOR="<<table_background>>" >

A simple string replacement is used where ever pairs of '<<' and '>>' are
found whether between tags or in tags.  (If '<<' or '>>' is needed for
another purpose, the web page developer could write <\< or >\> which
would be replaced by '<<' and '>>' respectively.)


A web page developer may want to store a string with multiple lines
in a string variable.  A way to do this could be:

    <DPC SAVE=special_announcement >
    <STRONG>
    Reminder  -  applications to become a millionaire need to be turned
    in today to human resources so they can plan accordingly.
    </STRONG>
    </DPC>

and the string variable could be referenced as:

    <BODY>

    <<special_announcement>>


Besides, the setting and referencing string variables, I believe that
another functionality at this level is reading a file:

    <DP FILE="shared_variables" >
    <DP FILE="standard_page_bottom" >

The file could contain text to be included at that point or tags for setting
string variables, reading files, etc., or both.

The file name can be specified in a string variable, e.g.:

    <DP :page_bottom_file="standard_page_bottom" >
       .
       .
       .
    <DP FILE=page_bottom_file >

(Note that the '<<' and '>>' aren't needed because the tag knows that
a string variable can be used with the FILE attribute.)


A related functionality is the "FILES" functionality.

    <DP FILES="company/section/department/set_variables" >

The program starts at the top directory specified, in this case 'company',
and reads the file indidicated 'set_variables'.  It then moves to the
subdirectory indicated, 'section' in this case, and reads the 'set_variables'
file in that directory if any.  It continues down the path until the last
subdirectory in the path is reached.  The advantage of this functionality
is that variables can be over-ridden at various levels, i.e. a string
variable set by a file in a directory higher in the path can be re-set
by a file in a sub-directory lower in the filepath.

Sometimes, not all the sub-directories at the beginning of a path need to
be searched.  For example:

    <DP FILES="/usr/standard_files,  company/section/department/set_variables" >

specifies a root for the files, in this case '/usr/standard_files' .
The first directory that the file 'set_variables' is looked for is
'/usr/standard_files/company'.



I think another basic functionality is macros.  A very simple version
for standardizing check boxes on a web page could be:

    <macrodef macroname=cb>
      <input type="checkbox" name="##name##" value="##value##"> <STRONG> ##value## </STRONG>
    </macrodef>

    <macro macroname=cb name="car_use" value="travel">
    <macro macroname=cb name="car_use" value="business">
    <macro macroname=cb name="car_use" value="local">

(The abstraction might be a little challenging for some web page developers.
Others will probably be able to learn the concept pretty quickly.)


The last basic functionality I think needs to be provided is the ability
to get a value from a page request.  Suppose that the program and the web page
server are configured to extract values from a URL (but not the QUERY
part).  For example:

    http://www.acompany.com/product/l:english/chairs.cfg

If the web page developer could use functionality getPageRequestValue
like:

    <DP :language=getPageRequestValue("l") >

the web page developer could then configure the page like:

    <DP FILE=language >

by reading in the file for the specified language.


So, I think the functionality for the very basic level should include:

    ability to set a string variable in a tag using the ":" or an equivalent notation

    ability to set a variable to contents of a container via the SAVE attribute
       or an equivalent

    ability to replace a reference indicated by '<<' and '>>' with the string
       in the variable specified or equivalent notation

    ability to read a file with the FILE attribute or an equivalent

    ability to read files along a file path using the FILES attribute or an
        equivalent

    ability to define and use basic macros

    ability to get a value from a web page request


While the functionality is quite small in number, I think it can be useful
for a number of types of web pages.  The functionality supports a wide
range of support for "nip and tucking".

-----------------------------------------------------------------------


I think the next level of functionality expands the previous level
by adding boolean variables and IF statements.

As standard, boolean variables can only be set to true or false.  For example,

    <DP  :include_directions=true  :dual_column=false >

The boolean variables can also be set functionality similar to
'getPageRequestValue'.  This functionality is called 'isPageRequestValue'
and tells if some value is set in the page request.  For example,
in:

    http://www.acompany.com/product/manager,l:english/chairs.cfg

the 'manager' value is set.  The web page developer could then write
a tag like:

    <DP :manager_mode=isPageRequestValue("manager") >


The boolean variables can be referenced by IF and IFNOT attributes.
For example,

    <DP IF=manager_mode :table_background="yellow" >

    <DP IFNOT=manager_mode FILE="standard_employee" >

    <DPC IF=manager_mode SAVE=special_announcement>
      <STRONG>
      Reminder upper management meets every ...
      </STRONG>
    </DPC>


The IF and IFNOT attributes can control if text will be included in the page.
For a single string of text, IF or IFNOT can be used with the STRING attribute.
For example:

    <DP IF=customer STRING="<STRONG>Check with your sales representative for special discount</STRONG>">


For a block of text, IF or IFNOT can be used with a container.  For example:

    <DPC IF=member >
      <A HREF="renew.html> Renew </A>
      <A HREF="refer.html> Refer </A>
      <A HREF="donate.html> Donate </A>
    </DPC>


If the web page designer wants to append a text to a string variable
under certain conditions, the designer can use IF or IFNOT with the APPEND
attribute to append text.  For example,

    <DPC IF=visitor STRING=" ... some info  ..." APPEND=some_variable >

    <DPC IF=staff APPEND=special_announcement >
       .
       .
       .
    </DPC>


The additional functionality for this level is:

    ability to set a boolean variable in a tag using the ":" or an equivalent notation

    ability to reference a boolean variable by an IF or IFNOT attribute
       or equivalents

    ability to determine if a value is specified in a web page request

    ability include a string specified by STRING attribute or equivalent

    ability to append the contents of a container to a string variable
       via the APPEND attribute or an equivalent


The introduction of boolean variables and the IF and IFNOT attributes
significantly expand the abilities of the web page designer.  For
example, suppose that a web page changes only once in a while.  The web
page designer could store all the information in one file and edit by hand
to reconfigure the page as appropriate, e.g.:

    <dp :summer_motif=true >


The web page developer could also do rapid prototyping and demonstrating
by manipulating the URL:

    http://www.acompany.com/product/manager,demo1/chairs.cfg


where the file has tags like:

    <dp :demo1=isPageRequestValue("demo1") >

    <dpc IF=demo1 >
       <dp :summer_motif=false >
          .
          .
          .
    </dpc >


-----------------------------------------------------------------------

The next level of functionality is probably being able to use string
and boolean expressions.  Some web page developers may not be
comfortable with expressions.  Some web page developers may not be able
to grasp the difference between a string and an expression.

As a quick example suppose that files for various languages are kept in
a sub-directory called 'languages'.  The demonstration of the
getPageRequestValue functionality could be rewritten as:

    <DP :language=getPageRequestValue("l")
        :language_file=` "languages/" + language ` >
       .
       .
       .
    <DP FILE=language_file >

The string for variable language_file is created according to an expression.
The backquote (`) is used to indicate an expression rather than a string.
The '+' means to concatenate.

An IF or IFNOT attribute could use an expression like:

    <DP IF=` background == "" `      :background="yellow" >

For C fans, another way to do this is:

    <DP :background=` (background == "") ? "yellow" : background ` >



----------------------------------------------------------------------------

Just a few thoughts.  Would love to hear any feedback.

Scott



> I don't like the idea of different versions for
> different groups for the following reasons
> 
> 1. Resource Discovery
> How do we ensure that the 'right group' gets to the
> 'right version'?
> If there are links from the default rendering what are
> they going to say?
> 
> 'Link to Text Only Version?'
> Well, how do I know if I am 'supposed' to use the text
> only version?
> 
> 'Link for Blind and Visually Impaired People?'
> This doesn't do it for me, it sounds discriminatory.
> Also see 5.
> 
> What's to stop people landing (on a search from Google
> for example) on the 'wrong' version. What do they do
> then? How do they know they are on the 'wrong' version?
> 
> 
> 2. The skills aren't there
> In my experience so far, there simply is not the
> awareness of what the needs are of different 'groups of
> disabled people', to create an accessible site for a
> specific group.
> The process of producing two or more version will be
> expensive enough without all the potential rework to
> fix up stuff.
> 
> 
> 3. More than one verion means less testing and lower
> quality.
> This has been my experience so far. Site quality is
> lower, resouces get stretched, stuff gets missed.
> 
> 4. No site will ever be fully accessible.
> There seems to be inherent in this argument somewhere
> that we can make a site 100% accessible.
> I think that it is helpful to look at the bricks and
> mortar world in this regard. In NZ anyway an accessible
> door (in the regulations) has a handle on it which can
> be opened by 'most' disabled people.
> A 100% accessible door would be one of these Star Trek
> things that simply opened automatically (optional swish
> swish sound) but they are not specified in the
> regulations (they are too expensive).
> These regulation were pioneered by disabled people. A
> pragmatic ('non 100%') response to a real world problem.
> 
> 
> 5. Disabled People want the same solution as everyone
> else.
> OK, so I only have a small sample size, but that's the
> message I get.
> 
> In short I believe that accessible design is universal
> design.
> 
> Regards
> Graham

Received on Monday, 4 March 2002 01:49:40 UTC