Re: SVG Navigation Proposal

These constraints on navigation that you are describing are not part of the css properties I talked about, but they seem compatible with them.

The css properties assume that the host language has it's own focusability semantics, and that either the user agent alone, or the user agent
and the host language, have a default spatial navigation behavior.

The properties then come on top of that to allow the author to override this behavior, either in terms of which element to navigate to (existing nav-up, nav-down, nav-left, nav-right properties), or of which element can be focused (upcoming focusable property).

In the absence of these properties, the normal SVG behavior prevails. And if the author uses the properties to do something that wasn't part of the original model (for example navigating out of a chart feature into another one), I am not sure this is an issue, given that this is an explicit instruction from the author.

 - Florian


> On 24 Apr 2015, at 14:40, Fred Esch <fesch@us.ibm.com> wrote:
> 
> 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 Esch 
> Accessibility, Watson Innovations
> AARB Complex Visualization Working Group Chair
> W3C SVG Accessibility Task Force 
> <1F046871.gif>
> <1F439046.jpg>
> 
> 
> <graycol.gif>Florian Rivoal ---04/23/2015 05:29:09 PM---> On 17 Apr 2015, at 15:05, Doug Schepers <schepers@w3.org> wrote: >
> 
> 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/ <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 <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
>