The view element - SVG Accessibility API Mappings

The SVG <view> element provides a functionality completely different from
anything in HTML, and therefore from anything considered in core ARIA and
accessibility mappings.  To recap:

   - A view element does not contain any content that is directly displayed
   on screen.
   - A view, however, *changes* what is displayed on screen, by altering
   the region of the SVG displayed to visual users.
   - The view works by over-riding certain attributes on the root <svg>
   element (the specs say "nearest ancestor" svg element, but this is not well
   defined or implemented).
   - The view is triggered by following a link with a target reference to
   that view's id, or by using a URL with that target fragment to embed an SVG
   as an image/object in a web page.
   - A view element may have a title and description.
   - The SVG specs include a viewTarget attribute that allows the author to
   specify the ID(s) of one or more elements or groups that are the main
   object of that view.  In practice, however, this is rarely used because it
   currently has no impact in any user agent, visual or otherwise (to my
   knowledge).
   - Instead of using a view element, views can be constructed dynamically
   using the svgView target fragment syntax, which includes all the view
   attributes within the document URL.  There is no way to include a title and
   description in this case, although you can specify a viewTarget.

Practical uses of SVG views include zooming in on specific features of a
map when the user follows a link in a legend or label, or displaying a
single icon from an SVG document that contains many different icons within
an <img> element of a larger web page.

Because views can change which part of a document is displayed, and because
they can be the target of links, they cannot be ignored when creating an
accessible representation of the document.  However, it does not make sense
to talk about a view as a node in the accessibility tree.  Instead, a view
is more like a modifier of the root <svg> element.

So I think the logical strategy would be:

   - When a view is in effect, and that view has an accessible name or
   accessible description, use those values to replace the name/description of
   the root SVG element.
   - If a view comes into effect, or ceases to be in effect, during the
   life of a document (this would usually happen when following an internal
   link), treat this as a modification of the root SVG element.
   - When following a link to a view, treat it as a link to the (modified)
   document root.
   - Treat viewTarget as an implicit aria-flowto relationship on the
   modified root, so that after re-orienting to the new document view as a
   whole, the reading order naturally follows to the targetted element(s).
   - In addition, the user agent would adjust its determination of which
   elements are showing or offscreen according to the results of the view.
   I'm not sure if any special instructions are needed for this.

Does this make sense to those of you who regularly use screen readers?  Is
the aria-flowto behavior well supported?  Could we make it obligatory
(i.e., only treat a link to a view as a link to the root if you can then
present the user with flowto options)?

Some consequences of the above would be:

   - If the author has not added any accessible information to the view, a
   link to the view would effectively be treated as a link to the top/root of
   the document.
   - If the author has added title and/or desc to the view but not
   viewTarget, a link to the view would be treated as a link to the root of a
   modified version of the document with different alternative text.
   - If the author has added viewTarget information, but has not provided
   an accessible name or description for the view itself, a link to the view
   would jump to the top of the document, repeat the document name & maybe
   description, then give the user the option to flow back to the actual
   targetted content.

The last example is not ideal, but any other strategy I think of only
increases the complications.

Once we clearly define the expected behavior, we can give better guidance
to users about avoiding the most awkward situations.  And also about
providing good fallback.  For example, if the author places the view
element just before the target elements in the DOM, a user agent that
applies standard rules for following links will still flow from the linked
view element to the target.

For the SVG Accessibility API Mappings document, there are a number of
places where these behaviors would need to be mentioned:

   - We'd probably want to add a general definition of view / active view.
   - In 5.1 (General rules for exposing WAI-ARIA semantics), the view
   element would be listed as something that should be excluded from the
   accessibility tree.
   - In 5.5 (State and Property Mapping), an explicit mapping would need to
   be specified for the viewTarget attribute.
   - In 5.6.1 (Name and Description Computation), we would need a specific
   exception/alternative rule for the root element if there is an active view.
   - In 5.8 (Events), we would need to define activating a view as a set of
   property changes on the root element.

It's kind of spread out everywhere, but that is an unavoidable consequence
of following the document structure of the Core mappings spec.

Once we have a clear resolution on how things should behave, I'd be happy
to draft the text.

Best,
Amelia BR