Accessible Rich Internet Applications Working Group Teleconference -- 21 Apr 2016

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

<scribe> scribe: fesch

CFCs

rs: issue 742 moving role = text -> ARIA 2.0
... no objectsion
... Topic: Password Role
... talked with security folks, need consensus with security folks...
... either password gets in 1.1 or moved to 2.0 - we may have a gap with HTML
... will set up meeting on password role, Freedom Scientific will respond
... any comments?

jd: I understand text needs to come out of ARIA 1.1.... holding off on removing to allow editors branching..

rs: this is the way you preserve stuff?

<Rich> trackbot, start meeting

<trackbot> Meeting: Accessible Rich Internet Applications Working Group Teleconference

<trackbot> Date: 21 April 2016

<scribe> scribe: fesch

rs: we can leave password in a branch

Password CFC

rs: question on password is whether in goes in 1.1 or not

jd: we are making a branch....

mc: we will discuss it in 2 weeks, editors call - will send around discussion of plan...
... are we having a joint meeting with security?

rs: yes

Action-1490

<trackbot> Action-1490 -- Matthew King to Propose spec text edit for issue-610: comboboxes should allow complex children elements -- due 2016-02-03 -- OPEN

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

mk: only 2 changes

<mck> http://rawgit.com/w3c/aria/action1490-combobox/aria/aria.html#combobox

hello

<jemma> *;-)

<MichaelC> mk: creating functioning examples - diff between what Rich and I are saying -

<MichaelC> mk: will be in own repository

rs: what do folks think about launching dialog boxes from combo boxes?

<MichaelC> mk: I think the spec text already covers what needs to be covered... rewrote required owns...

<MichaelC> mk: included specific feedback

js: don't like it

mk: there are lots of examples of combos with popups
... easy to demonstrate examples...

cs: I don't think it is a combobox.
... a combobox is a textbox and list...
... think it is antipattern...
... think it has poor usability

<bgaraventa1979> +q

mk: part of the issue - combobox or not - is defining ARIA not on interactions
... thought purpose of ARIA role was to help user understand interaction pattern

cs: that is what ARIA is supposed to be doing
... calling a cat a dog doesn't help

mk: dog vs dog...

cs: limitation of a role based system, something we can fix in 2.0

mk: I think this is where the example helps - can't see where another role will help...
... if you give more roles - gives user more confusion

cs: I would call a combo with a dialog something else...
... combos have been around for 30 years...

mk: combo textbox + popup
... you want combo = textbox + popup list

cs: there is specific behavior with a list

bg: we are talking about two control types
... once in dialog box, then not in a combo any more
... I don't see why it is in the spec

mk: could say the same thing about a list...

bg: problem with dialog is a child of a combobox doesn't make any sense could be recursive
... mapping for combobox...
... opening a combobox - does not support a composite widget type

mk: that is the way it is in the API..., don't understand this, all other composite widgets can be nested

bg: region cannot use a virtual cursor inside a combobox

mk: that is why we are changing it

bg: if you put it on the edit field ... but if you are still in the edit box and go to a grid cell, AT reports it... you can't tunnel into it, so it won't match any select element

rs: what is a combobox Cynthia?

cs: there are expected control pattern and tree structure...

rs: if we put this in, it breaks Microsoft's pattern
... maybe we have a subclass of combobox...

cs: subclass feels like a better model

rs: a subclass gives Microsoft the ability to build something that works for it that doesn't break their current comboboxes
... what do others think about that approach?

mk: users will have to use another role...

<jamesn> **Calls 20 minutes**

mk: the reason they know how to use it... is they've used a combo box
... what you get in the end is identical...

rs: what do people thing about creating a subclass?

mk: all you need to do is look at the target of aria-controls... use based on what is controlled traditional or not

cs: change the role we map it to based on an attribute?\
... mapping the control type based on combobox role, must include .... tree structure... edits...
... I could figure out a way to map it... but users expect a combobox to be a particular thing, would like a usability test

bg: why does the dialog need to be a child of the combo?

rs: so you can walk back to the textbox

mk: in the case of dialog, it is less important that the dialog be a sibling of the textbox... because folks would be using a reading cursor..

bg: why is it required in the spec?

<clown> "When a descendant of the pop-up element is active, authors MAY set aria-activedescendant on the textbox to a value that refers to the active element within the popup while focus remains on the textbox element. "

bg: you can't get to the textbox because the dialog is modal...

rs: need a subclass....

mk: that doesn't help the user....
... you can do a similar thing without the combobox roll...
... we can do this... but it surprising to the user opening something from a textbox

rs: can do it other ways...

mk: now has one more way of doing things, additional baggage with no additional values

rs: can be really confusing to user

mk: a user knows how to do that thing...

