Accessible Rich Internet Applications Working Group Teleconference

<MichaelC> trackbot, start meeting

<trackbot> Date: 02 June 2016

<MichaelC> agenda: https://lists.w3.org/Archives/Public/public-aria/2016May/0218.html

<MichaelC> agenda order 1, 3, 4

<MichaelC> scribe: jaeunjemmaku

Decisions from last week

rrsagnet, make log world

<fesch> scribe: fesch

mc: CFC emails went out yesterday nothing to approve

jf: the CFC are compound requests - can you do individual CFCs?

mc: that would be formal decision change, but we can re raise this issue when Rich is back

aria-autocomplete ACTION-2039 https://lists.w3.org/Archives/Public/public-aria/2016May/0152.html

<MichaelC> drop item 12

<scribe> scribe: jaeunjemmaku

mk: most of editorial work

mk;authoring change implied in 1.0 but not normative

mk: fixed typo from joseph's feedback
... if anyone has a question, I am happy to answer

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

jemma: matt sent out a detailed email about the change

<clown> "If an element has aria-autocomplete set to list or both, authors MUST ensure that either the element or a containing element with role combobox has a value for aria-haspopup that matches the role of the element used to present the collection of suggested values."

<MichaelC> changes in this branch: https://github.com/w3c/aria/compare/action2039-autocomplete

cyn: authoring requirement that auto complete is also included to aria controls?

<clown> " When an element has aria-autocomplete set to list or both, authors SHOULD use the aria-expanded state to communicate whether the element that presents the suggestion collection is displayed. "

mk: I am thinking why I didnot include it but I am happy to take action to include aria-control part

https://lists.w3.org/Archives/Public/public-aria/2016May/0152.html

joannie: selected status is different.I can show example

michael: we may need more time to look into this with Joanie's comment on state issue
... any questions/suggestion on working on this issue for next week?

next item

Treeitem, option re children presentational https://lists.w3.org/Archives/Public/public-aria-admin/2016May/thread.html#msg16

michael: does somebody want to start the discussion?

bg: problem is in that we deal with this treeview as composite widget or not. it is also relevant to focus management issue

fred: james and I suggested to move this issue to aria 2.0

<clown> Stefan's latest: https://lists.w3.org/Archives/Public/public-aria-admin/2016May/0049.html

fred: james came up with an idea using attributes, complex, prestentationl and etc

jn: this is common ui pattern so we need to come up with an answer eventually although it is too late for 1.1

michale: what is the comfortable option for this?
... I check with Stefan. if not I will work with matt and james to summarize the issue
... current proposal by stefan's is accepted by everybody?

michael: did we record actions with this issue for 2.0?

mk: happy to have an issue for 2.0. however we would like to work within APG group so that we can come up with actual solution

