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

Wendy,

	The technique in Front Page was a "for whatever it's worth" ... MS may
consider it a "hack" of their program <grin> ....

	Yes, each day I work with the kids using the pages on
http://www.geocities.com/apembert45 , I see a preference for the fewest
words ... perhaps a preference for an verb in it .... print map of xxxx,
see pictures of xxx, etc. I can't promise I have enough time to collect
hard data, but it's happening as I watch!

						Anne

At 11:52 AM 1/19/01 -0500, Wendy A Chisholm wrote:
>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 Monday, 22 January 2001 19:09:11 UTC