Re: SVG AAM feedback part 1

Hi Fred,

Thanks for all these detailed comments.

I'll reply in order. For simple typos & wording fixes, I'm also pushing
changes to the repo branch as I go.

*The change starting on line 611 about role none.*
>
> If the first mappable role provided by the author is *none*
> <http://w3c.github.io/aria/aria/aria.html#none> or *presentation*
> <http://w3c.github.io/aria/aria/aria.html#presentation>, the element must
> not be exposed. However, note that a number of features of an element, such
> as interactivity, can cause an author-supplied role of presentation *to
> not be mapped.* <http://w3c.github.io/aria/aria/aria.html#presentation>
>
> I think you need to repeat none in the second use so folks do not think
> none and presentation have a different affect.
>
Agreed.

> Using the term *to not be mapped* and where the link takes you is odd. I
> thought the link would take me to a definition of *to not be mapped*.
> Instead it goes to ARIA presentation role. I find the term to not be mapped
> confusing in this use since role none
> <http://w3c.github.io/aria/aria/aria.html#none> and role presentation
> <http://w3c.github.io/aria/aria/aria.html#presentation> use the phrase *will
> not be mapped *in the opposite sense* - *that is the element won't be in
> the accessibility tree*. *Where as your usage is saying the element will
> be in the accessibility tree. I also get the sense that the statement
> allows a non-none or non-presentation backup role for none/presentation be
> used because the first mappable role failed. Instead, I suggest the
> sentence.
>
If the first mappable role provided by the author is *none*
> <http://w3c.github.io/aria/aria/aria.html#none> or *presentation*
> <http://w3c.github.io/aria/aria/aria.html#presentation>, the element must
> not be exposed. However, note that a number of features of an element, such
> as interactivity, can cause an author-supplied role of *none *or
>  presentation to be ignored.
>
Once Rich's changes to ARIA 1.1 have been integrated, there will be a
better anchor to serve as the destination of that link.   However, I agree
with wording changes.  I've made the link start from "author-supplied"
until the end of the sentence.


> *The change starting on line 626.*
>
> In all cases, an element with not be excluded if it can currently receive
> focus based on user interaction. Consult the original document [*CORE-AAM*
> <https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html#bib-CORE-AAM>]
> for the normative text.
>
> Typo with want will
>
> A tabindex of -1 cannot currently receive focus, but I would hate to see
> elements in a chart enter and leave the accessibility tree as a polyfill
> toggles tabindex values to perform better navigation. I prefer
>
> In all cases, an element will not be excluded if it has a tabindex, can
> receive focus based on user interaction or has an aria property that
> triggers inclusion in the accessibility tree. Consult the original document
> [*CORE-AAM*
> <https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html#bib-CORE-AAM>]
> for the normative text.
>
> Typo fixed.

The distinction for elements that can *currently* receive focus is
intentional & consistent with how I understood the discussions we had in
the AAPI call.  It allows someone to disable content or make it inert by
using aria-hidden in combination with removing it from the tab index.  It
ensures that you can have pop-ups (tooltips or dropdown menus) or offscreen
content in the DOM but not currently in the accessibility tree.

Yes, there are lots of cases where you *want* elements with tabindex="-1"
to be included in the accessibility tree.  They will still be included
based on other factors, such as a role.  However, the distinction is
important because a positive tabindex overrides aria-hidden, but a negative
tabindex does not.


>
> *Question about special cases in 5.1.1 Excluding Elements from the
> Accessibility Tree *
> There are two special cases listed with bullets
>
>    - 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
>
>
> Is there a special case for mesh?
>

Honestly, I'm going to try to argue that SVG 2 should be changed so that
<mesh> is just a regular paint server. It's such a pain to have it's dual
nature.

As it stands, however, I am treating <mesh> for accessibility like an
<image>.  For this section, it would be affected by visibility but not by
fill & stroke.


> *I don't think we should include/exclude shapes in the accessibility tree
> based on style (fill and stroke) because:*
>
>    1. It assumes data in the accessibility tree *must* be tied to what is
>    visible on the screen
>    2. It assumes that if a user can't see an object, the object has no
>    significance to a user (ie by not showing Ohio on a map it gives Michigan a
>    bigger chance to win the big 10 - note, the maps they sell like this
>    haven't helped so far)
>    3. It will be a huge burden on user agents to calculate (ie
>    calculating whether Alaska is included will take checking it's 2000
>    islands)
>    4. Animation could affect the presence in the accessibility tree
>    (during the animation) of an item that starts and ends in the accessibility
>    tree or vice-versa.
>    5. Animation performance could be significantly impacted if the user
>    agent tries to keep the accessibility tree up to date with animation.
>
> The reason these properties are called out is because they affect
`pointer-events` processing and therefore interactivity.  They are
consistent with the way CSS properties are used by

If an element is neither visible nor interactive to sighted users, it seems
reasonable to assume that the author expects the content to be hidden.

Aria-hidden="false" can be used to override if this assumption is
incorrect.  *I've changed the text to make this explicit.*

If you are using the color or opacity of fill or stroke to convey data, you
wouldn't be using `fill: none` or `stroke: none`, you would be using a
transparent color value or using fill-opacity or stroke-opacity.

You make a good point that assessing the hidden status of a group
containing many elements could require a lot of scanning of the DOM.
However, I don't see that it would be any more difficult to asses fill &
stroke versus assessing visibility alone (which can also be over-ridden on
child elements).  (That said: the usual way to draw a map shape with many
islands is as a single path element with many subpaths defined in the path
data. The many subpaths don't have their own styles, so nothing to check.)

`none` is not an interpolable value, so animation performance is not an
issue.