Re: SVG AAM Data and rendering - Amelia's changes review part 2

(I touched on this topic in my reply to Fred's first email [1], but it's
worth more careful discussion.)

The guiding role for creating the accessibility tree is that it should
reflect the content as able-bodied users experience it. If an author wants
to present a complete data set including missing data, they need to make
that content available to all users, not hide it in the markup of a graphic.

The references to "rendered elements" were added to remove a lot of the
complexity from previous drafts.  It allows us to remove all sorts of
explicit rules for different cases.  Some elements are never rendered,
other elements are not rendered because of a never-rendered ancestor, other
elements are not rendered because of conditional processing attributes
and/or a switch element, and other elements are not rendered because of
display: none.  By referencing the new SVG 2 definitions of "rendered
element" and "non-rendered element", we cover all these cases, and any
future ones, with a single word.

Elements can be *invisible* and yet still be *rendered* from the
perspective of the user agent.  Some invisible elements are considered
hidden from assistive technologies, some are not.  The rules for
determining whether something is hidden are based on the existing
pointer-events property, and only include properties with discrete keyword
values for the invisible state (visibility: hidden and fill/stroke: none).

These rules are *much simpler* than the rules user agents currently use to
determine whether HTML content is hidden or not.  Properties you would
likely to animate, such as opacity and geometry (width, height, etc), are
not used to determine if something is hidden.

Invisibility can be over-ridden by adding interactivity, or by adding
aria-hidden="false".

Non-rendered elements are never interactive.  ARIA theoretically allows
non-rendered elements to be included with aria-hidden="false", but this is
really problematic for user agents, and ARIA currently warns against it.


*All that said:*

I would be willing to remove the dependence on fill/stroke: none.  It adds
a lot of extra complexity for what are likely to be relatively rare use
cases (an author using these properties to hide content).  Even as I was
writing this, I realized an additional complication that I had not factored
in: markers.  A path can have no fill, no stroke, but still be visible
because of markers.  (I've pushed edits for that).

I'm interested in other opinions: should we keep the rules simple, even if
it means that some elements are not hidden as the author intended?



[1]: https://lists.w3.org/Archives/Public/public-svg-a11y/2016May/0024.html


On 19 May 2016 at 07:40, Fred Esch <fesch@us.ibm.com> wrote:

> All,
>
> The SVG AAM suggests that something must be *rendered* to the screen in
> order for it to be passed to the accessibility tree. In section 5.1.2
> Including Elements in the Accessibility Tree
> <https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html#include_elements>
> it states. (Yellow highlighting and bold italics on word rendered is my
> emphasis).
>
> SVG user agents *MUST* provide an accessible object in the accessibility
> tree for *rendered* SVG elements that meet any of the following criteria,
> *unless* they are excluded from the accessibility tree per the rules in *Excluding
> Elements from the Accessibility Tree*
> <https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html#exclude_elements>
>
> And in section 5.1.1 Excluding Elements from the Accessibility Tree
> <https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html#exclude_elements>
> it states:
>
> For the purpose of SVG, an element is considered *hidden*
> <https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html#dfn-hidden> if
> it is *neither* visible nor interactive, and is therefore not
> *perceivable*
> <https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html#dfn-perceivable>
> to visual users. User agents *SHOULD NOT* expose to accessibility APIs
> any element that is hidden in this sense. This includes *graphics
> elements* <https://svgwg.org/svg2-draft/struct.html#TermGraphicsElement>
> that have the following computed style values, *unless* the element can
> receive user input (pointer events or keyboard focus) as described under *Including
> Elements in the Accessibility Tree*
> <https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html#include_elements>:
>
>
>    - a value of hidden for the *visibility*
>       <https://svgwg.org/svg2-draft/painting.html#VisibilityControl>
>       property
>       - a value of none for *both* the *fill*
>       <https://svgwg.org/svg2-draft/painting.html#SpecifyingFillPaint>
>       and *stroke*
>       <https://svgwg.org/svg2-draft/painting.html#SpecifyingStrokePaint>
>       properties of text or shape elements
>
>
> Note the last bullet states if shape's fill is none and the shape's stroke
> is none - the shape (and it's associated data) should not be passed to the
> accessibility tree.
>
> I do not believe being *rendered* should be a factor on whether something
> is passed to the accessibility tree or not. If a user adds an aria-label to
> a shape that has a stroke of none and fill of none, the data/aria-label may
> still be important information for the user. Missing data and no response
> data might not *rendered* on a chart. When missing/no response data is
> not rendered, it does not mean a visual graphic/chart/map user won't be
> aware of the missing/no response data and isn't prevented from being aware
> of the significance of the missing/no response data. Here is an example,
> you have a monitoring system that plots a dot for the value of a sensor at
> every time interval* t*. Just before time 23*t* connection with the
> sensor is broken and the value recorded in the log is - 23*t* missing.
> Since the data is missing, a dot is added to the SVG graphic with a stroke
> and fill of none and an aria-label 23 t (missing). A visual user of the
> monitor can see that at 23*t* through 28*t* there is a gap in reporting
> from the sensor and can verify this by looking at the log. Someone using
> the accessibility tree would not know what happened between 23*t* through
> 28*t* if the data associated with the dot (with fill none and stroke
> none) were not passed to the accessibility tree. Another example, an
> aeronautical chart with a blank space in it, lets the pilot know that the
> area has not been mapped and therefore the pilot will not know how many
> vertical obstructions exist in the area and won't know the heights of
> vertical obstructions in the area. Missing data can be very important to a
> user.
>
> The purpose of most informational graphics is to convey information and
> for graphs and maps the purpose is to convey *data* to a user through
> visual means. Often important information is not rendered but can be put in
> the SVG. All important information needs to be passed to accessibility tree
> whether rendered or not.
>
> I suggest we remove dependence on whether something is rendered for
> deciding on whether something goes into the accessibility tree. We can
> simply have inclusion based on aria properties overrule exclusion based on
> not being rendered. I do think we need a method for authors to
> include/exclude objects and since roles (none, presentation) aren't strong
> enough we could rely on display none. We do need a simple way for authors
> and script writers to show/hide data that affects both visual and the
> accessibility tree, however I do not think that stroke and fill are
> appropriate for doing this.
>
>