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

Anne,

I have included the AU WG on my response to address the 2nd issue you raise.

My understanding of your message is:
1. in your experience, the children that you work with are less likely to 
follow "in your face" URLs so therefore you support adding something to the 
techniques document.

2. One way that you are able to create text links is using IE and FrontPage 
reader and you've outlined those steps as a proposal to add to our 
techniques document.

3. Another observation you have made is that children and perhaps also 
people with CD and LD find shorter links easier to navigate.

I'll respond to each of these:
1. I'm glad we have some informal data to back up and provide more 
rationale for avoiding "in your face" URLs.

2. Currently, we do not have any techniques that are specific to one 
authoring tool.  People have requested this information but we have not 
provided any yet.  Since these are both Microsoft products, I think it 
would be more appropriate for them to produce something that we could point 
to.  Ideally a document that shows how to work with their tools to follow 
all of the WCAG checkpoints - ala Guideline 6 in the Authoring Tool 
Accessibility Guidelines [1].  What do others think about this?  Does 
Microsoft have documentation online that we can refer to from the 
techniques to help people make the connection between WCAG and the tool 
they are using?  What about other authoring tools?

3.  People in general seem to find shorter links easier to use - assuming a 
link has been given enough context so that it's destination is clear.  User 
Interface Engineering discusses link length in their book "Web Site 
Usability: A Designer's Guide" which is based on a series of usability 
studies.  Jakob Nielsen also discusses link length in his book "Designing 
Web Usability."  Links that are too short can be ambiguous and confusing.

[1] http://www.w3.org/TR/ATAG/#gl-provide-help
--w


At 06:54 PM 1/18/01 , Anne Pemberton wrote:
>Wendy,
>
>         As I considered your addition to techniques, I thought about the 
> web page
>that the 2nd graders are now using pretty regularly in the lab
>http://www.geocities.com/apembert45 ... some of the links go to old stuff,
>and two pages that the students use (Thanksgiving and Halloween) were pages
>used in print and just converted to html and hung on the web ... the links
>are all "in your face" URL's, and many kids avoid these pages and use only
>the newer ones for King and Israel ... (it may be that kids who use the
>Internet at home and are used to "clicking on the underlined blue letters"
>are more adventuresome) ... Links of one or two words are easier for young
>children (perhaps CD and LD folks, even ordinary folks) to navigate ...
>
>         There is an easy "technique" to do it in Front Page, perhaps other
>authoring tools - 1) pull up page in Front Page, minimize 2) Pull up IE; 3)
>go the the target site; 4) copy address from window; minimize IE; 5) paste
>address to desired place in page, press enter; 6) move cursor to somewhere
>inside address now in link color and underlined; 7) Insert words for link;
>8) delete the original link before and after the inserted words. ....
>(Words for link can be the title of the page, the site, or the type of
>activity, etc. whatever suits the surrounding page ...)
>
>                                                 Anne
>
>
>
>                                         Anne
>
>
>At 03:18 PM 1/18/01 -0500, Wendy A Chisholm wrote:
> >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
> >/--
> >
> >

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

Received on Friday, 19 January 2001 11:46:50 UTC