Re: SVG Navigation Proposal

For SVG, I think it is important to ensure navigation can stay within a
chart feature and not move out of the chart feature by default. I am
defining a chart feature to be a single data element - such as the set of
points in a scatter plot, or the bars in a bar chart. Other features are
guides like axes, grids and legends. Again, normal behavior when navigating
is to not leave the feature to go to another feature, when the user wants
to move features they must signal that the want to shift to another
feature.

Some charts have hierarchical features, for instance all the bars are part
of the same feature in a stacked bar chart, but you have two levels - the
stacks and the bars making up a stack.  You should keep navigating through
stacks of bars when you are at the stack level and the user should signal
when you want to start moving within a stack. When moving within a stack
you shouldn't be allowed to jump to another stack, for that you need to go
back up to the stack level. Another way to describe hierarchical navigation
is by thinking about the feature as a tree structure. And movement is
always - you can move among sibling branches,  you can signal you want to
change levels and move up to your parent, or signal you want to change
levels and move down to your children. But you can't hop to a cousin branch
that does not have the same parent, to reach the cousin, you have to go to
up the tree to a common ancestor and back down.  An example of charts that
can have multiple levels in the feature are clustered bar charts. You can
cluster by as many variables as you wish (although as a practical matter
you will rarely see clustered charts with more than 3 levels of
clustering).

For blind users, this form of navigation allows them to pick up the
inherent organization of the feature, and I include summary information
such as a total for that level (imaging not providing a blind user the
total for a stack in the stacked bar chart and making them walk the members
of the stack adding them up to get the total sighted users visually see).

A side effect or maybe a feature of this type of navigation is that - above
the leaf level, a group of objects are grouped together as one object and
treated as one for navigation purposes.   And when you drop down a level
the individual members of the group are navigated. Groups work nicely for
this, since you can provide your summary information (ie stack total) to
the group.

Lets not forget these types of considerations as we discuss navigation.

                                                              
                                                              
                    Regards,                     Fred         
                                                              
                   Fred Esch                                  
       Accessibility, Watson Innovations                      
    AARB Complex Visualization Working Group                  
                     Chair                                    
        W3C SVG Accessibility Task Force                      
                   IBM Watson                                 
                                                              
                                                              






From: Florian Rivoal <florian@rivoal.net>
To: Doug Schepers <schepers@w3.org>
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, public-svg-a11y@w3.org
Date: 04/23/2015 05:29 PM
Subject: Re: SVG Navigation Proposal



> On 17 Apr 2015, at 15:05, Doug Schepers <schepers@w3.org> wrote:
>
> Hi, Rich–
>
> Thanks for pulling this together.
>
> I had a short conversation with Florian Rivoal (CCed), the editor of the
CSS-UI L4 spec, and we talked about focusability in CSS, including the
notion of a 'focusable' property (to reflect the existing state in CSS),
and about depth/nesting. He's agreed to join a future telcon with us to
help coordinate.
>
> I propose that the implicit "semantic" mechanism for the focusability of
an element be the following:
> * textual elements
> * links (<a>)
> * any element (including <g>) with a <title> or <desc> immediate child
>
> We can also allow explicit focusability, but the default should just fall
out of the model.

Hi Doug and Rich,

Sorry for the long delay before getting back to you, I've had a crazy week.

In the HTML/CSS side of the world, some user agents have spatial
navigation,
allowing the user to use directional input (e.g. shift + arrow keys)
to move the focus between elements which are focusable according to the
semantics of HTML (buttons, links, things with tab-index, etc)

The logic seems similar to what you're proposing with your implicit
semantic mechanism for focusability.

I've blogged about the implementations I know about and how to use them:
http://florian.rivoal.net/blog/2015/04/controlling-spatial-navigation/


I recommend you use Opera 12 to try this out. To my knowledge it's by
far the best implementation in a desktop browser.

While it is easy to determine which elements are focusable once the
language
semantics are in place, it turns out that finding which of the focusable
elements you should navigate to when going from another one in a particular
direction is actually very hard. Most pages are far from a neat grid of
well aligned focusable elements, and when you add overlap, overflow,
z-index, transparency, transforms, animations, etc, the heuristics UAs
need to use get pretty complicated, and it is not rare that they fail
to do what the author would have wanted.

To address this problem, and also to enable things that could not be
deducted
from the spatial organization of elements (e.g. moving to the right from
the
rightmost image in a carousel should bring you to the leftmost, and vice
versa),
CSS has introduced 4 properties: nav-up, nav-down, nav-left, nav-right.

http://dev.w3.org/csswg/css-ui/#nav-dir


Assuming conveniently placed IDs, they can be used like this to go
solve the example given above:

  #rightmost { nav-right: #leftmost; }
  #leftmost { nav-left: #rightmost; }

There's one complication that has come out of this, though. If the element
targeted by one of this directional navigation property is focusable
according to the host language semantics in the first place,
everything is fine. But what if it's not?

The behavior we have specified, to follow what current implementations do,
is that it becomes focusable. But we have considered one other behavior
which we believe may be useful in some cases: when attempting to move
the focus to a non focusable element, traverse the dom (including
children) starting from that element, and focus the first one you
find that is focusable.

This could for example be used if you want to focus the first form
control of a form, without having to worry about how the form is
structured. Just set the form itself as the target of the navigation,
and since it is not focusable, the focus will instead fall
on the first focusable child element of the form, presumably one
of the form controls.

Since we believe both of these behaviors are potentially useful in
different contexts, we've been considering adding a focusable property
along these lines:

focusable: auto | true | false
(initial is auto)

auto:  the element is focusable according to the semantics of the
       host language, or if it is the target of directional
       navigation
true:  the element is focusable
false: the element is not focusable. Attempting to focus it
       through directional navigation focuses the first focusable
       element found by traversing the dom starting on this element,
       starting with its children

Another thing being considered is nav-prev and nav-next, which
would influence the ordering of tab navigation without relying on
a global tab index, which is in retrospect a rather poor design.
The focusable property is equally relevant to this.

All of this seems completely applicable to SVG, so I'm happy to discuss
this with you at a teleconf at your convenience.

 - Florian