WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using UL for links

for

From: Terence de Giere
Date: Mar 18, 2004 1:54PM

I think this discussion of using undordered lists, the HTML UL element,
to organize links began with the problem of not using printing separator
characters between links, an accessibility guideline designed mostly for
legacy assistive technology. This is a Priority 3 World Wide Web
Consortium guideline:

"10.5 Until user agents (including assistive technologies) render
adjacent links distinctly, include non-link, printable characters
(surrounded by spaces) between adjacent links."

Note that this guideline does not just cover assistive technologies, but
browsers in general, and visual browsing as well.

Some browsers by default underline the links, some older browsers and
text browsers do not, some new graphical browsers do not, in which case
it might be hard to tell even visually where adjacent links begin and
end. How well the user can tell the text they are seeing, listening to
or feeling on a Braille terminal is a link depends on whether the user,
by looking or with the use of assistive technology can directly identify
a link or has to interpret or guess just what is printed on the screen.
Visually, most current graphical browsers by default underline links,
but this is not universal, and the user may need to set user settings to
underline links if they were not so coded using cascading style sheets.

Legacy screen readers (assuming left to right reading European languages
for this discussion) read left to right across the screen, then move
down to the 'next line' as they interpret where the 'next line' begins,
presumably based on the vertical spacing of characters on the left
margin of the page. Thus the greatest potential for non discrimination
of links is with links in a horizontal line where it may not be clear to
a visual user where the text for one link ends and another begins, and
the same is true for old screen readers. A true audio browser should
work fine, because an audio browser reads the HTML directly, rather than
indirectly as do older screen readers, and thus can clearly identify a
link. If the links are vertical, in a list or table, there should not be
nearly as much potential for confusion, unless the link text wraps to a
new line, in which case it may be indistinct to a visual user if the new
line is a new link or not, and the same for an older screenreader.

A non link printing spacer character such as vertical bar, a period,
left and right brackets, etc., between the links provides a method for
the user to visually or by reading with a screen reader in normal or
character mode, to determine where the next link begins. In default
presentation, browsers rendering a list will add a non link bullet
character, an asterisk, etc. before the link, although this character
may not be read in some assistive technology. If the list ends with a
link, and is immediately followed by a link, there will be no printing
spacer character.

There is also the question of what happens if the list bullet is
suppressed by CSS. using {list-style-type:none} The non link printing
character does not print to the screen. Thus if a link is formatted
using CSS from a vertical list to a horizontal row of links, and
suppressing the bullets, we now have a situation where there is no
printing character between adjacent links. An older screen reader used
with a recent CSS browser could in fact be in the same situation with
such a reformatted list as with a horizontal row of unseparated links.
The accessibility checking software sees a list so it thinks there is a
character there, but it is not actually checking for the character, it
just assumes that because it has identified a list.

Using CSS or even the deprecated font element, one can color a link
separator character (for graphical artistic reasons) to be the same
color as the background, which may affect some visual users who have
perception problems, but allows the character to be read by screen
readers because it is text that prints to the screen, and to show in non
CSS browsers. Putting borders etc, around the links can help visual
users keep them separate, amking them look like a row of buttons. This
visual CSS is not read by current assistive technology.

Note that Bobby version 5 will incorrectly miss printing spacer
characters between links if they are enclosed in another element, such
as SPAN, for example, to color the spacer character the same as the
background. If {display:none} is used to hide a printing character, the
character will render in non CSS technology and some older assistive
technology, but will effectively not be there with recent screen readers
that can interpret that CSS rule and not be there visually with CSS
competent browsers. One could position it off the screen using CSS, and
it will be read by some of these technologies, but not be seen.

Now, some assistive technology users are annoyed with spacer characters,
because they do not need them as their technology clearly identifies
links. For them listening to say, 'vertical bar' being spoken by the
reader between each links slows down browsing. If links are separated
with left and right brackets as is sometimes the case, it is even more
annoying for these users when these characters are read out, for
example, "left bracket link apple period computer period com right
bracket left bracket link ibm period com right bracket." Exactly how
these links are rendered, how the pucntuation is rendered and so on, is
a function of the speech engine and the assistive technology reading
mode. Some are more human usability centered than others when it comes
to reading text.

The intent of this guideline seems to be to provide a means for both
visual and non visual users to be able to unambiguously identify
adjacent links, and it is clear that each of the potential solutions
might not be ideal for every user, that accessibilty checking software
is not sophisticated enough, and that the main problem for users will be
with a horizontal row of links that are not clearly worded, clearly
spaced, clearly formatted, and with links that wrap to more than one line.

Terence de Giere
<EMAIL REMOVED>



----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/