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

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

And in section 5.1.1 Excluding Elements from the Accessibility Tree it
states:

For the purpose of SVG, an element is considered hidden if it is neither
visible nor interactive, and is therefore not perceivable to visual users.
User agents SHOULD NOT expose to accessibility APIs any element that is
hidden in this sense. This includes graphics elements 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:
      a value of hidden for the visibility property
      a value of none for both the fill and stroke 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 23t connection with the sensor is
broken and the value recorded in the log is - 23t 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 23t through 28t 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 23t through 28t 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.

                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality