Accessible Rich Internet Applications Working Group Teleconference -- 15 Mar 2016

<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> http://www.w3.org/WAI/ARIA/track/actions/1681

<clown> 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: 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> http://w3c.github.io/aria/html-aam/html-aam.html

<cyns_> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html

<clown> 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> 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> 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> 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> 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> 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> …. <img tabindex="0"> …

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> …. click me …

CS: Joseph, your example has a tabindex; remove that. And make it a span.

<clown> …. click me …

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()"> something something click me …

<cyns_> <body onclick><div tabindex=0>click me!</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

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

15 Mar 2016

Attendees

Contents

ACTION-1681 (Joseph, Amelia) Editorial change(s) clarifying inclusions rules and/or exclusion rules.

No meeting next week.

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output