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

<clown> agenda: this

<scribe> scribe: joanie

ACTION-2008 (Cynthia/Joseph) Handle concept of description property for UIA.

<clown> action-2008?

<trackbot> action-2008 -- Joseph Scheuhammer to Handle concept of description property for UIA -- due 2016-03-01 -- PENDINGREVIEW

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2008

JS: There is going to be a description property in UIA, like there is in the other platforms.

(Group discusses how to do pull requests)

<clown> https://rawgit.com/w3c/aria/action-2008/core-aam/core-aam.html#ariaDescribedBy

JS: The above URL is for the change.

RS: I'm pleased at this new property.

CS: We also have help text.
... Which is for things which are not descriptions, but otherwise helpful.

RS: Can we put errormessage in help text?

CS: It's usually for things like tooltips.

ABR: In the name and description calculation, if the API/AT has a way of presenting both description and tooltip, this will preserve each.

CS: I don't know if the other platforms have a way to do that.
... But we do.

JS: If it's not already in master, I'll put it there.

CS: If I put it in master, I'm not sure how I did it.

JS: I'll check, and I'll close the action.

CS: While I was working on that, I made an action for myself to add this to AccName AAM.
... I think that's a bit more complicated.

action-1104

<trackbot> action-1104 -- Cynthia Shelly to Define what the accessibility API mapping is for UIA on aria-describedby in section 5.5.1 table when the element does not exist in the accessibility tree such as when css: display:none applies -- due 2016-12-31 -- CLOSED

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/1104

JS: That is action-1104

CS: I'm doing a bunch of AccName changes.

JS: You closed it as a duplicate.

CS: There's another one too.
... I'm thinking of action-2042.

action-2042

<trackbot> action-2042 -- Cynthia Shelly to update accname-aam to reflect UIA FullDescription -- due 2016-04-25 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2042

CS: And that's a little more involved.
... I'm doing some other work, but didn't finish it before CSUN.

<clown> https://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html#accessible-name-and-description-mapping

JS: Look at the table (above URL), under accessible description, there's a TBD under UIA.

CS: Action 1104 was just about aria-describedby.
... This (other action) involves looking through all the places where changes might be needed.
... I also need to think about what impact having three fields has.

JS: I'll keep an eye on what you're doing.

CS: I'll have a sizable pull request for you.

JS: Other questions?

ACTION-1681 (All) Clarifying inclusions rules and/or exclusion rules.

<clown> 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

JS: This is a continuation from last meeting.
... We stopped at the case where you have an event handler on the body which handles all click events on the document.
... And what the means for inclusion in the accessibility tree.

<clown> https://lists.w3.org/Archives/Public/public-aria/2016Mar/0159.html

JS: Rich sent email (link above) to Alex.
... (Reads from the aforementioned email)

<clown> https://lists.w3.org/Archives/Public/public-aria/2016Mar/0215.html

JS: Alex replied (above URL)
... Which I sort of understand, but not completely.

