Re: link navigation

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. 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.

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. Hitting the ENTER key turned
chords gray on Chrome. I don't have a clue as to what that is supposed to
mean. 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.  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. 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. However, sighted
users don't have a natural or learned association for using connectors.
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.  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.
                                                              
     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, "Chaals McCathie Nevile"
            <chaals@yandex-team.ru>
Cc: "SVG-A11y TF" <public-svg-a11y@w3.org>
Date: 11/01/2015 02:06 PM
Subject: Re: link navigation



On Tue, 20 Oct 2015 06:46:53 +0900, Chaals McCathie Nevile
<chaals@yandex-team.ru> wrote:

> This is trivial to represent as a sparse table, although a little
> clunkier on the Web where table markup is pretty simplistic. You place
> the cost as
> row headers, in decreasing order. You place the number of deaths as
> column headers, in increasing order.
>
> Alternatively you make a chord graph, with the left-hand-side
> representing the total cost, and the right-hand side the total number of
> deaths. My current thinking on how to lay it out is to split the
> connectors into two pieces.
> If you keep the deaths/costs axes vertical and use quadrilateral
> connectors, I would split them into triangles (by diving the
> quadrilateral daigonally, from axis to axis, and then adding a line
> around the quadrilateral so the bounding box - and therefore the focus
> ring - covers the whole thing. You would be able to navigate up and
> down each axis, or follow a link from one axis to the other.

I made something like this, omstly 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.

More thinking to come…

cheers

Chaals

> The height of the quadrilateral on each side would be the width of the
> blocks in the current diagram.
>
> The logical extension of that pattern to this graph is that you take the
> connectors as they currently are, and do the topologically equivalent
> division - i.e. you need a cubic curve between the top left and bottom
> right corners of each.
>
> The difficulty is not in how too put together the graph, it's just in
> getting the curves and then splitting them diagonally. The rest is work.
>
> So you would have:
>
> list, 8 items
>    first item list 2 items:
>       breast cancer, $256M
>       Link to death numbers: 41k, 3rd
> second item list 2 items
>      prostate cancer $147M
>      Link to death numbers: 21k, 5th
> third item list 2 items
>      heart disease $54M
>      Link to deaths: 600k 1st
>
> etc, until you got to the second list, which was death rates, linking
> back
> in the analgous way, e.g.
>
> list 8 items
>    first item list 2 items
>      heart disease 600k
>      link to cost: $54M, 3rd
>    second item list 2 items
>      COPD 143k
>      link to cost: $7M, 6th
>
> Note that all the numbers, the ranking, and also proportional comparison,
> can be calculated from the figures provided which were presumably used to
> generate the chart. I.e. it can *all* be done automatically, given the
> set
> of numbers.
>
> A more interesting question is whether you can do something smart at the
> point where the paths cross over, for people who are using a pointer. But
> nothing interesting springs to mind.
>
> cheers
>
> On Mon, 19 Oct 2015 22:44:12 +0200, Fred Esch <fesch@us.ibm.com> wrote:
>
>>
>> Chaals,
>>
>> I pulled this image from Graham Will's blog Working Vis. Since Graham is
>> doing Brunel Visualization language we could probably get an SVG of it.
>> In any case, it would be difficult to >make a useful link based
>> navigation using tabindex for something like this. Chord charts would be
>> difficult also.
>>
>> Here is a summary of the image. The image consists of two columns with
>> (the same) eight diseases listed in each column. Both columns are
>> independently sorted. The left column is >sorted by the amount of money
>> spent on (I am guessing research) on the disease and the right column is
>> sorted on the number deaths from the disease. The diseases are
>> represented by >rounded rectangles with their area/width (height is
>> constant) proportional to the amount of money spent (left column) and
>> number of deaths (right column). Each disease is also labeled >with the
>> disease name and amount of money (left column) and number of deaths
>> (right column). The diseases are color coded and the a thick semi opaque
>> gray (curvy) line connects the >same disease in both columns. As it
>> turns out, none of the connecting gray lines are horizontal, they either
>> go up or down.
>>
>>
>> Another interesting thing about this chart is I don't think it would
>> work well as a table. You could invent a dollars/death ratio to keep a
>> disease in a single row, but then you could not sort by >both factors
>> independently.
>>> Regards,
>>
>> Fred EschWatson, IBM, W3C >Accessibility
>>
>
>>
>>
>
>
>


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



Ô