(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?