RE: Limit on the links in a page

On the subject of how long it takes to build links -- I believe there are a
number of factors:
1. Some pages contain frames nested into complex frame sets.  AT may need to
traverse these frames
2. The link text that is generated by some screen readers is not just the
inner text but may include title attributes or alt attributes of nested
images, etc.
3. Other factors mentioned in this thread including cross-process access
play a role

I will say that a large number of elements on a page regardless of whether
they are links or not affect access.   I've seen large simulated combo boxes
with 3,000 bring assistive technology down.  At the same time I've had
commercial web apps like Basecamp brought down to a crawl on IE with NO AT
running.  The WHATWG HTML page can slow down IE, Chrome and Firefox
incredibly with no AT running.

A large number of links on a page do present other issues for accessibility:
1. When reading with arrows screen readers tend to stop on elements of
different types such as links.  This is true of the swipe with iOS or when
down arrow and JAWS.
2. The word link repeated can distracted from understanding the page

This issue is particularly an issue on pages where links are used to provide
linking to definitions.  These definitions can be useful for some people
with cognitive impairments however.  I've seen some pages where almost every
word was linked including simple words -- for me this causes issues with
tooltips popping up as I moved my mouse making it a challenge to read the
text of the screen.

These types of challenges of course do not fall into success criteria
conformance unless an argument can be made against assistive technology
supported or non-interference under the WCAG conformance requirements.

There are many universal design and usability issues that are important to
people with disabilities.  It can certainly be a challenge for organization
to determine which ones to require or not.  Some methodologies prescribe
making them requirements if they can be tested in a discrete manner.
However, this factor alone is not sufficient.  Other methods use tests to
determine user responsiveness, why others measure importance by research and
consensus from the community.

This same challenge is what the we are facing when trying to determine the
level of accessibility of a webpage using metrics.   Not all WCAG success
criteria are equally important to all user groups -- and while it's the goal
to meet all of them that doesn't always happen and issues have to be
prioritized.

Jonathan


-----Original Message-----
From: Mark Rogers [mailto:mark.rogers@powermapper.com]
Sent: Saturday, August 11, 2012 11:05 AM
To: Benjamin Hawkes-Lewis; Olaf Drümmer
Cc: W3C WAI ig; Adam Cooper; Vivienne CONWAY
Subject: RE: Limit on the links in a page

>I can't see any fundamental reason why this should take a long time.
>VoiceOver doesn't just handle them in memory, it displays them in the Item
>Chooser list. Pretty much instantly.
>Likewise Opera surfaces 2000 links in its Links list pretty much instantly.
>If this is a problem in JAWS, that represents fundamental inefficiency
>either in its communication with browsers (assembling the list) or its
>widget set (rendering the list).

I think the likely reason for this is JAWS (and NVDA) on are separate
applications, which means they run in their own protected memory space. This
means they can't access memory in the browser directly, and need to marshall
data between processes (e.g. to get a list of links). This is much, much
slower than just accessing the data directly in memory.

This is one reason JAWS and NVDA both have plugins for IE and Firefox -
these run as part of the browser process to speed up some common operations.
Some details on this here:

http://www.nvda-project.org/wiki/DesignOverview#Inter-processCommunication

I'm not familiar with the internals of VoiceOver, but I'd guess it's loaded
into each process automatically because it's part of iOS / MacOS, which
means it doesn't suffer the performance hit.

Best Regards
Mark

Mark Rogers - mark.rogers@powermapper.com PowerMapper Software Ltd -
www.powermapper.com Registered in Scotland No 362274 Quartermile 2 Edinburgh
EH3 9GL

Received on Tuesday, 21 August 2012 01:56:25 UTC