A Proposal from the Disabled Access Community

Introduction

I am new to this list, and infact, I am only here by accident.  I 
had attempted to subscribe to the www-amaya list in order to be informed 
of  its port to PC/Win.  I stayed because I liked the discussions.  I 
have noticed that the topics don't stay completely on HTML, they tend
to wander a little if the discussion warrents it.  I am also on another
list called dev-access, which deals with accessiblility in general and 
access to developer envirements in particular.  One of the posters has a 
question  he would like posed to those that have a say in how documents
on the www are treated by User Agents.  If anyone knows of a different
forum this could be broached on, please let me know.

This is his premise:
For the last few years I have been active assisting users of the Lynx 
World-Wide Web browser. Some of these users are blind and use speech 
output in lieu of video display screens in their dialog with computers 
and the Web.  Since Lynx is optimized for text-only browsing of the Web, 
it has developed a following of devoted users among the speech-interface
user community. Based on this contact I have developed an interest in 
access adaptability for the World Wide Web. This is a natural extension 
of long-term interests that you might summarize as modeling classes of 
knowledge. 

Proposal

In two companion [messages], I summarize two change notions for the 
basic operation of the World Wide Web.  These are inspired by the 
difficulties that I observe Lynx users [are] having with the way the Web 
works today.  Perhaps better solutions can be found.  But based on my 
experience to date, these look like they would be a win for the blind 
Web browsing community, and very lightweight in their cost to the rest 
of the Web world. 

One of these dodges I have wanted from long ago and just recently 
realized that the blind need it more than anyone.  That is a  
"where-it-says" clause in an URL that triggers text-searching in the 
client that exercises the URL.  In other words citations would not be 
limited to anchors named by the author, but an URL could go precisely 
to a location defined in the cited document by a third party. This is a 
way of formalizing in an URL what the folks on lynx-learners use as 
their standard form of citation. 

The basic idea is for a citation creator to be able to embed a text
string in an URL.  The URL with this string in it is intended as a
localized reference to the first occurrence of that string in the
document which can be retrieved using the remainder of the URL. 
Searching for that string localizes the reference within the document
retrieved.  FTP and HTTP servers would ignore this string, but client
programs would search for the string and locate their presentation
around the location-in-document so found before presenting the document
to the user. 

This requires a standard mechanism because the citation creator needs to
be able to communicate the reference to other people in a way that is 
independent of their choice of client software.  One rough idea of a 
possible implementation is as a search-part parameter name
"where-it-says" such that an example URL would be:

scheme://path.to.server/path/to/file.typ?where-it-says=I%20told%20you%20so 

Current usage is that search-part parameter names are not standardized,
but defined by servers.  In this case that would not be good, as the
implementation of the searching is distributed over a varigated lot of
client programs.  Before this implementation is selected, one would have
to examine possible interactions with other uses of this syntax. 


Rationale

Plain-text resources:
Many of the currently Web-fetchable resources that are the most use in a 
speech-output environment are plain text files.  People writing for
paper 
write with a prosody closer to oral prosody than those who currently 
write documents specifically for the World Wide Web. The latter user
more the prosody of a highway billboard. 

However, these documents can get large and speech access is slow.  For
these reasons, it is particularly valuable to be able to forward a
reader to a specific point in the document. Hence the frequent use of 
"Search with '/' for..." in discussions on lynx-learners. 

Named anchors -- mostly missing or misplaced:
For documents written as HTML, one has the capability to localize a 
reference by placing named anchors in the document.  However, the 
practice in this regard is very uneven.  Particlarly for the speech
user, the start-points created by these anchors are mis-located relative
to natural starting places for aural browsing. 

Empowering readers:
This may be a subtle point, but permitting third parties to define
reference points in Web pages has the effect of flattening the texture
of the Web, making it more democratic and a better medium for
collaborative problem-solving.  The first writer of a page is not the
only one that can define focal points.  A community of the readers of a
page can converge on their own definition of critical points within the
document without having to edit what the originating author wrote. 

In the particular case of speech users, it empowers the speech user
community to solve their own peculiar problems by developing a light,
adaptation layer over speech-insensitive resources that makes the
resources effectively more speech-friendly.  To make this serve the 
speech community as efficiently as the rest of the Web infrastructure
supports the background population, it must be possible to
institutionalize the speech-adaptive reference points in Web documents. 
In this line of thought, I am very much influenced by the good work of
Gregory Rosmaita in providing a speech-adapted interfaces to search
engines by means of a layer of HTML pages. 
******

This is the end of his first proposition, I request discussion on the 
feasibility of implimenting this in the developement of HTML and UA's, 
and welcome questions for clarification.  I will present the second 
proposition after the first one has run its course.

Regards,
        James
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
James Alan Shattuck                     mailto:progman@ecst.csuchico.edu
Shattuck Consulting, Chico, Ca.    http://www.ecst.csuchico.edu/~progman
System Design/Installation      Repairs/Upgrades        Web Design
Business/Personal               Training                Disabled Access
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Born: 9/3/63, Adopted: 7/71 as Anthony Douglas, San Francisco, Ca
Searching for Birth Family
Adoption Page:  http://www.ecst.csuchico.edu/~progman/adoption/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Received on Thursday, 17 April 1997 21:55:22 UTC