Re: [ARIA] Agenda: March 3, 2016 WAI-ARIA Working Group

Hi Fred,

On 2016-03-04 12:43 PM, Fred Esch wrote:
> For SVG it is imperative that an author be able to mark an element 
> with the role none or presentation and know that the element will not 
> appear in the accessibility tree. SVG is too messy to force authors 
> and authoring tools to work through anything but the simplest rule.

Given the current specification of how the presentation/none role works, 
the way the author ensures that the element will not be exposed is by 
making sure that the element is not focusable, will not incur an 
accessibility event, and/or does not have any global aria-* attributes.  
If the developer configures the element as such, and adds role="none" to 
it, then the element will not appear in the accessibility tree.  In 
short, it's the author's responsibility to use the correct kind of 
element, not add @tabindex to it, nor any other aria-* attribute if they 
want it excluded.

Regarding your two use cases, by "group element" do you mean the <g> 
element?  Based on the svg-aam, that element is generally not mapped, 
meaning it doesn't even need role="presentation" to exclude it from the 
tree [1] (my emphasis):

" group role mapping if the element meets the criteria for Including 
Elements in the Accessibility Tree; otherwise, *no accessible object 
created*"

For Case 1, is the group element focusable, TAB navigable, clickable, or 
otherwise interactive?  Does it have any aria-* attributes?  Is the <g> 
element given a role other than presentation/none?  If the answer is 
"no" to all these questions, then the group element won't be exposed 
(there won't be an accessible object in the a11y tree).

For Case 2, you imply there is interactivity with the <g> element in the 
form of navigation.  It may also have some aria-* attribute(s) or a role 
other than none/presentation, although I can't tell without more 
information.  Assuming some or all of these holds, then it will be 
included in the accessibility tree.

I don't see any issue or inconsistency between the current specification 
of presentation/none and your two use cases.  It looks to me like you 
have everything you want -- where is the problem?

> The SVG accessibility task force decided that using a role of none or 
> presentation was the golden hammer that developers and authoring tools 
> need to exclude elements from the accessibility tree. Amelia is add 
> the changes in. If we need to change the ARIA spec lets change it.

To use your terminology, there is no golden hammer.  One of the 
principles of ARIA is that it does not change the browser's user 
interface.  For example, if an element is focusable, TAB-navigable, or 
clickable, then putting role="presentation" on it will not change its 
interactive nature.  Users can still TAB to it, or activate it by mouse 
or keyboard regardless of an additional presentation role. As such, it 
must have some representation in the accessibility tree.  If the author 
truly intends for that element to have no semantic impact, then it's 
their responsibility to construct the element such that it is, in fact 
meaningless.  That entails that they do not add any aria-* attributes to 
it, since, by doing so, they would be adding semantic information.  If 
authors properly configure a semantic-free element, then adding 
role="none" will do what you want, if it is needed at all.

[1] 
http://w3c.github.io/aria/svg-aam/svg-aam.html#mapping_role_table#role-map-g


-- 
;;;;joseph.

'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
                  - C. Carter -