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

RE: A single URI

From: Scott Luebking <phoenixl@sonic.net>
Date: Wed, 19 Dec 2001 14:46:45 -0800
Message-Id: <200112192246.fBJMkjLi030055@newbolt.sonic.net>
To: asgilman@iamdigex.net, w3c-wai-gl@w3.org
Cc: phoenixl@sonic.net

I thought also that it meant the exact same URI and was guessing that
the linking meant some redirection or something.  I think that Al is
correct that the consensus item could benefit from some work.  Perhaps
including a couple of examples could help.  For example,
http://www.someplace.org/newsletter.html gets a regular version while
http://www.someplace.org/alternate/newsletter.html gets the alternate

While cookies and content negotiation can be helpful, they require the
web site developers to have some advanced technical skills.  If various
URI's are allowed, that would be helpful.

I agree that the parallel sites need to overcome the distrust from the
past.  However, I think it means that the right technology and tools for
supporting multiple versions of a web site need to be developed.

The reason I suggested that this was a paradigm shift was that early
last year and other times when Kynn or I brought up the possibility of
multiple versions of a page, there was some extremely strongly held
positions on the "one size fits all" approach.


> At 09:50 PM 2001-12-18 , Cynthia Shelly wrote:
> >Not a consensus, just my opinion....
> >
> >One way would be to detect that the user can't accept cookies (not
> >hard), and in that case send a page that links to all the different
> >renderings.  The user could then click the appropriate link and see the
> >one they want.  
> >
> AG:: 
> The last time this came around was at
> <http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/thread.html#1042>
> http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/thread.html#1042
> [The fact that it came back suggests we need something more in the appendix: a
> note and/or a link to this discussion, anyhow more than a parenthetical
> aside.]
> Note that the site could serve the page with hyperlinks as the first page,
> without sensing noCookies first, and still be in compliance.  "Through the
> same
> URI" does not mean "as transparent alternative realizations of one and the
> self-same URI-named resource."  It just means that by starting at the 'one
> URI'
> you can get there accessibly and expeditiously, although the way to get there
> may include following hyperlinks.  
> Or at least that interpretation passed by without opposing argument the last
> time.  There was no official record of consensus about this as clarifying the
> 'consensus item' so far as I know.
> PF went on to advise the Device Independence Working Group that
> <quote 
> cite="http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html">
> - Hyperlinking is an acceptable means of relating alternative options.
> Coverage of user requirements may be by the envelope of the capabilities of
> the alternatives in this case.  [...]
> </quote>
> Having the user chose among user-visible options is a more stable method of
> controlling server-side options than asking the user to make more abstract
> choices by indicating 'preferences'.  See the Telecomm strategies for reducing
> cognitive barriers, quoted at
>  http://lists.w3.org/Archives/Public/w3c-wai-gl/2000AprJun/0313.html
> Parallel sites still have to overcome mistrust based on past bad performance. 
> The /access option at Amazon does not appear to be full-function.  I tried to
> use it for my Christmas shopping and gave up and went back to the main site.  
> But the people at Tesco would seem to have done it right.  At least they have
> the support of RNIB for what they did. 
> <http://<http://www.tesco.com/>www.tesco.com/access/default.asp>
> It's not so much a paradigm shift as an explicit nod to the long-standing
> notion of equivalent facilitation, and the growing server-side capacity to
> deliver the same.  [But it had better be good.]
> Al
Received on Wednesday, 19 December 2001 17:46:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:39 UTC