<Zakim> joanie, you wanted to ask why not make it an textbox (or subclass) with haspopup?

jd: why not make it an textbox (or subclass) with aria-haspopup?

<clown> aria-haspop: "Indicates that the element has a popup context menu or sub-level menu."

bg: this goes back to the discussion - where it tells what will be opened - and would address this whole thing

mk: could do this for any textbox that opens things... what I have learned about comboboxes - people expect a down arrow to open ...
... other stuff is opened with enter.... different ways... doesn't provide information to user how to open it
... knowing that it will open with a down arrow to open and return with escape - then those learned behaviors ...

jd: might also do other keys ... as they work on other platforms...
... an entry with a popup, can communicate to user what the keys do....

bg: someone suggested popup-type a couple of years ago...
... problem is it doesn't tell you what type of object is being opened - dialog, tree, grid ....
... if we could indicate what type of popup is being opened...

mk: a lot of date pickers are dialogs...

bg: we are talking about what is being opened -

<clown> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25851

rs: OK an attribute for what is being opened.

mk: who does that help?

rs: knowing a dialog is being opened is helpful to the user...

mk: I would be shocked if someone gets confused

bg: select doesn't work that way and it violates some best practices... if it says what it opens, then we will at least know it will send you somewhere

<clown> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25851

js: aria-haspopup - Steve suggested that it tell you the type...

rs: aria-haspopup is global, would want to think about that...

mk: hidden elements could be in the DOM and not in the tree

bg: may not be directly referable...

rs: leaning toward giving information on what is being opened
... we could impact things all over the place...

mk: true false still there, backward compatable

rs: default is what?

mk: it is already technically true... could leave that...

rs: do folks want to let Matt write a popup type? We should limit it

js: true = menu attached

rs: default = list

cs: may be a while before I can do mapping - boolean in API

<clown> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25851

rs: might break a few things...
... took more than 20 minutes... worth while...

mk: has authors SHOULD have modal dialog... but is a designer
... inert in aria-modal is to obfuscate...

bg: opens up a dialog as you are typing...sets the modal... on iOS you won't see the input anymore...

<Rich> https://www.w3.org/TR/html5/editing.html#inert

mk: should change the aria-modal text to agree with inert

<Zakim> clown, you wanted to mention the bug about aria-haspopup and to point out that on AXAPI, aria-modal means "prune the tree".

bg: if we change modal, we will break it for touch interface
... I think it is dangerous... modal is loaded term...

mk: have to manage focus...

js: can you click outside of it?
... click outside a modal dialog it beeps, not allowed to click outside of it...

rs: you want to click outside of it and have it go away, that is not modal

js: covered by aria-modal.... click outside of it ... you are still stuck with it

cs: clicking outside a dialog is called light dismiss in windows...

rs: nobody disagrees we don't want a modal dialog.. have we reached consensus on those three things?

<mck> dialogs launched from a combo need not be modal but should manage focus so the user can click outside the popup to close it.

<clown> +1

<mck> dialogs launched from a combo should manage focus but need not be modal so the user can click outside the popup to close it.

RESOLUTION: dialogs launched from a combo should manage focus but need not be modal so the user can click outside the popup to close it.
... we will expand the values for aria-popup to address use cases of combobox and others

bg: this is backward compatable

<Rich> ACTION: mking3 Expand aria-haspopup to support a token list of values [recorded in http://www.w3.org/2016/04/21-aria-minutes.html#action01]

<trackbot> Created ACTION-2054 - Expand aria-haspopup to support a token list of values [on Matthew King - due 2016-04-28].

mk: thanks Rich for taking the time

ACTION-2036

<trackbot> ACTION-2036 -- Richard Schwerdtfeger to Modify aria-kbdshortcut based on group feedback -- due 2016-04-07 -- PENDINGREVIEW

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

rs: can we put this in the spec and get guidance from APG on shortcuts

<Rich> https://rawgit.com/w3c/aria/action2036/aria/aria.html#aria-keyshortcuts

<clown> ACTION: Joseph Scheuhammer to drive mappings of the new enumerated type values for aria-haspopup [recorded in http://www.w3.org/2016/04/21-aria-minutes.html#action02]

<trackbot> Created ACTION-2055 - Scheuhammer to drive mappings of the new enumerated type values for aria-haspopup [on Joseph Scheuhammer - due 2016-04-28].

<clown> action-2055

<trackbot> action-2055 -- Joseph Scheuhammer to Scheuhammer to drive mappings of the new enumerated type values for aria-haspopup -- due 2016-04-28 -- OPEN

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

RESOLUTION: Pull aria-keyshortcuts proposal into ARIA 1.1 where the final text guidance is subject to revew of new APG text on aria-keyshortcuts

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

21 Apr 2016

Attendees

Contents

CFCs

Password CFC

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output