Re: Technique Reducing The Need For In-Your-Face URLs

Trying to resolve this thread...

In WCAG 1.0 this relates to checkpoint 13.1 - Clearly identify the target 
of each link. [Priority 2].  Techniques are discussed in the section 6.1 
Link text of the HTML Techniques for WCAG [1]

In WCAG 2.0 this has been wrapped into checkpoint 2.1 Provide consistent 
interaction behaviors and navigation mechanisms.

I think in the techniques we can write more about "consistency" of 
navigation mechanisms (such as links) and one of the recommendations that 
we think should be consistent is only using "in your face URLs" in cases as 
have been described in this thread - in footnotes when the page will be 
printed, when specifically identifying a web site for someone to read 
(again, usually for printing or presentation/discussion purposes), etc.

Therefore, for the time being I propose adding something to section 6.1 of 
the HTML Techniques for WCAG.  This eventually should appear in the Core 
Techniques as it applies across languages - but for something to quickly 
point to and something that 's easy to change how is that for a first stab?

[1] http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text
[2] http://www.w3.org/WAI/GL/WCAG20/#consistent-behaviors

--wendy

At 10:21 AM 1/18/01 , Sean B. Palmer wrote:
> > reading something on a web page and then wanting to email
> > it to you, so I copy-and-paste and send it to you.  The links
> > will be lost during that process.
>
>Good point. I wonder if in the future there will be different kinds of
>copying mechanisms: copying media and converting it into text form? For
>example, if I select a Web page, and copy the text, it should convert the
><img alt=""> to their alt attributes, and <a href=""> to their href
>attributes... Maybe AU would be interested in that?
>
> > Printability is one of the primary reasons for this;
>
>That's always the major reason. Even in 5/10 years time when CSS is more
>generally accepted, I don't think there will be many changes. People will
>still feel the need to have in-your-face URL's because of the "pre-CSS
>browsers"... and that is a problem. If 99% of people haven't got a gimmick
>that makes pages more accessible, do you have to provide fallback
>mechanisms for those 1%, and cause problems for the 99%? The answer appears
>to be yes...
>
> > Stylistically, I think inline "in your face" URLs are generally
> > nasty unless they specify a simple site address, such as
> > "the W3C's WAI (www.w3.org)".  [Yes, I know that's a machine
> > name, not a URI,
>
>Well, it's a domain name. Yes, they are generally accepted, and most
>browsers will take them if you type those in... but what if one didn't? Oh,
>and I think you might want the (www.w3.org) after the "W3C" not the "WAI"?
>
> > If a URL is going to be directly stated, I feel it should be
> > given by itself, and not inline;
>
>Yes, or as a reference at the foot of the email. Maybe we should have a
>techniques document for plain text :-)
>
>Kindest Regards,
>Sean B. Palmer
>@prefix : <http://infomesh.net/2001/01/n3terms/#> .
>[ :name "Sean B. Palmer" ] has :homepage <http://infomesh.net/sbp/> .

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Thursday, 18 January 2001 15:13:17 UTC