Description
(copying over an issue / request for feedback from the spec)
SVG Views provide a functionality unique to SVG, with no direct equivalent in HTML documents. They may be used as the end-point of a navigation action, but are not themeselves a container for the targetted content. They may also be used at the time an SVG document is embedded, to subset the visual content to only include a portion of the file.
The editors would be very interested in practical examples of SVG views in use, so that we may determine if the above requirements are sufficient. Particular issues to consider include whether special rules are required for managing keyboard focus, or for excluding content that is rendered offscreen when a view is in effect.
In addition,
the viewTarget
attribute,
and the corresponding parameter for SVG view fragments,
has been deprecated in SVG 2.
Their intended use,
to trigger visual styling changes in the target element,
has never been well implemented by user agents.
Without viewTarget
, there would be no native way in SVG to indicate
the semantic target of a given view.
For view
elements
(but not view fragments),
a possible alternative is to encourage
authors to directly specify aria-flowsto
attributes.
These would then need to be mapped to the relevant svg
element.
This raises the question of whether any other (or all) ARIA attributes
should be mapped from the view
element
onto the accessible object for the svg
element
while the view is in effect.
This would require careful consideration
of all possible consequences and conflicts.
For example,
should a view be able to change the role of the SVG element?
The aria-flowsto
attribute is not well supported in assistive tools;
there have been proposals to deprecate it in a future version.
Are there other ways in which user agents could expose the changed view,
so that users of assistive technologies can quickly understand
which parts of the graphic are visible?