Re: [aria] SVG-AAM: Consider explicit language regarding objects with presentational role and aria-label (#136)

Joseph,

I hope Amelia or Rich jumps in on what is supposed to happen with events.
In SVG we may put an event handler on an object that is not visible to a
sighted user (transparent paint, no border) because it gives the mouse
using sighted user a bigger area to click on. Likewise CSS can add hover
events to a transparent, no border - non visible to a sighted user object,
again to provide a bigger area to get a tool tip response from.

We may not want focus on the larger non visible to a sighed user object and
we may not want the larger non visible to a sighted user object in the
accessibility tree, rather we want the real small, correctly
labeled/described/relationshipped object in the accessibility tree.  SVG is
all about visual presentation and we need to provide an understandable way
for authors to enable AT support at the same time they are improving
behavior for folks with older shaky hands with less precise motor skills.
We need magic hammers like role none to work.  Otherwise authors will
reasonably give up on trying to get that darn diagram accessible.

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






From: Joseph Scheuhammer <notifications@github.com>
To: w3c/aria <aria@noreply.github.com>
Cc: Fred Esch/Arlington/IBM@IBMUS
Date: 01/11/2016 10:52 AM
Subject: Re: [aria] SVG-AAM: Consider explicit language regarding
            objects with presentational role and aria-label (#136)



@fredesch,


      It is imperative that an author know role none is the magic hammer
      which absolutely keeps an
      element, but not necessarily their children out of the accessibility
      tree.


Two things: First, what @Joanmarie has uncovered in her research is that
the ARIA spec appears to contradict this, since, as she quoted, it does say
(paraphrase) that even if role="presentation" or "none", if the element
also has a global ARIA property, that property MUST be exposed. What is
unclear is how said exposure is accomplished. It might mean that the
presentation role is ignored, and an accessible is created. Or, it might
mean that the global properties are exposed on an existing accessible,
possibly the parent accessible. At the very least, something needs to be
added to the specification of presentation/none to clear this up.


Secondly, the magic hammer is not absolute when it comes to events.
Although this is somewhat unrelated to the issue at hand, if the element
has a @tabindex on it, or an @id that designates it as a potential active
descendant, or has a click handler, or other event handler, then the
element can cause accessible events. Accessible events have a source
accessible object associated with them (X just gained focus, X was just
selected, X's value just changed, etc.). In that case, the
presentation/none role is ignored as an author error since the browse can't
help but emit the events.


—
Reply to this email directly or view it on GitHub.


Ô