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

Everyone if you have an opinion or issue with the changes please respond on
list if possible so we can think about it ahead of time.

Amelia,

Can you list the open issues (not typo fixes) so we can capture them for
the agenda?


I disagree that cartographers would use a single object for mapping objects
with multiple disjoint parts - like islands. There are several reasons for
not using a single polygon in a vector product:
   Data is not collected as a single polygon
   Generalization is done for each scale
   Generalization includes simplifying polygons and dropping small features
   (ie islands)
   When you have a zoomable map, you may use a switch to drop small
   features (ie islands)
   Creating a single polygon might impact you ability to support all your
   requirements (ie making all navigation hazards a single polygon would
   not help marine navigation avoid them)

You may see cases where maps have been scanned and a single polygon is
produced for a complex object. But I doubt any organization that produces
vector map products would do that.  That said, you may find feature parts,
like an elevation contour which can include disjoint parts as a single
object. It all depends on the requirements and usage.

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






From:	Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To:	Fred Esch/Arlington/IBM@IBMUS
Cc:	SVG-A11y TF <public-svg-a11y@w3.org>
Date:	05/19/2016 05:08 PM
Subject:	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 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.