Separate adjacent links with more than white space

Best practice?

[D_Blackwell]

I have several paragraphs that contain just a link. The paragraphs are used to style a box, background, and such. The paragraphs are displayed vertically with an em of margin between each.

How do I best hack/get around/satisfy " Separate adjacent links with more than whitespace." in this situation?

"White space characters", such as spaces, line l. breaks, carriage returns, and paragraph breaks, are not sufficient.

It seems to me that a link boxed up in a <p> should be more than adequate. Why should this be put upon designers, rather than UAs and 'assistive technologies'. If this is actually important, what are the "assistive technologies" doing? Is it important?

Place some sort of separating character between adjacent links. Images or bulleted or numbered lists are good choices.

These are not options in this case.

Do I just hack in an extra character right after each link, and then hide it with color: or some such? I hate that, but have done it in other situations. Does it matter or help, or cause affected users some other issue?

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

Same question as above really. On whom (who?) should this issue legitimately fall?

"Not I", I protest, with a vigor usually reserved for IE bashing. However, I want to do my best anyway:((

[Mindy]

While I can't speak for earlier versions of JAWS or other AT, JAWS 6.0 and higher certainly has no problems with adjacent links. However, it is standard practice to separate links with a > or a ¦ and most people will understand what those symbols mean as they are used to them being used in that way. JAWS reads links as "Link: text of link" and I think Windows-Eyes does a similar thing.

It seems to me that adjacent links are more of an issue for people with low vision NOT using AT or people with cognitive disabilities who for whatever reason do not understand where one link ends and the next begins just by looking at the words. It is also an issue of usability because where sites have loads of different links one right next to each other, I find I have to concentrate that bit harder to find what I want.

[Don_Hoagie]

This is often the result when sites using CSS rollovers are viewed sans stylsheet, correct? I don't know if that's specifically what you're speaking on D_B; but we can see this as a situation where the adding of of "divider characters" would not work.

Personally I think this stipulation should be more of an advisory, and not so much a rule (Actually I forget what priority level it is... maybe it is an advisory after all). As the last poster stated, I don't think screen readers have issues with this technique (the Mac's built-in VoiceOver SN doesn't have an issue), so it comes down to sight-enabled users who have trouble with the lack of clarity. That is something that should be kept in mind when designing, but when you gotta do it, you gotta do it.

[esha734]

I got the same message when using Bobby. I asked an administrator what it meant and a possible solution.
This is his reply:
"Although you've defined space around those hyperlinked images in you CSS, if you don't have a style-sheet display, the images would have no space between them. That is why it is being flagged. It is a Priority 3 error, so take that into your consideration. Here is a little exerpt on white space:

White space between links is not much of an issue for screen readers these days, but it is an issue for
some browsers, particularly text browsers. With some text browsers, you cannot tell where one link
ends and the other begins, if the elements are adjacent. This is true even if the link is an image, where the text representation (Alt text) of the image in the link can still make it hard to tell one link from another. This is the rationale behind the WCAG Checkpoint 10.5 and why the accessibility check flags some adjacent links as errors. While you expect that a line break in a text browser should mean that there is one link per line and that it should be pretty clear which link is which, testing shows that vertically adjacent links still present problems. Until this situation changes, the accessibility check will not accept <br> as a separator. Consider it part of Watchfire's careful accessibility guideline conformance.

Example Solution:
Place a separator character, such as a pipe, in a <span style="visibility:hidden"> tag. The <span> tag
will prevent the character from being displayed on screen. However, in browsers that need the separator
character, it will appear since those browsers generally do not support CSS. That makes it possible
to meet the accessibility need without impacting design, and the accessibility check will accept this
technique.

A technique I personally like is to have [ ] characters around the link, and you could use CSS to not display the [ or ] characters. But if a browser without CSS sees the page, they will be shown. Example: [Link 1] [Link 2] [Link 3]"
This is what I've used that works:
<li><span style="visibility:hidden">[</span><a name="top"></a><a href="#maincontent" title="go directly to main content">Skip to Main Content</a><span style="visibility:hidden">]</span></li>

Cheers.
es

[D_Blackwell]

esha734 - I like the idea [ bracketing ] links, though that would mean extra sets of <span> tags, which I don't like so much. Up til now, I've just been hiding a character after each link, and will likely continue with that.

It's hard to get away from a strong feeling that these text readers and such need should be dealing with these kinds of things. For now, I guess that I'll continue to acquiesce.

[DrDoc]

Although bracketting certainly looks better, it gets mighty annoying for anyone employing a screen reader: "left square bracket, link text, right square bracket, left square bracket ..."

The ideal separator from a "screen reader" point of view seems to be a period or comma. Both already serve as natural separators in written language, and would be less annoying for the user. From a visual point of view, it is probably best to ensure that there is reasonable _space_ between the links, accompanied by something like a vertical bar or hyphen type character.

Lists also offer additional possibilities for "separation" without having to resort to specific characters.

Avoid "directional" symbols (such as >) as they symbolize progress and/or navigational levels.

[DrDoc]

Place a separator character, such as a pipe, in a <span style="visibility:hidden"> tag. The <span> tag
will prevent the character from being displayed on screen. However, in browsers that need the separator
character, it will appear since those browsers generally do not support CSS. That makes it possible
to meet the accessibility need without impacting design, and the accessibility check will accept this
technique.

That may be dangerous advice, as it assumes accessibility only between CSS and non-CSS environment, completely discounting the affects it would have on screen readers etc.

[D_Blackwell]

All along I've been hiding a period after every link, so it sounds like I'm addressing the problem at hand as best as possible, without creating undo problems for other groups. Good point about the problem that brackets might cause.

Given that most of my clients care not the slightest anyway, and certainly don't want to bankroll any of the learning curve, I hope that it's all worthwhile down the road.