- From: phoenixl <phoenixl@sonic.net>
- Date: Sun, 3 Mar 2002 21:22:35 -0800
- To: goliver@accease.com, GV@trace.wisc.edu
- Cc: w3c-wai-gl@w3.org
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