URI appearance is not a CHIP issue - agreed

At 12:07 AM 2003-01-29, Alex Rousskov wrote:
>Al,
>
>         I agree with your points, but I think you missed mine. I was
>trying to say that, for many years now, it does not matter much how
>URIs look. We should not spend time discussing or documenting their
>looks. That does not mean that access to "raw" URIs should disappear
>from user agent interfaces. That access is essential and should stay
>(for the reasons you mentioned). That access does not imply we should
>care how URIs look though.

OK, good.  What your Subject line appears to say is not what you meant.

What you did mean to say, I can't really discuss because you gave no
specific reference into the document.

However, it is generally good to avoid making value statements about
off-topic subjects.

Webmasters should care, to a limited degree, as to how everything on their site
looks.  The CVS update-codes on W3C pages detract from the effectiveness of the
site by their human-unfriendly presentation.

But how the "raw" URIs appear is not an HTTP Implementation matter, period.

Access for low-vision users to all content does depend on how the content 
looks.
But the extent of W3C pronouncements on this subject has been limited to saying
that how it looks should be under the user's control, independently from the
resource representation that left the server (passed through HTTP).

  http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-styles
  http://www.w3.org/TR/WCAG10/#gl-structure-presentation

This supports your point that how the URI looks in the presentation is a 
concern
that should be separated from the HTTP implementation concerns.

Saying "it doesn't matter how the 'raw' URIs look" passes the 80% test but
flunks the standard for W3C pronouncements, and the standard for quality
programs anywhere.  This document, however, is not the place to discuss pros
and cons of how URIs look in web content.

On the other hand, Quality Assurance for W3C has to be Very Clear that "the
80% rule" Does Not Apply to W3C work.

Al

PS:

For the collegiality of our consensus methods, it is important to include a
specific reference (at least one) into the subject document to set the context
for any comment.

Likewise, this misunderstanding demonstrates the importance of writing 
effective
Subject: lines in W3C work.  The Subject: header of email messages comes under
heavy performance pressure in a listserv-driven organization such as W3C.  For
maximum performance, speak simply and directly to the point in email Subject:
lines.  Do not indulge in coy neo-colloquialisms.

[I can thump this participation guideline because violating it is one of my
most frequent sins.]



>Alex.
>
>
>On Tue, 28 Jan 2003, Al Gilman wrote:
>
> >
> > At 04:40 PM 2003-01-28, you wrote:
> >
> > >On Tue, 28 Jan 2003, Karl Dubost wrote:
> > >
> > > > QA Activity has published two W3C Notes: CHIPs and CUAP
> > >
> > >There are several CHIPs checkpoints that talk about visual formatting
> > >of URIs. It surprises me that QA WG (or anybody) still cares how URIs
> > >look. The whole "use meaningless but easy to remember URIs" rhetoric
> > >seems to lack real-world foundation.
> > >
> > >While cool URIs may not change, cool interfaces do not force users to
> > >type URIs and, hence, it is not that important how those URIs "look".
> > >Cool interfaces use other means like page titles and links to present
> > >resource pointers to users, and computers do not care how URIs look as
> > >long as the URI "works". Document <title>s are for humans, URIs are
> > >for computers.
> > >
> > >With the exception of domain names (which are not even URIs), how many
> > >users still have to type URIs by hand? Bookmarks and links of various
> > >kinds make that awkward and unnecessary. Moreover, isn't it a
> > >violation of Web Accessibility guidelines to talk about specific
> > >visual appearance of URIs without talking about how URIs should sound,
> > >for example?
> > >
> > >Without much hope, I would suggest that arbitrary requirements related
> > >to URIs "look" are removed.
> >
> > It is true that for screen reader friendliness, one should not use the URI
> > as link text but rather put a natural language title for the cited
> > reference in the link text and expose the URI-reference in visible text
> > somewhere unlinked but nearby.
> >
> > But don't hide the URI, either.  This is a genuine conflict between user
> > groups.  Lots of users understand what is going on better if the link is
> > from the URI-reference text.
> >
> > What is easy should be easy (activate a hyperlink) but what is hard should
> > be possible (cut, edit and paste or even type in a URI-reference).
> >
> > Direct navigation, that is to say going directly to a web resource by
> > entering a URI-reference through the user interface of the user agent, is a
> > civil right of the Web.  It's not the democratic space that Tim wanted 
> it to
> > be without this cycle.  Yes, it is mostly done with cut and paste and not
> > typing.  Only fossils like me type the URIs for the email archives.  But
> > editing the URIs from where you are to say where you want to go (to 
> parallel
> > structures on the site) is very real in terms of resources such as the W3C
> > email archives.  It depends on the structure of the collection, whether
> > editing URIs is something that will be used often or rarely.
> >
> > See also:
> >
> > Use URL path hierarchy mnemonically:
> >
> >   http://lists.w3.org/Archives/Public/uri/2002Nov/0013.html
> >
> > People do use the list-of-list-archive pages:
> >
> >   http://lists.w3.org/Archives/Public/wai-xtech/2002Mar/thread.html#66
> >
> > Al
> >
> > PS:  If the URI is available in cut and pasteable text, we don't need to
> > put in guidelines about how they should sound.  The sound like gibberish,
> > it is clear to the screen reader that it should spell and not say them,
> > and the key thing is being able to print or email them for a friend to
> > start at the same place as where you were.
> >
> > Think about reporting a problem which arose using the web.  The first
> > question is "where were you, and what were you trying to do."  If one can't
> > cut and past the URI the webMaster is out of luck trying to reproduce the
> > problem.
> >
> > This is a genuine problem for people with disabilities: that the reporting
> > of problems is badly supported with over-restrictive web forms and not
> > enough automation in terms of capturing and emailing the conditions under
> > which the problem occurred.
> >
> > >Alex.
> > >
> > >--
> > >                             | HTTP performance - Web Polygraph benchmark
> > >www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
> > >                             | all of the above - PolyBox appliance
> >
> >
>
>--
>                             | HTTP performance - Web Polygraph benchmark
>www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
>                             | all of the above - PolyBox appliance

Received on Wednesday, 29 January 2003 09:20:18 UTC