Re: link navigation

Chaals,

Comment near the bottom... in double blue square brackets.

                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: Fred Esch/Arlington/IBM@IBMUS
Cc: "SVG-A11y TF" <public-svg-a11y@w3.org>
Date: 11/02/2015 04:01 PM
Subject: Re: link navigation



On Tue, 03 Nov 2015 00:07:02 +0900, Fred Esch <fesch@us.ibm.com> wrote:

> Chaals,
>
> The sparse chord example does indeed show issues.  The first time I ran
> it using Firefox my default browser, I saw wedges of the chords
> disappearing and it reminded me of search lights in the sky.

Yeah, that was due to a bug :)

> I did not follow the navigation pattern as my focus was drawn to
> wondering why chords were changing.  I tried it on Chrome and saw
> different highlighting - a blue bounding rectangle of the left bar +
> chord (or a horizontal blue line if the rectangle was clipped) and
> less noticeably a gray blur on the chord boundary.  IE was similar
> to Chrome, but in IE the gray blur was more noticeable than the box.

Yes. I agree that the highlighting needs to be pretty clear. I think it is

useful to have standard highlighting from a browser, with *additional*
highlights. For example, the browser focus highlights tend to be square,
covering the bounding box, whereas things in SVG might have different
shapes - and indeed not reach anywhere near their bounding box in practice.

> I ran it several times and  I realized that navigation was walking down
> the left side. It took me several more minutes to realize that the
> pattern was left bar, chord, left bar, chord - I think.

Well, that's something. (I don't think you can get that in Firefox since
it doesn't respect tabindex in SVG).

> Hitting the ENTER key turned chords gray on Chrome. I don't have a
> clue as to what that is supposed to mean.

Nor do I. If you hit enter on a link, I would expect it to move focus to,
and highlight somehow, the target of the link. But that doesn't seem to
happen much yet.

> If navigation was simply walking down the left bars, I would suggest
> strong highlighting on the active left bar so the user can see
> the navigation pattern.

Even if it isn't that I think you're right that there needs to be strong
highlighting.

>  I don't think this is a workable pattern as I
> will have to look at the DOM to verify the navigation order.
>
> Connectors may help, but users won't know how to use connectors in
> navigation.

They are links, associated to both of their endpoints - in practice the
strong native semantic version of aria-flowto. I agree that there is a
question about whether this makes sense to users, which might explain why
the implementation of flowto is weak, but the alternative of making
reciprocal links is pretty painful. Although I believe I can use SVG
animation to significantly improve the visual hints - except of course in
IE.

> I will go out on a limb and say, it is pretty easy for sighted
> users to pick up using the arrow keys for navigating.

That's good news if true.

> However, sighted users don't have a natural or learned association for
> using connectors.

I suspect they do if we start with the right kinds of diagrams. Undirected

graphs, such as circuit diagrams, roadmaps, chord graphs, social graphs
based on confirmed links…

> Training a user on a chutes and ladders (snakes and ladders) game would
> help for nodes with single connections, but not for nodes with multiple
> connections.

Right. And I don't think snakes and ladders is any better than a lot of
other examples.

> My experience is, when you get multiple connections, the user
> will have additional keystrokes to learn and use. Since most users won't
> learn and use additional keys for infrequent use cases, connector based
> navigation will be mostly ignored.

I'm not sure that additional keystrokes are the right answer. Instead, I
would expect something more like a text-based adventure game from the
1980s - "you can (1) go to the pub (2) go fly a kite or (3) go back where
you came from..."

If the browser handles the fact that there are options, as it already
needs to do for flowto, then the user doesn't need a lot of magic
keystrokes.

Another example is a menu for a voicemail system. The user might know the
keystrokes in advance and be able to skip through the whole thing in half
a second, or they might have to listen to all the options. Likewise a lot
of mobile phones from 2 decades ago had complex option setting which
expected power users to learn the options and simple users to just
navigate successive menus. (Modern phones dropped the mechanisms for power

users).

[[There are complications for flowto in graphics that don't exist in HTML.
A low vision user using AT working with a network diagram may not be able
to tell which of the links/other nodes the list of choices is presenting as
the accessible name of the target may not be visible on the diagram.
Another difference, is the connector object enabling the flowto (often an
arrow) may carry information - for example the width or color of the arrow
may be based on the value in a data column. This additional information
needs to be presented to the user as it could affect the path they want to
take. In graphics, the connector may need to be a flowto target as the
connector can have semantic meaning, can carry additional information and
can be interactive. If the connector has a link, the user needs to be able
to get to the connector to use the link. Connectors and flowto can get
pretty messy in graphics.]]


Anyway, I'd love to get more issues filed on the worked examples. Thanks
for taking the time to play and write.

> I made something like this, mostly just for thinking my way through:
> http://svg-access-w3cg.github.io/use-case-examples/sparse-chord.svg

>
> It shows there are some issues for making visual representation and
> navigation match, especially when what I really want is a connector.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com



Ô