W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2012

Re: Limit on the links in a page

From: Chaals McCathieNevile <w3b@chaals.com>
Date: Sat, 11 Aug 2012 17:35:03 +0200
To: "'Vivienne CONWAY'" <v.conway@ecu.edu.au>, "'W3C WAI ig'" <w3c-wai-ig@w3.org>, "Adam Cooper" <cooperad@bigpond.com>
Message-ID: <op.wivuwpov22x22q@chaals>
On Sat, 11 Aug 2012 07:21:58 +0200, Adam Cooper <cooperad@bigpond.com>  

> Hi Vivienne,
> A page with 2000 links would end up with me closing the browser tab ...
> there certainly can be too many links on a page, but I can't recall  
> anything in WCAG that expressly imposes any limit ...

It would be quite difficult to set a limit. Although it is painful reading  
a large document (WCAG isn't, but the HTML5 specification is something  
like 1000 pages) which interrupts itself all the time to announce a link,  
it is unclear what the alternative is.

Technical specifications, and the front page in particular of large  
government department, newspapers or universities often have a lot of  
links. Unlike a novel, it is rare to read them from start to end. So it is  
important to have structure that allows you to find the interesting bit.  
Sadly, JAWS implemented a links list years before it allowed heading  
navigation so people learned to skim through the links, and therefore  
taught others the technique that worked for them, instead of developing a  
culture of structuring content for simpler search.

> The 'links list dialog' in JAWS (INSERT + F7) would take considerable  
> time to compose a list of 2000 links,

A HIGHLY INEFFICIENT way to get this list from a page [1] takes a fraction  
of a second in Opera for the 547 links in wcag. If JAWS is taking a long  
time, they should look at the code again.

> and one wonders, with that many links, whether link purpose might
> become an issue ... meaning links with the same screen text
> pointing to different destinations or links with different screen
> text pointing to the same destination.

Yeah, that is an issue with a dozen links too. But often (apart from the  
dreaded "click here" that it seems some sites just can't get out of their  
system) that isn't an issue in practice.

The 2000 links often come from things like providing a link to the  
definition of technical terms every time they are encountered.

HTML 4 provided the ability to add rel="glossary" for this. It isn't  
complicated to check whether you are adding a duplicate link to a  
glossary, or even to strip them out altogether, if you want to simplify  
navigation. But if nobody does it, then people look for the most effective  
thing that is actually implemented, even if it is far worse in practice...

[1] <javascript:var foo='list:';for(var  
";}alert(foo)> This is inefficient because in theory it generates the  
entire list again to look for each entry. Making the smart version of this  
into an extension that produces the link list in the browser (instead of  
in JAWS) is pretty trivial, and if JAWS is really that inefficient it  
might be worthwhile.



> Just a random thought  ...
> Cheers,
> Adam Cooperacooper
> -----Original Message-----
> From: Vivienne CONWAY [mailto:v.conway@ecu.edu.au]
> Sent: Thursday, August 09, 2012 11:08 PM
> To: W3C WAI ig
> Subject: Limit on the links in a page
> Hi all
> I was having a discussion with a colleage about the number of links on  
> pages
> and how that poses a burden on users of screen readers in particular.   
> One
> page recently had over 2000 links which, if you were using a screen  
> reader
> and trying to find your way around via the links, would be incredibly
> frustrating.  It also caused the automatic tool being used to verify  
> results
> to fall over and surrender.
> We wondered if there is any mention in WCAG of the need to limit the  
> links.
> I couldn't find anything, but some of you might know the answer to this.
> Regards
> Vivienne L. Conway, B.IT(Hons), MACS CT, AALIA(cs) PhD Candidate &  
> Sessional
> Lecturer, Edith Cowan University, Perth, W.A.
> Director, Web Key IT Pty Ltd.
> v.conway@ecu.edu.au
> v.conway@webkeyit.com
> Mob: 0415 383 673
> This email is confidential and intended only for the use of the  
> individual
> or entity named above. If you are not the intended recipient, you are
> notified that any dissemination, distribution or copying of this email is
> strictly prohibited. If you have received this email in error, please  
> notify
> me immediately by return email or telephone and destroy the original
> message.
> ________________________________________
> From: Chaals McCathieNevile [w3b@chaals.com]
> Sent: Thursday, 9 August 2012 8:10 PM
> To: W3C WAI ig; Harry Loots
> Subject: Re: does alternate version comply with SC 2.1
> On Thu, 09 Aug 2012 13:10:27 +0200, Harry Loots <harry.loots@ieee.org>
> wrote:
>> ... by being forced to use the table, [users] are denied the
>> advantages offered by the timeline (e.g.: context, comparison at a  
>> glance,
> etc).
> I think that pretty much explains the issue.
> Is it clear that to use a keyboard you have to find the alternative  
> version?
> How hard is it to make the thing respond to keyboard control?
> It seems your developer is proposing something that probably technically
> fulfils the minimum possible requirement, but is really second-rate (to
> almost avoid saying "half-arsed amateurish") work.
> If you're prepared to pay for that, the developer can probably justify  
> it as
> acceptable. If this is truly the scenario, please let me know who the
> project team is so I don't risk hiring them.
> cheers
> Chaals
> --
> Chaals - standards declaimer
> This e-mail is confidential. If you are not the intended recipient you  
> must
> not disclose or use the information contained within. If you have  
> received
> it in error please return it to the sender via reply e-mail and delete  
> any
> record of it from your system. The information contained within is not  
> the
> opinion of Edith Cowan University in general and the University accepts  
> no
> liability for the accuracy of the information provided.

Chaals - standards declaimer
Received on Saturday, 11 August 2012 15:35:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:45 UTC