RS: (Reads statement from Alex's email)

JS: For this particular condition, it just exposes the leaves.

CS: Does it cause other elements which wouldn't normally be in the tree to be there?

RS: I don't think so.

ABR: If the leaf node is an em element or span, that would add a lot of clutter.

CS: I think we're not going to expose every element in the DOM.
... If there's an event handler like onclick on the body, we'll handle it a different way.

Group: It's expensive.

JS: If I read him literally, he's not talking about the span, but the text in the span.
... Is that the correct interpretation?

RS: Like CDATA?
... We can ask him.

CS: It would be good to contact him to clarify.

RS: I'll respond to him.

JS: (Reads from Alex's response)

RS: I believe when he said "I think", he didn't look.

JS: But I did (look).
... What you have to do is put a click handler on the input element to cancel the bubbling.

RS: I'll include that in my response.

JS: Mind you, I only tested Firefox.

RS: Any particular version of Firefox, Joseph?

JS: Whatever was the latest version as of last week.

RS: Email sent.

JS: Does that answer our question, then?

RS: He didn't quite answer it.

CS: I think it's pretty clear that we don't want to require browsers to do that.
... It sounds like if there's things already in the tree, they're exposing the action on those objects.

ABR: So as far as the spec, we want to make it clear that we'll not be adding extra nodes to the accessibility tree as a result of global or inherited onclick handlers.
... If you add one to a specific node, then that node needs to be in the tree?

CS: I think that's an open issue, along with how to handle the global element?

JS: For instance, if it's on the body.

CS: Body might not be a good example; if the global handler is on a div or span.
... In that case, we would include it.

ABR: It might result in something with role="presentation" winding up in the tree.
... But we need to clear that up in the Core AAM.

CS: It's not all event handlers; it's just click.
... We don't want all event handlers in the tree.

ABR: And key handlers are covered by focusability.

CS: Touch handlers we treat as click.
... We can look at if we want to do W3C touch and pointer events.
... But I think those may be less common, or less urgent.
... And that we're fine for 1.1.
... But someone could look into it.

JS: So you just want click handlers for now?

CS: Yes.

ABR: I would generalize that to touch or mouse event handlers.
... It would be strange if single click were treated differently than double click.

CS: But that's device dependent.

ABR: I guess the question is if it will be useful to expose it to the AT?
... If so, do we want an open-ended inclusion?
... In other words, if the AT can handle it.

JS + CS: I think that's for 2.0.

CS: This is risky stuff (for 1.1). But we might wish to dip our toe into it.

JS: I think right now, only click is something the platform can handle.

JS + CS: I like your idea.

ABR: If we could come up with open-ended language that allows it.

CS: I don't like open-ended.

JS: We could add some sort of text which indicates we'll deal with it in future versions of ARIA.

ABR: As far as authoring guidance goes, authors should not be relying upon event handlers to get something included in the tree.

CS: We wired up click in Windows 10. And we did it because so many websites do not add the appropriate thing.
... We scoped it very tightly, however.
... What we found is that it helps in a reasonable number of cases.
... And didn't make the rest any worse.

ABR: I think this is one of those things where the browser is trying to patch up authoring errors.
... Thus being conservative seems appropriate.

JS: I will come up with some wording for global versus element-specific handlers.

CS: There is certainly language out there for this.

JS: I'll look around.

<clown> issue-1017

<trackbot> issue-1017 -- Separate out text from role="none" and "presentation" so that a single location may be referenced in Core-AAM -- open

<trackbot> http://www.w3.org/WAI/ARIA/track/issues/1017

JS: I am waiting on issue-1017.

JS (Describes issue)

RS: If we apply a role to something inherited?

JS: No, it's an author error.
... The concrete case is presentational role being used, along with a global ARIA property (e.g. aria-label).
... Where things override the presentational role is scattered throughout.

RS: I thought we were going to put all the presentational stuff in a single section.

JS: (Quotes the text in the issue)

RS: That was right before we went to CSUN.

JS: Yes.

RS: Do I have an action?
... And it should go in the ARIA spec.

JS: There is no action, and yes it will be in the ARIA spec.

RS: We also have to deal with password and keyboard shortcuts.
... If you give me an action, I'll do it for the ARIA spec.

<clown> ACTION: Rich to separater out text from role="presentation/none" so that a single location may be referenced in Core-AAM. [recorded in http://www.w3.org/2016/03/29-aapi-minutes.html#action01]

<trackbot> Created ACTION-2044 - Separater out text from role="presentation/none" so that a single location may be referenced in core-aam. [on Richard Schwerdtfeger - due 2016-04-05].

<clown> action-2044

<trackbot> action-2044 -- Richard Schwerdtfeger to Separater out text from role="presentation/none" so that a single location may be referenced in core-aam. -- due 2016-04-05 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2044

ABR: That's an action to clear up the ARIA spec.

<AmeliaBR> https://lists.w3.org/Archives/Public/public-aria/2016Mar/0158.html

ABR: For the Core AAM, there will be additional details regarding when things are conflicting.
... The URL above points to an email I sent a couple of weeks ago.
... Is this what everyone else understands?
... (Describes contents of email)

(Group processes contents of email)

CS: Number 1 is fine.
... I think I'd add tabindex of -1 to item 1.

ABR: But what if it has aria-hidden on it because it's not relevant.

CS: There are various reasons things go in (natively they go in, or their focusable, etc.)
... Tabindex of -1 falls into that category.
... But I see what you're trying to do.
... That item 1 applies even if it's hidden.

ABR: You're (Cynthia) taking my list in reverse order, I think.

<Rich> https://www.w3.org/WAI/ARIA/track/actions/2044

RS: Above is the new action.
... You'll see some text in there.

JS: Amelia, is your email text the suggested text for Rich?

ABR: This is something I'd like to see in the Core AAM.

JS: And wipe out the text that is there?

<clown> https://rawgit.com/w3c/aria/action-2008/core-aam/core-aam.html#include_elements

ABR: I don't care as much as what is in there adds up to what's in my email.

CS: I don't normally like algorithms in specs, but maybe this is an instance where we want one.

JS: I put in the URL for the current inclusion (above).
... It's just a list.

ABR: What brought up this issue is that it doesn't right now handle certain interactions between including and excluding.

RS: And title?

JS: That's part of HTML AAM; not Core AAM.

ABR: I have it that role="none" takes precedence over native host language semantics.

RS: So if someone puts a tooltip on there, we don't care?

<cyns_> step 1: include based on native rules. Step 2: include things with roles (and the other properties) Step 3: remove hidden things Step 4: add back focusable and other override stuff

ABR: If someone puts a caption on a table with role="presentation"

CS: Above is a quick example of a algorithmic approach.
... (Reads)

ABR: I think the only thing you're missing there are things which would normally be included due to native roles.

CS: That's step 3, in my mind.

ABR: No, because hidden overrides things which role="none" does not.

CS: I meant to include those in step 3
... That makes it clear what goes in and out.
... I'm not sure if it's good from the implementation standpoint.

RS: Where does it belong?

<AmeliaBR> s/due to native roles/due to native roles, except for role=none/presentation/

CS: I don't think it needs to be in the ARIA spec.

RS: But what Joseph was saying is that it's in different places in the ARIA spec.

JS: We have a section in the Core AAM which points to the ARIA spec.
... And what it points to in the spec is huge and not especially clear.

ABR: So the section in the Core area that needs to be cleaned up are the rules when an author-supplied role of presentation/none will be ignored.

<clown> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#exclude_elements2

CS: Maybe we need a sentence which says what attributes will cause that role to be ignored.

ABR: It's there, but lost in the other text.

RS: Other than aria-labelledby....

(Group discusses which attributes are relevant)

RS: I'll put it in presentation.

JS: Put a subsection in presentation with all these little nuances.

RS: I'm not sure how to put the subsection, but I'll give it some thought.

JS: Looking at the current exclusion rules, aria-hidden is a SHOULD NOT; not a MUST NOT.

ABR: Rich, did you have any more questions about the changes you'll make to the ARIA spec?

RS: I don't.

ABR: Why don't we shift focus to the Core AAM spec then?
... We have things which are currently described as SHOULD NOT rather than providing very clear rules.
... Part of the problem is that these are some of the things which should be excluded, except for other things.
... Is that why it was done as SHOULD NOT?

JS: I know the history.
... It used to say, you must rely on the CSS only.
... That gradually weakened over time.
... Firefox insisted on keeping aria-hidden things in the tree for 1.0.

JD: They've since pruned the tree.

CS: Why don't we change it to a MUST NOT and see what they say.
... We should explicitly ask them for their feedback.

JS: I'll ask Alex.

<clown> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaHiddenTrue

JS: And also point this out.
... If you look at the above, every last one indicates should not be exposed unless it fires an event or is focusable.

CS: That's true.
... MUST NOT be in the tree unless the above condition is met. In which case is MUST be in the tree.
... Let's get rid of all the SHOULD's

ABR: aria-hidden overrides global attributes where presentational role does not.

CS: Which is actually a big difference.

JS: I made a note of that.
... Can we wrap this up?

CS: Do we want to make the change, or talk to the Firefox developers first?

JS: Give me an action.
... Actually, I have an 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

JS: I think the rules are all there, but ambiguous. So it's mostly editorial.
... The change from a SHOULD to a MUST is the exception.
... I'm going to push the due date out to two weeks from today.
... Will your text be done in two weeks, Rich?

RS: I can try.

JS: I'm putting a note in my action that it depends on yours, Rich.

Accessible Rich Internet Applications Working Group Teleconference

29 Mar 2016

Attendees

Contents

ACTION-2008 (Cynthia/Joseph) Handle concept of description property for UIA.

ACTION-1681 (All) Clarifying inclusions rules and/or exclusion rules.

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output