Focus [was: Accessibility was: anchoring in svg]

Hi, Jonathan, et al-

First, let me apologize for crossposting, but I had a few questions about
focus for the WG at the end.

Jonathan Chetwynd wrote:
| http://www.w3.org/TR/2004/WD-SVG12-20040318/#focus is referred to in
| the wiki: http://www.peepo.co.uk/pmwiki/pmwiki.php/Main/SVG
| .../#focus refers only to text not graphics, and this is a significant
| weakness in a graphics technology.

I understand, from our discussions, that you are concerned with keyboard
navigation in SVG, but I think that you are misreading the 1.2 Spec as
regards the focusable attribute. You seem to be inferring that only text
elements can have the 'focusable' attribute; by contrast, the Spec states
explicitly:
    'Applies to: container elements and graphics elements'
This means that you can use the 'focusable' attribute in any container
element (<svg>, <g>) or any element that renders (including <circle>,
<path>, and <text>); thus, any of those elements can receive focus.

Perhaps you were confused by this section:
    'The value "auto" is equivalent to "false", except that it acts like
"true" for the following cases: the a element; the text and flowDiv elements
with editable set to "true"; the top-level svg element '
But all this means is that no elements except the type listed are focusable
by default (that is, text is always focusable unless actively set to
'false'); setting any element to focusable='true' means that that element
can be selected by keyboard access.

I know you would also like to see the ability to copy and paste graphical
elements. I worked up a very simple example that allows you to copy and
paste from one SVG to another, but it is proprietary to IE (that is, it uses
the Windows clipboard). I see that the Spec mentions copy/paste access to
text nodes [0], but perhaps this could be extended to allow programmatic
access, so we could expect the same behavior cross-platform?

All in all. I think that this goes a long way toward addressing your
concerns about accessibility via keyboard access. I strongly suggest you
read the entirety of the CSS3 chapter 8.2. Keyboard control [1], which SVG
1.2 references, and if you find that it is lacking from an accessibility
standpoint, point out what specific problems you see.

This is not to say that this is the only (or even the optimal) method for
navigation. But it is wholy consistant with the established HTML model,
which you have said your clients/students are familiar with. I think that
Jan-Klaas has raised a very interesting point about heirarchical navigation;
I think a possible way out of this would be to extend the 'nav-index'
property to take a different argument than an integer, to reflect relative
groupings (that is, for example, in an SVG with several dialogs comprised of
nested elements: the first dialog might have nav-index='1', its first child
might have nav-index='1.1', and that child's fourth child might be
nav-index='1.1.4' ...   tabbing would work within a nesting level until you
navigated to the next level up).

While we're on the subject, I do have a few questions for the WG as regards
'focusable':

1) The Spec currently uses the term "tab key"; I understand that this is
temporary language that stands for whatever device-dependent navigation
method is available. But my question is, are we to anticipate that this will
recommend to the UA developers that the tab key is available? Currently, you
can't use the tab key in ASV3/6pr1, so if you could, it would be great. If
this is the case, will it be available to keyboard events in JavaScript? I
only ask because DOM3 Events (yay!) specifically mentions altKey, ctrlKey,
metaKey, and shiftKey, but I couldn't find anything about the tab key (nor
about mouse scroll events, to my dismay).

2) What sort of behavior can we expect when an element that has
focusable='true', and a nav-index value, but which also has display='none',
visibility='none', or opacity='0'. I anticipate that display='none' would
simply not take focus, since the element isn't rendered. The other two are
trickier, though. It would be confusing to a user to tab onto one or more
invisible elements (as on a hidden dialog). I guess the author could simply
take care to set focusable to false? In any case, I'd like to see this
explicitly described (unless I'm missing it somewhere in CSS).

3) I'm *very* glad to see that you are including the 'key-equivalent'
property from CSS3. I think it will be very practical to allow the author to
specify what happens when those keys are pressed (for example, mapping one
key to trigger a menu, or using 'page-down' to navigate slideshows or
multipage documents). At least, this is how I'm thinking about it, but I may
not understand it. Is it possible to include some explicit examples of this
in the Spec?

4) Are you planning on including the directional focus navigation properties
from CSS3? I owe that they seem to be more related to interdocument
navigation, but they can be used within a document, and I thought this might
be one way of dealing with the heirarchical navigation issue that Jan-Klaas
raised (specifically nav-up and nav-down). They could also be used for
multipage documents.

Regards-
-Doug

[0] http://www.w3.org/TR/2004/WD-SVG12-20040318/#editable-attribute
[1] http://www.w3.org/TR/2003/WD-css3-ui-20030703/#keyboard

Received on Sunday, 28 March 2004 06:19:56 UTC