- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Tue, 15 Mar 2016 16:14:30 -0400
- To: ARIA Working Group <public-aria@w3.org>
- Cc: "wai-xtech@w3.org" <wai-xtech@w3.org>
Link: https://www.w3.org/2016/03/15-aapi-minutes.html
Plain text follows:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Accessible Rich Internet Applications Working Group Teleconference
15 Mar 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/03/15-aapi-irc
Attendees
Present
Joseph_Scheuhammer, Bryan_Garaventa, Joanmarie_Diggs,
AmeliaBR, Rich_Schwerdtfeger
Regrets
Chair
Joseph_Scheuhammer
Scribe
Rich, joanie
Contents
* [3]Topics
1. [4]ACTION-1681 (Joseph, Amelia) Editorial change(s)
clarifying inclusions rules and/or exclusion rules.
2. [5]No meeting next week.
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<clown> agenda: this
<scribe> scribenick: joanie
ACTION-1681 (Joseph, Amelia) Editorial change(s) clarifying
inclusions rules and/or exclusion rules.
JS: Amelia is here for this action.
action-1681
<trackbot> action-1681 -- Joseph Scheuhammer to Propose new
wording, as an editorial change only to clarify the inclusion
rules in section 5.1.2 -- due 2015-09-15 -- OPEN
<trackbot> [8]http://www.w3.org/WAI/ARIA/track/actions/1681
[8] http://www.w3.org/WAI/ARIA/track/actions/1681
<clown>
[9]http://w3c.github.io/aria/core-aam/core-aam.html#exclude_ele
ments2
[9] http://w3c.github.io/aria/core-aam/core-aam.html#exclude_elements2
JS: This action is only a small slice of the issue.
... At the above spec URL, there is the excluding elements
content.
<clown> Elements with none or presentation as the first
mappable role in the role attribute string, according to the
rules for the none and the presentation role defined in
Accessible Rich Internet Applications (WAI-ARIA) 1.1
[WAI-ARIA].
<AmeliaBR> Also related discussion here:
[10]https://github.com/w3c/aria/issues/136
[10] https://github.com/w3c/aria/issues/136
JS: I noticed just recently that the first bullet point
(above), has this catch-all that I missed.
... So what the Core AAM is doing is saying none/presentation
is excluded.
... But this is modified by the rules in the spec.
... The advantage is that the statement in the Core AAM is
always correct. :)
... The disadvantage is that one needs to consult with the spec
to see what the state is.
RS: (Asks about role-specific attributes)
JS: Here is the spec text about global attributes.
<clown> "the user agent MUST always expose global WAI-ARIA
states and properties to accessibility APIs, even if an element
has an explicit or inherited role of presentation."
JS: (reads text above)
... So you want to add something for role-specific states and
properties?
RS: Yes.
JS: Where?
RS: If you have a layout table and wanted to give one of the
rows the role of region, that's doable.
... And that would cause them to be included.
... And that's covered in the spec.
... We need to cover both roles and their states and
properties.
... We need to say if you have any role attribute, whether
inherited or not, it is included in the tree.
ABR: This gets into the issue they had with the HTML mapping.
... A div/span without a role, but an aria-label needs a role
change to be included in the tree.
JS: Firefox always includes divs even without a label.
CS: IE did as well; I don't think Edge does.
JS: So non-interoperability.
ABR: I'm not sure we want to recommend every div in a document
gets exposed.
... That would be painful in some documents.
JS: Let's say all divs are not, but if you add a label it must
be included.
... In the case of ATK, the role would have ROLE_SECTION and a
label.
CS: It's group in UIA and IA2, I think.
<AmeliaBR> [11]http://w3c.github.io/aria/html-aam/html-aam.html
[11] http://w3c.github.io/aria/html-aam/html-aam.html
<cyns_>
[12]http://rawgit.com/w3c/aria/master/html-aam/html-aam.html
[12] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html
<clown>
[13]http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el
-div
[13] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-div
JS: They do have, for IA2 and ATK, may not have accessible
object if there is no semantic meaning; otherwise it's a
section.
... But if it's included due to the presence of a label, and
there's not another role, it's ROLE_SECTION.
ABR: There's the general issue of which element should be
included or excluded.
... Another issue is if you're forcing something to be included
and it lacks a role, what role should it be given?
RS: You typically fall back on the host language.
JS: You also look at the relevant AAM to figure out the role
for the host language element.
(Brief discussion that you can display script, which is not
normally exposed, via CSS)
RS: If you have an ARIA attribute....
JS: A non-global one?
RS: Are global already addressed?
JS: Yes.
CS: It would be nice to have it all in one place.
JS: I could summarize what the role="presentation" spec text
says.
... For instance, you can override presentation with a new
role. That's covered by the spec.
... (Reads example regardring aria-level)
CS: Does anyone else think this is way too complicated?
Group: Yes.
<clown> "aria-level is not a global attribute and would
therefore only apply if the element was not in a presentational
state."
ABR: Basically, global attributes apply regardless of roles.
... Role-specific attributes do not apply if role="none".
JS: That's covered by the spec text I quoted.
... The very next sentence is
<clown> "If an element with a role of presentation is
focusable, user agents MUST ignore the normal effect of the
role and expose the element with implicit native semantics"
RS: Do we need anything in the mapping spec?
CS: I think it's good to copy it there, because it's not clear
from how it's currently written that stuff with
role="presentation" might wind up in the tree.
JS: That's why I raised the issue last year.
ABR: Editorial suggestion: It's not obvious that there is all
this information under role="presentation" that is not pointed
out by role="none".
... There might need to be some top-level section that
everything can point to.
CS: That's a good idea.
... Is there anything we can do in ReSpec (or elsewhere) to
include shared text?
JS: We do that with the glossary.
CS: Maybe it would be good to do this for the
what's-in/what's-out content.
ABR: In the SVG AAM, there are some areas where I need to
manually include text that is in Core AAM.
CS: It would be nice to have this in HTML AAM as well.
RS: Why don't we raise an issue against ARIA to separate out
the common text?
ABR: So we resolved what role should be exposed if overriding
role of none (goes back to host language)
... Confirmed focusable elements as one role="none" is ignored.
... On the mailing list we discussed when aria-hidden should be
ignored.
JD: Link to the thread?
<AmeliaBR>
[14]https://lists.w3.org/Archives/Public/public-aria/2016Mar/00
43.html
[14] https://lists.w3.org/Archives/Public/public-aria/2016Mar/0043.html
ABR: That email (above) links to the other threads.
RS: Here is the issue
<Rich> [15]https://www.w3.org/WAI/ARIA/track/issues/1017
[15] https://www.w3.org/WAI/ARIA/track/issues/1017
issue-1017
<trackbot> issue-1017 -- Separate out text from role="none" and
"presentation" so that a single location may be referenced in
Core-AAM -- raised
<trackbot> [16]http://www.w3.org/WAI/ARIA/track/issues/1017
[16] http://www.w3.org/WAI/ARIA/track/issues/1017
RS: I personally won't be looking at that for a while because
I'm working on key shortcuts.
JS: Where is this text going to go?
RS + ABR: Somewhere in the ARIA spec.
JS: One other thing: I've not yet looked at the spec to see if
it's covered, but....
... In Core AAM, it says that if it causes an accessibility
event it has to be in the tree.
CS: That's not possible.
... For instance, if you put a click handler on the page, all
children could have an event.
ABR: Events bubble. There are also text mutations.
CS: There are a couple of tricky things. UIA has no concept of
bubbling.
... The other thing is that if you have a click handler on the
body, you don't want to expose every single element in the DOM.
... So the text that is currently in the spec doesn't reflect
reality.
... It does express a problem which needs to be solved, namely
how to figure out the elements which should be clickable and
expose them.
JS: I'm thinking aria-selected.
... If aria-selected changes, you get an accessible
state-changed event.
<clown>
[17]http://w3c.github.io/aria/core-aam/core-aam.html#mapping_ev
ents_state-change
[17]
http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events_state-change
CS: If you're talking about ARIA attributes changing, yes, that
is true.
... But if you're talking about DOM events....
JS: I'm talking about accessibility events.
CS: For things like focus, there are. But for input events like
click and keypress, they can bubble.
JS: The link above is about accessibility events for state and
property changes.
ABR: For most events which are about the accessibility API will
be handled as a result of the role and other ARIA properties.
... As far as general DOM events or text mutation events, it
needs to become a requirement on the user agent to bubble them
up to the nearest element which is exposed in the accessibility
tree and fire the event on that element.
CS: That's close to what we've been thinking about.
... But it gets tricky when the element with the input event is
not in the tree.
... In other words, that the div that got clicked on is not in
the tree.
... We can express the x,y coordinates, but I'm not sure how
the ATs will find it.
ABR: The author should give the element some semantic
relevance, or a tabindex, etc.
... What's the consequence if something says you clicked on
this paragraph instead of this em element in a span in a
paragraph?
... Is there a usability issue?
CS: That's a good question.
... The accessibility APIs were not designed for this scenario.
... If you have a thing that looks programmatically like a
range of text, but is supposed to act like a button, it's an
authoring error if it doesn't have (say) a tabindex of -1.
ABR: A more practical example: A diagram like a chart where you
can hover over data points and have information about that
element show up.
... Chances are that the author will put just one event handler
that looks at the target and gets the data.
... This is a realistic case where the exact element might
matter and need to be communicated.
CS: In that case, if the reference points have tabindex of -1,
or are links or buttons or something else interactive, they'd
be in the tree.
... That is the advice I'd give the author.
ABR: That sounds like a natural approach that anything with
semantic meeting has a property that causes it to be included.
CS: I think that's the right approach.
... Bubbling/pass-through mechanisms will not be done in time
for 1.1.
ABR: On the Accessibility API side, or the DOM side?
CS: Either one.
... Are there implications there with respect to CR?
ABR: Where it's currently defined is
... (Reads from the text in Core AAM)
... There is no direct link to what it means to fire an
accessibility event.
JS: I always thought it meant the content in the section
related to accessibility events.
CS: And I thought it included things like click handlers.
<AmeliaBR>
[18]http://w3c.github.io/aria/core-aam/core-aam.html#mapping_ev
ents
[18] http://w3c.github.io/aria/core-aam/core-aam.html#mapping_events
ABR: The above link has the section in Core to what events are
being mapped.
JS: There's a table there.
ABR: Those are about specific ARIA properties and how they are
mapped.
... And that shouldn't be a problem because they'll be in the
tree.
... 5.8.2 and 5.8.3 regarding visibility and text mutations,
there might not be a one-to-one correspondence between DOM node
and event to be triggered.
<Rich> scribe: Rich
Cynthia: The scenario is sort of a reverse bubbly scenario
... some children are not in accessibility tree
<scribe> scribe: Rich
joanie: some of the things I scribed that Joseph said was my
understanding. However, if we are talking about the paragram
example, we don’t care so much about the EM. We are interested
in the coordinates at what was clicked.
... what is they waypoint example?
... if I don’t have to synthesize the input event and something
pops up I will get an event and an appropriate role
amelia: we wan the assistive technology to know that the event
happened on a meaningful object and it may need to bubble up in
the DOM tree
... we don’t want non-important elements to suddenly announced
as you clicked on this span. But the reverse issue it is hard
to determine what is important in these scenarios
cynthia: an image button in the middle of a paragraph is a
great example'
<clown> <p onclick="handleClickOnImage()"> …. <img
tabindex="0"> …</p>
cynthia: so it is just an image and there is a click handler
elsewhere up the tree that does something on behalf of the
image and it is all over the web. we need to find a way to have
authors repair it
<joanie> scribenick: joanie
<clown> <p onclick="handleClickOnImage()"> …. <span>click
me</span> …</p>
CS: Joseph, your example has a tabindex; remove that. And make
it a span.
<clown> <p onclick="handleClickOnSpan()"> …. <span>click
me</span> …</p>
JS: Like the above?
Group: Yes.
JS: So you click on the span and it bubbles up to the
paragraph.
CS: Exactly, and this sort of thing is really common.
... Though it's more often on the body.
... And it's an authoring error. But it's very common.
... There's enough content out there in the world that it would
be great if the user agent could repair this.
JS: But how, as this cannot be found via the DOM?
CS: There's certain magic one can do for DOM-based solutions.
... But for ATs based on accessibility APIs, there's no way to
deal with this currently.
<AmeliaBR> <body onclick="handleClickonPar()"><p tabindex="0">
something something <span>click me</span> …</p>
<cyns_> <body onclick><div tabindex=0><span>click
me!</span></div></body>
ABR: Above is the opposite case. You still have a span called
"click me!", but the paragraph is the important thing.
JD: On my platform, the span wouldn't be exposed. I would only
see the paragraph.
CS: That could be handled I think.
... The tricky one is in my example (above)
... The click handler is looking for the ID of the span.
... It will get a click on the div, but not on the span.
... If we use the approach I'm thinking of.
ABR: No way sort of reading authors' minds can you handle all
of these cases correctly.
... Unless you parse the JavaScript, or....
Group: That way madness lies.
CS: I think we can solve Amelia's scenario.
RS: I'm trying to figure out what they're doing when putting
the click handler above (in the DOM tree) the object.
CS + JS: They're reducing code.
RS: Example, a click handler was put on the body tag so if you
click anywhere outside a dialog box, it would close.
ABR: The event handler itself has the element associated with
the event.
RS: This is Firefox telling you that there's an onclick handler
on all the descendants.
... And then ATs were trying to infer why all of those elements
had an onclick handler.
CS: We added invoke only if there was an explicit onclick
handler; not all descendants.
... I'd be curious how Firefox is doing it.
RS: I think they were using the Action interface.
JD: If so, that might be a real problem.
JS: It's the end of the hour!
... I guess the discussion with events are ongoing since we
didn't solve everything.
ABR: We didn't even get to aria-hidden.
RS: I'll send a note to Alex Surkov regarding the action issue.
No meeting next week.
Group: CSUN is next week, so we won't be meeting.
<scribe> scribe: joanie
Summary of Action Items
Summary of Resolutions
[End of minutes]
Received on Tuesday, 15 March 2016 20:15:12 UTC