Re: navigation banner in css.

Visually (i.e. for the large majority of people) it is not clear how to 
interpret <a href="foo">this is a </a><a href="bar>very</a> <a 
href="baz">contrived example</a>. It's a similar problem to working out 
what are the hotzones of an imagemap without tabbing around it. As far 
as I know Amaya (hardly a mass-market product, but one with an 
increasing user base) is the only browser that provides a means to 
highlight hotzones visually in an imagemap, and while speech output 
systems are capable of presenting links separately, it is less common 
in tools designed for us, the masses.

The question might be one more of presentation. In HTML, the practice 
of separating things reasonably can be done in several ways - my 
personal preference is for a visual indicator, but this isn't always 
easy to do using inline linking from text. (My approach to that is to 
see if I can write my text in a slightly different order. Answer: 
sometimes...). In graphics it is also interesting. HTML imagemaps are 
pretty simplistic,  and browsers should be able to put markers onto the 
hotzones if users ask for it, but in SVG this is relatively easy for 
authors to do to.

This of course begs the question of whether authors or browsers should 
provide the functionality - the tradeoff is between flexibility in the 
way that it is presented, allowing authors to match it well to their 
overall presentation, and ensuring that the functionality is available 
to the users without imposing work on authors that won't actually get 
done. Obviously the text you quoted isn't adequate for clarifying what 
links there are it there were agreement that the author should be 
responsible for doing so. But having read the explanations you give 
here and in your book, I don't think you have definitively established 
that the requirement underlying the checkpoint is not a reasonable one.

cheers

Chaals

On Saturday, Jan 25, 2003, at 11:52 Australia/Melbourne, Joe Clark 
wrote:

> <http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-divide-links>
>
>  Until user agents (including assistive technologies) render
>    adjacent links distinctly, include non-link, printable characters
>    (surrounded by spaces) between adjacent links.
>
> As I explain in my book, this is an arse-backward requirement in the
> first place. The sequence <a></a><a></a> is self-explanatory and
> fully demarcated, as is the similar <a></a> <a></a>. So: Jaws
> (inevitably-- WCAG's blindness-related requirements are all based on
> working around the peccadilloes of Jaws present when WCAG was
> written)

This is an unsubstantiated, and in my opinion based on my experience of 
working on WCAG 1 since WAI started it, an untrue claim. Do you have 
evidence to back up your claim that all  blindness-related requirements 
are based on what jaws did? Or did you really mean to say that some 
requirements were based on JAWS' behaviour at the time (as indeed one 
would expect for things grouped under a guideline that says

"...These checkpoints are classified as "interim", meaning that the Web 
Content Guidelines Working Group considers them to be valid and 
necessary to Web accessibility as of the publication of this document. 
However, the Working Group does not expect these checkpoints to be 
necessary in the future, once Web technologies have incorporated 
anticipated features or capabilities."

-- WCAG 1, Guideline 10 
<http://www.w3.org/TR/WCAG10/#gl-interim-accessibility>

> couldn't differentiate adjacent links. That's not our
> problem. It's valid HTML. Similarly, adding those hideous D-links
> because user agents didn't support longdesc was also a bad idea
> because it too was not our problem.
>
> Now, can anyone demonstrate that current browsers and screen readers
> *are still unable* to "render adjacent links distinctly"?
>
> Note that a response of "Well, Product X version 1.0 from 1994,
> which one person in a Swiss canton still uses, is unable to
> differentiate links" ain't gonna cut it in 2003. We're not talking
> about something genuinely novel and complex, like accessible PDF or
> Flash. We're talking about interpreting the original HTML spec!
>
> -- 
>
>   Joe Clark  |  joeclark@joeclark.org
>   Author, _Building Accessible Websites_
>   <http://joeclark.org/access/> | <http://joeclark.org/book/>
>
>
--
Charles McCathieNevile           charles@sidar.org
Fundación SIDAR                       http://www.sidar.org

Received on Friday, 24 January 2003 22:41:41 UTC