Talk:SVG Accessibility/Navigation

From W3C Wiki

Comments on Amelia's Proposal & Related Brainstorming

Amelia wrote: How should the browser convert the position of a shape to a point on a scale? Using the nearest edge of the bounding box? Using the center of the bounding box? I would argue for the center, since it is more consistent across different graphic types, and the position would be the same regardless of which direction you're moving.

I second using the center of the item for calculating movement when using directional arrow keys. However, the center x of a line/area in a line/area chart will be the same for all (continuous) lines/areas, which users seldom realize. Lines/areas present non-intuitive answers in center y as well. Discontinuous lines/areas may also give non-intuitive center y values. Paths with disjoint parts can provide centers not in any part. Even though, these are know problems, using a center point is better than alternatives.

I do not support trying to relate an SVG drawn location (x,y) to a scale. Trying to relate a graphic position (x,y) to a scale requires understanding the data model. Some graphics use coordinates that were generated using FFTs, deconvolution, transforms or projections. Scales in charts may be categorical, ordinal or numeric. Interpolating a (center) y value into a categorical or ordinal value can produce incorrect answers. Non linear scales (log, e) are often used. Coordinate systems do not have to be Cartensian (rectangular); polar, (map) projections, hex, and homogenous coordinate systems using vanishing points are common. Any information about scale values must be provided by the author.

Supporting 8 direction navigation is no harder than supporting 4 direction navigation. The svg coordinate system can be rotated 45 degrees providing the equivalent coordinate pair (x',y') as an original x,y and the same logic used to move with x,y reused for (x',y') movement. 8 direction navigation would provide better movement in polar coordinates than 4 direction navigation. Providing keyboard support is a problem as not all keyboards may not have a numeric keypad or obvious keys to use for the off cardinal direction moves.

Amelia wrote: There is also a third type of navigation to keep in mind: pan & zoom of a visual display. This is separate, in that it is not associated with specific elements receiving focus/regard. It would not require any author or browser definition of a navigation order. However, it is relevant in that it is another complexity for user agents mapping input commands to navigation actions. How many ways can a user agent overload basic inputs such as arrow keys with extra modifiers before it becomes too complicated for users to remember?

Navigation should follow markup without regard to whether an item is in the viewbox or has been clipped. An application that has a dynamic viewbox and wants navigation to only move within the viewbox or clippath, would be responsible for designating items that are not navigable, possibly by setting their role to none and rebuilding the DOM if needed.