Re: changing presentation of links [SEC=UNCLASSIFIED]

Good thread.

Is anyone here taking this stuff into WebPlatform.org? That should be a  
useful place to store the outcome of these discussions (and be a good  
reference when questions come up again...)

On Fri, 09 Nov 2012 00:51:48 +0100, Phill Jenkins <pjenkins@us.ibm.com>  
wrote:

> Roger asked about1.4.1 Use of Color: Color is not used as the only  
> visual means. . .
> While JF said:". . .  links should be perceivable to all users without  
> first having to hunt for them (using tabbing or mousing) . . ."
> In my opinion 1.4.1 is all about NOT using blue as the only visual  
> means, while JF and others are suggesting that there should always be a  
> visual >means.   
> I believe there is confusion (again and often) about the requirements  
> for the web developer and his/her content and the requirements for the  
> browser, >AT, and end user settings and education.   
> As Andrew Arch pointed out, SC 1.4.1's Failure F73 [1] is key in  
> understanding 1.4.1.  I've quoted the description because it is  
> explanatory in this case >[Phill added text in brackets]:
> "The objective of this failure is to avoid situations in which people  
> who cannot perceive color differences cannot identify >links. Link  
> underlines or some other non-color visual distinction are required.  
> While some links may be visually evident from >page design and context,  
> such as navigational links, links within text are often visually  
> understood only from their own >display attributes. [Authors] Removing  
> the underline and leaving only the color difference [or removing both  
> the underline >and the color difference] for such links would be a  
> failure because there would be no other visual indication that it is a  
> link.
> Note 1: If the non-color cue only happens when the mouse hovers over the  
> link or when the link receives focus, it is still a >failure.
> Note 2: If the link is a different color and bold it would not fail  
> because the boldness is not color dependent."
> In my opinion, the requirements for "links" are, at least, the following: 
>        1.3.1 Information [about links] can be programmatically  
> determined (Level A)Understanding Success Criterion 1.3.1        
> >                1.3.3 Instructions provided for understanding and  
> operating [links] do not rely solely on sensory characteristics such as  
> >shape, size, visual location, orientation, or sound. (Level  
> A)Understanding Success Criterion 1.3.3               1.4.1 Color is not  
> used as the only visual means of conveying [links] or distinguishing a  
> [link] (Level A)Understanding >Success Criterion 1.4.1
> So, authors creating blue underline links would meet all three success  
> criteria, unless the surrounding non link text was also blue underlined  
> - correct? > And bold black links would also not fail  if is was  
> different than the surround text - correct?  A key author requirements  
> is to make the links > programmatically determinable, so then the  
> browser, AT and end user settings can "do the rest" of the  
> personalization and visual styling, if needed.

Normal links are programmatically determinable by definition. They use an  
A element with an HREF attribute. THe program to find them often looks like

  document.querySelectorAll('a[href]')

(Although this isn't always true. Gmail originally used a giant onclick   
handler, so when you clicked on a part of the screen that had blue text,  
it behaved as if there was a link, effectively failing 1.3.1 and making  
keyboard accessibility a nightmare. The later Bespin text editor had  
similar issues. Over a decade ago common design tools would make a picture  
of big chunks of text, and then do the same via image maps. But all of  
those solutions are rare - they require the combination of a skilled  
programmer (to make it work) and very little understanding of how the web  
is used (to allow it to ship). In the general case, this seems to be  
handled by common sense).

The key is to make links identifiable on inspection by a user. Since most  
users don't customise presentation of a page, it is insufficient to assume  
that they *could*. And as noted, colour alone doesn't cut it - although it  
helps most people, there are lots of cases where it fails, and a secondary  
convention such as underlines, font change, etc, should be used.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com