Accessible Rich Internet Applications Working Group Teleconference -- 01 Dec 2016

<Rich> https://lists.w3.org/Archives/Public/public-aria/2016Nov/0061.html

<scribe> scribe: jongund

<Rich> https://lists.w3.org/Archives/Public/public-aria-admin/2016Nov/0007.html

RS: ARIA DPUB aria module went to CR
... Wehn will it be published

MC: Aiming for the 13th

RS: Excellent

<Rich> https://lists.w3.org/Archives/Public/public-aria/2016Nov/0024.html

RA: ARIA in HTML is out for review

<Rich> https://www.w3.org/TR/2016/WD-html-aria-20161121/

JG: I will look at

RS: How do we create action items?

MC: There is no distinction

<clown> https://github.com/w3c/html-aria/issues

MC: You have to go to the GitHub user interface to do it
... We can add people to contributors

RS: Who is in the list?
... We can add comments

MC: DO we want individual comments or group comments

JG: I can make a wiki

MC: I think we should use tracker

<Rich> ACTION: Jon create wiki with feedback on aria-html. others contribute to it. [recorded in http://www.w3.org/2016/12/01-aria-minutes.html#action01]

<trackbot> Created ACTION-2128 - Create wiki with feedback on aria-html. others contribute to it. [on Jon Gunderson - due 2016-12-08].

RS: What product do we associate that with

<clown> action-2128

<trackbot> action-2128 -- Jon Gunderson to Create wiki with feedback on aria-html. others contribute to it. -- due 2016-12-08 -- OPEN

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

MC: We should leave it unassociated right now
... We should stop using tracker with ARIA in its name
... How about Misc. product

<MichaelC> trackbot, associate action-2128 with product-56

<trackbot> action-2128 (Create wiki with feedback on aria-html. others contribute to it.) associated with product-56.

Comment from Karl Groves

<Rich> https://github.com/w3c/aria/issues/486

RS: We need to have a response, I did respond
... We feels host language should have precedence
... The host language determines what is allowed and what is not
... Looking at his last comment on "...not possible", the host language should determine, not ARIA

JS: Maybe

JS: I thought he had a deeper claim that LABEL should win over all ARIA
... SPIN Button example
... Are you going to write the spec about all the do or do nots

RS: Right but a spin button can be a container for...

JS: People have done this to make a left, right, up and down to make a spin button out of a text box

RS: The host language needs to limit it, not ARIA
... ARIA says that the host language can restrict what roles can limit

JS: Lests find it and make sure it says that

JN: It's linked in the GitHub issue "Host general conflicts"
... The link is wrong though
... Section 7.5
... I disagree that we should allow host language restrictions, I think ARIA always winning would make things simplier

RS: .... reading the spec...
... I think we already address this
... If there is a problem it should be discussed with the host language working group
... Do you think the ARIA spec text addresses his point?
... Here is an instance where he is wrong
... A WYSIWYG that can add a radio button and its label

JS: You are editing the label

RS: I think this should be done in the host language and we provide for that
... Any other ideas?

JS: You are using Javascript to repurpose an element to something else
... ARIA in general should win

RS: We have provisions in the ARIA spec to deal with this
... Any other comments?
... We need to render a decision

MC: I am not sure how to use Github for consensus
... Never clear if it is a group decisions or an individual

Janina: You want consensus by the working group on the wording

<Rich> Proposal: In general the ARIA working group believe that if the author has gone to such great lenghts to repurpose a host language element such that they would require an ARIA role to be applied to make it accessible they should be able to. That said, we do have a provision in the ARIA spec. to address conflicts with host languanges in this section of ARIA: http://rawgit.com/w3c/aria/master/aria/aria.html#host_general_conflict . The specific text that

<Rich> addresses your concern is this: “Therefore, to prevent providing conflicting states and properties to assistive technologies, host languages MUST explicitly declare where the use of WAI-ARIA attributes on each host language element conflicts with native attributes for that element. When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA

<Rich> attribute and instead use the host language attribute with the same implicit semantic.”

<clown> "user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language."

<Rich> Proposal: Proposal: In general the ARIA working group believe that if the author has gone to such great lenghts to repurpose a host language element such that they would require an ARIA role to be applied to make it accessible they should be able to. That said, we do have a provision in the ARIA spec. to address conflicts with host languanges in this section of ARIA: http://rawgit.com/w3c/aria/master/aria/aria.html#host_general_conflict . When a WAI-ARIA

<Rich> role is provided, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language. Values for roles do not conflict in the same way as values for states and properties (for example, the HTML 'checked' attribute and the 'aria-checked' attribute could have conflicting values), and

<Rich> authors are expected to have valid reason to provide a WAI-ARIA role even on elements that would not normally be repurposed.

RESOLUTION: Reponse to comment from Karl Groves is: In general the ARIA working group believe that if the author has gone to such great lenghts to repurpose a host language element such that they would require an ARIA role to be applied to make it accessible they should be able to. That said, we do have a provision in the ARIA spec. to address conflicts with host languanges in this section of ARIA:

<Rich> http://rawgit.com/w3c/aria/master/aria/aria.html#host_general_conflict . When a WAI-ARIA role is provided, user agents MUST use the semantic of the WAI-ARIA role for processing, not the native semantic, unless the role requires WAI-ARIA states and properties whose attributes are explicitly forbidden on the native element by the host language. Values for roles do not conflict in the same way as values for states and properties (for example, the HTML

<Rich> 'checked' attribute and the 'aria-checked' attribute could have conflicting values), and authors are expected to have valid reason to provide a WAI-ARIA role even on elements that would not normally be repurposed.

RS: We got the resolution

<Rich> https://github.com/w3c/aria/issues/486

<Rich> Rich: the issue is now closed

Testable Statements

MC: We have an echo problem with JN

RS: So I have been holding off on this, waiting for JC
... We are waiting for him
... Microsoft is also working on the core mappings

JS: There is a question for you

RS: The problem they had, they wanted to do an expand/collapse pattern, ..., but was not required, I don't know what his response was...
... I want the expand/collapse pattern could have popup set

<clown> https://github.com/w3c/aria/pull/467#issuecomment-264236294

JS: They will still use the expand/collapse pattern

RS: I am fine with it
... I have a branch conflict
... It makes sense to me, it has to go in there

RSL He needs to fix the conflicts

JS: In that pull request

RS: We should be seeing progress in filling out the table
... The gap we have now
... WHen do think you get started

JG: We have been making progress, trying to make

RS: They may be using a version 2
... I can send you send me new links
... You can talk to James Teh and Alexander Z
... Also know that Brett Lewis form FS
... I am trying to get both NVDA and FS more involved
... Send a note to them and copy me
... Joanie gets back next week, that will help to
... We left off with the U element in HTML5

MC: I need to look at the minutes

<Rich> https://www.w3.org/TR/html51/textlevel-semantics.html#textlevel-semantics

MC: We created a big issue
... The TOC is better than the section for me
... We looked at ......

RS: I didn't see SUB/SUP?? discussed

<MichaelC> https://github.com/w3c/aria/issues/485

MC: Issue 485
... We did not look at Ruby and its related elements....

RS: Is Ruby even mapped in HTML5?

MC: Tis is part of the triage

JS: Not found

<MichaelC> https://w3c.github.io/html-aam/

MC: editors draft and was updated yesterday
... I am not sure what they are doing on it

<clown> https://w3c.github.io/html-aam/