- From: Doug Schepers <doug.schepers@vectoreal.com>
- Date: Fri, 25 Aug 2006 00:22:24 -0400
- To: "'Jonathan Chetwynd'" <j.chetwynd@btinternet.com>, <www-svg@w3.org>
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