RE: should element with focus be within client window?

Hi, Jonathan-

I always count on you to keep us honest and aware on matters of
accessibility. Many thanks. I'll reply inline...

Jonathan Chetwynd wrote:
| 
| should element with focus be within client window?
| 
| how do people navigating SVG using the keyboard know which element  
| has focus?
| 
| for example: using mozilla, opera, safari-webkit etc visit
| http://www.peepo.com/index-html-svg.html
| zoom until a single graphic fills the page
| then tab through the links.
| 
| each graphic with focus fills the client window in turn.
| 
| Contrast this with http://www.peepo.co.uk/index.svg
| 
| in each case apart from the initial graphic the user will have no  
| idea which graphic has focus, due to the focus being outside the  
| client window.

Just to give some background here, previous versions of the spec (SVG1.1)
did not have much of a concept of focus.  They did mention it in the context
of focus events (particularly on text) and of pointer-event and the CSS
:focus pseudo-class, but the spec did not mandate any particular behavior,
relying instead on UA implementations to do whatever was appropriate for
their platform, and allowing the author to build a custom solution relevant
to the particular document (via the focus events).  Nor did SVG 1.1 specify
navigation behavior.

However, that did not turn our as universal optimal behavior by default
(neither for accessibility nor for typical usage), so the SVG WG was more
explicit in SVG Tiny 1.2, while still allowing UAs to decide upon the
specific mechanism.

According to the Navigation behavior section [1]:

"The SVG User Agent must allow navigation to elements which are located
outside of the current viewport. In this case it is recommended that the SVG
User Agent should change the current viewport so that the focused element
becomes visible."

I hope this addresses your concern for future implementations.  

Since the browsers you mention are probably working on 1.1, however, they
won't yet have the navigation and focus behavior from 1.2.  But you could
script the behavior in (not ideal, but workable), or request that feature
from the browser builders... there's nothing in SVG1.1 that prevents that
functionality, and it would be useful.


| my apologies if this is in the spec. I do have recognised problems  
| with the whole w3c process.

I wouldn't say the process was at fault.  It would have been natural to
assume that in the climate of the time that UAs might emulate the behavior
described in HTML4 for tabbed navigation (though as the optional tabindex
wasn't specified in SVG, it may have been an oversight... dunno, wasn't
there).  But there was a fallow period for browsers right around that time,
and SVG wasn't widely implemented natively until fairly recently; since the
primary SVG viewers were not also HTML viewers, navigation and focus seemed
to get lost along the way.  But the SVG developer community (including you
and me and many others) noticed the absence, and the SVG WG responded by
adding in explicit navigation and focus behavior.  Isn't that the way the
process is supposed to work?

Mind you, it *was* far too slow.  But it's often hard getting large groups
of people to agree.  Wouldn't you agree?


| mozilla zoom is currently disabled or broken..

I wasn't aware that Mozilla ever had zoom or pan.  It does zoom rasters, but
not SVGs.  In fact, under the hood, Moz doesn't even have a context menu
flag to indicate that an SVG was clicked on, like it does for rasters,
framed content, and MathML [2].  I'm working on that, though.

[1] http://www.w3.org/TR/SVGMobile12/interact.html#navigationbehaviour
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=348755

Thanks-
Doug, on behalf of the SVG WG

Received on Friday, 25 August 2006 04:22:42 UTC