<MichaelC> ACTION: mking to discuss treeitem and option re children presentational in APG group, define issues that need to be handled in ARIA 2.0 [recorded in http://www.w3.org/2016/06/02-aria-minutes#action01]

<trackbot> Created ACTION-2078 - Discuss treeitem and option re children presentational in apg group, define issues that need to be handled in aria 2.0 [on Matthew King - due 2016-06-09].

joanie: I am going to commit changes today for approved ones

michale: nobody objects Joanie's suggestion - commit changes

next item

Password role

michael: adding warning to pw role and more to this issue

<Zakim> JF, you wanted to ask about application of that attribute - i.e. <fieldset>

<MichaelC> https://lists.w3.org/Archives/Public/public-aria/2016Jun/0016.html

michael: we can talk about fieldset as the second item

<MichaelC> action-2072?

<trackbot> action-2072 -- John Foliot to Provide draft text for password by 6/2/16 -- due 2016-06-02 -- CLOSED

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

<JF> Warning: the password role does not convey or apply any of the security or privacy considerations found in native password fields. Authors are responsible for making sure that custom password fields have robust security and privacy protection, as befits their use.

<fesch> +1

<clown> +1

léonie: I agree with this

<joanie> +1

<MichielBijl> +1

RESOLUTION: Accept John's suggestion

next item for pw is application element - fieldset

jf: for now we can use input or content editable as aria role for pw but if people are using different aria role such as radio check and etc

lw: we need to address this issue to different places - mapping and host language sections?

<Zakim> MichaelC, you wanted to mention HTML-AAM

michale: for now, we don't have section for what element role should be applied

<Zakim> fesch, you wanted to say you need to allow it on div and span

michale: we can advisory comment to host language but we can not put definite saying.

jf: what is error handling process?
... if element is used which is not supposed to use, what happens?
... native semantics override aira

fred: not many content editable is not svg

joanie: I dont see any problem with content editable with password

<Zakim> cyns, you wanted to say that <p contenteditable=true role=password> is a legit use case

cyn: joanie already covered a lot

<Zakim> MichaelC, you wanted to say SVG may define different elements password can / can´t be applied to and to say error handling not specific to password

cyn: we may need to see a way css(webkit) can provide bullet which is gone away now.

jf: we put dependency to screen readers, not browsers

joanie: it present rendered text
... it is not checkbox, because it is password role

joseph: you are assuming the author has not written the javascript to handle this.

jf: what is js does not take care of it?

lw: aria spec is not the place to talk about error handling

michale: we can add words that host language should put restriction on this and handling by AT

joanie: we should not make assumption that we can write about handling by AT
... if someone wants to do that, I hope that person need to consult with me.

<Zakim> LJWatson, you wanted to say we can handle it in the host language, but could perhaps restrict it to use within a form role container?

lw: can we put restriction to form of container as well as host language restriction?
... if we restrict that it should be inside of form element, it may decrease the errros

<MichaelC> ACTION: cooper to draft ¨host language should¨ language for password that they should restrict elements it can apply to, with input from minutes of 2 June 2016 meeting [recorded in http://www.w3.org/2016/06/02-aria-minutes#action02]

<trackbot> Created ACTION-2079 - Draft ¨host language should¨ language for password that they should restrict elements it can apply to, with input from minutes of 2 june 2016 meeting [on Michael Cooper - due 2016-06-09].

joanie: I don't like lw

s suggestion

joanie: but it made me think
... I will make an action to limit the text to editable stuff only.

<LJWatson> +1 to Joannie's suggestion.

joanie: things not editable, you should not use password role

<fesch> +1 to editable

+1

<joanie> action Joanie to draft ARIA spec text limiting the use of role password on editable objects

<trackbot> Created ACTION-2080 - Draft aria spec text limiting the use of role password on editable objects [on Joanmarie Diggs - due 2016-06-09].

next issue

<MichaelC> issue: It is not defined how AT should handle bad uses of ARIA. Need to come up with AT error handling guidance.

<trackbot> Created ISSUE-1032 - It is not defined how at should handle bad uses of aria. need to come up with at error handling guidance.. Please complete additional details at <http://www.w3.org/WAI/ARIA/track/issues/1032/edit>.

jf: I am good with suggested action

we have three actions and one issue for pw role. does this take care of most of issues?

jf: yes

michale: third issue for password role - security issue

<Zakim> JF, you wanted to ask if this means being marked as "At Risk"?

<MichaelC> ACTION: cooper to draft wording for editorial note on password that it needs review and could be removed later [recorded in http://www.w3.org/2016/06/02-aria-minutes#action03]

<trackbot> Created ACTION-2081 - Draft wording for editorial note on password that it needs review and could be removed later [on Michael Cooper - due 2016-06-09].

michale: we would not use "at risk" but I will say it by drafting wording

lw: I want to thanks for all your patience for this issue.

next item

Keyboard shortcuts http://rawgit.com/w3c/aria/mck-keyshortcuts/aria/aria.html

matt: made a branch and sent to Rich for adjustment of language

<MichaelC> https://github.com/w3c/aria/compare/master...mck-keyshortcuts Diffs in keyboard shortcuts proposal

matt: Rich wanted to keep the reference

<MichaelC> ACTION: cooper to investigate having regular links to APG for each ARIA feature [recorded in http://www.w3.org/2016/06/02-aria-minutes#action04]

<trackbot> Created ACTION-2082 - Investigate having regular links to apg for each aria feature [on Michael Cooper - due 2016-06-09].

matt: we use normative language for warning

michale: no objection?

RESOLUTION: accept matt's proposal

next item

Action 2067: aria-owns dom/owned children sequential ordering

<MichaelC> action-2067?

<trackbot> action-2067 -- James Nurthen to Write text to state the order of aria-owns ids wrt. the dom child order and sequential aria-owns ids -- due 2016-05-19 -- OPEN

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

joshep: I worked on Jame's edit

<MichaelC> action-2067: https://lists.w3.org/Archives/Public/public-aria/2016May/0159.html

<trackbot> Notes added to action-2067 Write text to state the order of aria-owns ids wrt. the dom child order and sequential aria-owns ids.

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

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

michale: still waiting for Jame's follow up

<MichaelC> action-2067: James to follow up from Joseph´s input

<trackbot> Notes added to action-2067 Write text to state the order of aria-owns ids wrt. the dom child order and sequential aria-owns ids.

next item

Action 2040: Modify section 7.4 to include role values as native host language semantics in paragraph 2

<MichaelC> action-2040?

<trackbot> action-2040 -- Michael Cooper to Modify section 7.4 to include role values as native host language semantics in paragraph 2 -- due 2016-03-17 -- PENDINGREVIEW

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

<MichaelC> https://github.com/w3c/aria/commit/272700164a3cb9f475f6d266ce4fd85edaa3090f Commit for ACTION-2040

<MichaelC> added ¨On elements with implicit WAI-ARIA roles, authors can also use WAI-ARIA states and properties supported by those roles <em>without</em> requiring explicit indication of the WAI-ARIA role.¨

<MichaelC> added ¨Elements that have implicit WAI-ARIA semantics support the full set of WAI-ARIA states and properties supported by the corresponding role. Therefore, authors MAY omit the role when setting states and properties. The role is only needed when the implicit WAI-ARIA role of the element needs to be changed.¨

michale: say the same thing but in two different section.

fred: if it is implicit aria, wouldn't it already have state and properties?

cynthia: the case of check box

RESOLUTION: accept action 2040

next item

Action 2048: Narrator team speaking password role text (Cynthia Shelly)

<LJWatson> This is the HTML module with the host language requirements https://github.com/w3c/aria-in-html

<MichaelC> action-2048?

<trackbot> action-2048 -- Cynthia Shelly to Talk into narrator team about feasibility of echoing rendered text in role=password -- due 2016-04-27 -- OPEN

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

cyn: they will do eventually do something
... but not sure when

<MichaelC> action-2048: any change would be in a future version of windows, not the upcoming one

<trackbot> Notes added to action-2048 Talk into narrator team about feasibility of echoing rendered text in role=password.

<MichaelC> action-2048: password role not slated for upcoming version of windows

<trackbot> Notes added to action-2048 Talk into narrator team about feasibility of echoing rendered text in role=password.

<MichaelC> close action-2048

<trackbot> Closed action-2048.

michale: it increases the risk in the future since one agent would not implement this.

next item

Open issues and actions https://www.w3.org/WAI/ARIA/track/products/17

<MichaelC> close action-2040

<trackbot> Closed action-2040.

<MichaelC> reopen action-2040

<trackbot> Re-opened action-2040.

joanie: if action is closed, there is no way I can go back.

michale: I will leave it open for now.

<MichaelC> action-2068?

<trackbot> action-2068 -- Bryan Garaventa to Address issue 1006 -- due 2016-05-19 -- OPEN

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

<MichaelC> action-1744?

<trackbot> action-1744 -- Joanmarie Diggs to Implement edits proposed in issue-641, raise to group if any subsantive changes come out -- due 2016-03-17 -- OPEN

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

<MichaelC> agenda for next week

michale: we will put this to next agenda then to get group's consensus

next item

Status of ARIA spec review for feature freeze Working Draft publication

michale: aim to record consensus at next week meeting
... please look into spec from top to botton
... let's get ready for formal review
... I will chair the next meeting agian