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

Where can I get the 'fat links' idea installed so that it comes up
automatically on threads like this?

The most natural form of a link is that there is a small hot zone which is the
clickable screen real estate and there is a penumbra, "white of the egg" or
"immediate logical neighborhood" that the orientation to the link depends on
along with the link contents proper.  

The general idea is that if the formats always capture what this next larger
context is that provides the full orientation to this choice, then the
clickable hot spot in the visual interface would not have to be expanded to
include all of it.  This makes "click here" OK as link text, so long as there
is a wrapper or label that the user agent can comprehend which tells you "for
what."

The visual interface would distinguish the central 'yolk' of the link as
sensitive.  The screen reader would know to read out the "whole egg" when
tabbing.

This is a more-functional design.  It requires a change in the model of the
formats.  It is possible that it is a 'nice' and not critical enought to catch
on.  On the other hand, it removes a continuing bone of contention between
what
works for one group and what breaks for another.

Al

At 11:52 AM 2001-01-19 -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>http://www.w3.org/TR/ATAG/#gl-pr
ovide-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>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>http://www.w3.org/TR/WCAG
10-HTML-TECHS/#link-text
>> >[2]
<http://www.w3.org/WAI/GL/WCAG20/#consistent-behaviors>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 (<http://www.w3.org/>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 (<http://www.w3.org/>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/#>http://infomesh.net/2001/01/n3terms/
#> .
>> >>[ :name "Sean B. Palmer" ] has :homepage
<<http://infomesh.net/sbp/>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 12:09:54 UTC