Fw: SVG Navigation Proposal

Existing spacial navigation work around SVG.


Rich Schwerdtfeger
----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 04/24/2015 08:15 AM
-----

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 04: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