<richardschwerdtfeger> meeting: ARIA Working group

<scribe> scribe: jamesn

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria/2016Jan/0179.html

7 day decision policy

<richardschwerdtfeger> https://www.w3.org/WAI/ARIA/decision-policy

RS: wraps up tonight. Anyone have any objections to that

<silence>

</silence>

aria-grabbed and dropeffect

ACTION-1672?

<trackbot> ACTION-1672 -- Joanmarie Diggs to Mark aria-grabbed, aria-dropeffect as deprecated and provide reference definition of derprecated -- due 2016-02-03 -- PENDINGREVIEW

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

<joanie> https://rawgit.com/w3c/aria/action-1672/aria/aria.html#aria-dropeffect

<joanie> https://rawgit.com/w3c/aria/action-1672/aria/aria.html#aria-grabbed

<clown> https://rawgit.com/w3c/aria/action-1672/aria/aria.html#dfn-deprecated

RS: reads the notes from the spec

"The aria-dropeffect property is expected to be replaced by a new feature in WAI-ARIA 2.0. Authors are therefore advised to treat aria-dropeffect as deprecated."

Deprecated

A deprecated role, state, or property is one which has been outdated by newer constructs or changed circumstances, and which may be removed in future versions of the WAI-ARIA specification. User agents are encouraged to continue to support items identified as deprecated for backward compatibility.

CS: from a UA perspective it sounds like if we haven't implemeneted it yet we should probably hold off doing it

<clown> http://w3c.github.io/aria/core-aam/core-aam.html#ariaGrabbedTrue

RS: we are not going to try to get 2 implementations

CS: would be nice if it gave some advice to UA as well as to authors

JD: thought about that for some time

implression I got is that if it is in the spec it is meant to be implemented

I didn't like the idea of telling UA that they must implement something that is going away

if I were reading that and there was a normative statement that UA need not implement it then would question why it were in the spec

CS: when a 3rd party test suite includes it then I want to be able to say I'm not going to do that
... basically this feature failed - and we are taking it out becuase it didnt get uptake

RS: Bryan implemented it

we got 2 implementations

CS: middle ground like this may cause trouble - would like it if more crisp

MK: I think there are no WCAG techniques which refer to aria-grabbed and dropeffect

CS: is it required for a UA to support it to be in compliance with aria?

RS: yes

CS: for some period of time it is in this weird middle ground

JD: these properties are in the 1.0 spec - doesn't that mean you are not compliant with old aria

CS: if it is coming out then it is a waste of time to implement it

RS: ARIA 2 is a ways out - hope to do alot with the api work.

these are just a couple of properties

CS: a fairly chunky work item to actually get it to work

i could mape the properties but that is a waste of time as there is no user benefit

would be nice if it wern't this ugly story

RS: we are not going to haul it out. we need a proposal b4 we can think about replacing it

CS: it is in but it is bad.

MK: if you implement it - even once the new pattern is there then legacy implementations would still be valid.

unless there are conflicts then it is legit to support 1.1 features even after 2.0 is final

CS: this status is really complicated

MK: it doesn't eliminate the motivation to implement it

CS: I won't be able to sell working on a deprecated feature

<clown> https://www.w3.org/WAI/PF/testharness/testresults?testsuite_id=1&testcase_id=92

RS: what peole want to do is use a mark capability

when it started there was no drap/drop in the browser which was consistent

was it alligned with html5? no. that is what we plan to do in the future

we are not going to haul it out - there are people that have implented this in applications

CS: I would prefer it was there or not there - not in the weird middle state

RS: apple and others wanted it in this middle state

CS: some guidance on UA as to what to do with a deprecated feature in the spec would be helpful

have an authors should

JD: I put it in the glossary

<richardschwerdtfeger> https://rawgit.com/w3c/aria/action-1672/aria/aria.html#dfn-deprecated

you are already not comliant with a pretty old spec

JD: deprecation is not the same as obsolete

even in 2.0 the stupid thing will be around forever

becuase we dont like it and we don't want authors to do it

JS: IE passed this according to the test harness

<clown> https://www.w3.org/WAI/PF/testharness/testresults?testsuite_id=1&testcase_id=92

CS: my issue is with deprecated more widely
... I would like it to be crisper

<Zakim> clown, you wanted to ask if a note or something else needs to be added to Core-AAM

RS: are people ok with the text

MK: change to a future version not ARIA 2.0

RS: are people ok with that tweak

<richardschwerdtfeger> Propsosal: To accept Joanie’s changes regarding the deprecation notes on aria-grabbed and aria-dropeffect with the exception that it refer to a future version of WAI-ARIA and not specifically 2.0

<clown> +1

<joanie> +1

+1

<fesch> +1

RESOLUTION: Accept Joanie’s changes regarding the deprecation notes on aria-grabbed and aria-dropeffect with the exception that it refer to a future version of WAI-ARIA and not specifically 2.0

<richardschwerdtfeger> RRSAgetn, draft minutes

Combobox

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

<richardschwerdtfeger> https://www.w3.org/WAI/ARIA/track/actions/1490

RS: is there a branch?

http://rawgit.com/w3c/aria/mck-action1490/aria/aria.html

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

MK: 10 changes

Objectives:

1. Allow combobox to popup grid, tree, and dialog in addition to listbox.

2. Allow aria-controls so screen reader users can see a rendering of the popup in reading mode.

3. Remove ambiguities from the spec to improve understanding and simplify authoring.

4. Do it all without breaking any existing implementations.

MK: the impact is lightweight as most of this already works

important that screenreaders recognise aria-controls if we go that way

so escape works correctly to return focus

that is the only thing that doesn't work

MK: dialog is for example a date picker where there is a grid - and in addition to the grid have buttons next year previous year

JN: also have simple and advanced search buttons in a dialog

MK: right now use aria-owns to own the popup element

CS: controls makes my life much easier too
... controls works a lot better here

MK: 2 major problems for screen readers with owns.... have to distinguish the combo box from its children to extract the value. When in the reading mode the popup disaappears as you cant fit a grid in a listbox
... need them to be next to each other in the DOM so the "grid" appears next in the reading order

RS: have 4 notes in a row.... can we collapse them

MK: I see little relevance in note 4

RS: I would support deleting that
... combobox - do we need an implicit orientation?

MK: the implicit orientation of listbox might be useful

clown: why for a listbox?

MK: so the arrow key is left/right or up down

clown: combo uses left/right for the edit field

MK: focus stays in the edit field

RS: not sure orientation is important on a combo box

MK: should pull out the orientation too

clown: default value is specified

JN: could it just be inheritance?

MK: changed combobox superclass to input not select
... in 1.0 there was a required owned element of textbox but the sample code didnt have that

RS: comboboxes and menus are the worst things to implement

BG: are you saying putting role combobox on an input is invalid?

MK: no

just about the example in the spec

RS: like the fact it is expanded to more use cases

i think orientation is irrelevant in this case so can take it off

RS: collapse the others

objections?

MK: expanded can move into the paragraph about expanded

take class note off it - as it is normative

RS: need to remove the default orientation of vertical

clown: have a problem with the aria-owns change

want it the way it was before

MK: that is problematic that owns doesn't work for a combo box

clown: who would own the list in the tree?

MK: would encounter the listbox

clown: comboboxes have existed on the desktop. the parent child relationship on the desktop is well defined

we are now saying that on the web these things are different

MK: don't have the DOM on the desktop

CS: desktop combo boxes are really different

desktop ones can only have a limited number of things

RS: if have a text field with role combobox - if use owns then have to have a child of a text box
... almost like you have to do one or the other - there has to be an association.

MK: said must have an association and leaves the choice to authors to use controls and owns

clown: say you may have both of these

MK: children appear inside their parents

clown: not at all

I take the parent/child relationship as a logical relationship

sometimes children appear inside their parents, sometimes they don't

MK: in a screenreader thing the parent owns the child

clown: the menu is a parent of the menu items etc.

to me this is the same hierarchy

CS: depends what your goal is

we do the owns now and it doesn't work

so long as the control is there

MK: i don't think any AT would need both

clown: how do you know?
... willing to bet that in the a11y API it is a parent child relationship

MK: and that is a problem

clown: why?

RS: what do you do with Orca

clown: the popup list becomes a menu

JD: right now combo boxes are not a browse mode thing. orca presents the focus and text changes

orca's treatment of them is you shouldn't care where the combo box comes from

clown: would orca be bothered by this?

JD: independent of ARIA there are combo box type things out there. Orca has heuristics out there for stuff

it might matter in terms of NVDA and FF - at some point there was a lot of discussion about things there

clown: doesnt change the tree
... i have no objection to adding controls

MK: the AT needs to know about the relationship

when something is a child and the value is from the content

MK: when it popup up - number 1 - the popup is trigger from and by the combo box so will have the value from the relationship

RS: we have both cases covered

clown: why not both

what is the harm of both

MK: more concerned about how the screen readers render the popup in their virtual view

CS: dont really understand

BG: if you have role of combobox on an edit field and have the aria-owns is that it forces all the listbox content into the value of the edit field

CS: sounds like a bug in the screen reader

MK: that is what screen readers do with all contained elements

the DOM tree is a tree. How would you ever make the decision as to what is inside the element and what is not

BG: also a compatibility thing. some things cant support interactive child elements

MK: sounds like we should have a side tutorial as to how screen readers work

RS: dont have the VO people here

MK: VO does the same thing

they represent every child relationship as a container and you drill into it

CS: they are not children but they are pieces of a whole

RS: combo boxes with text fields in them...
... I don't have problems with Matt's wording
... need a vote

CS: we need controls but having both doesn't bother us
... what do you do with owns but leave controls off

right now it fails

RS: can anyone not live with Matt's text

clown: me - with respect to owns

<bgaraventa1979> can I also propose adding aria-valuetext for setting a value property association?

<bgaraventa1979> +q

JD: propose doing the notes as a seperate action

<joanie> ACTION: Joanmarie to address the non-normative notes which point out implicit values [recorded in http://www.w3.org/2016/02/04-aria-minutes.html#action01]

<trackbot> Created ACTION-2011 - Address the non-normative notes which point out implicit values [on Joanmarie Diggs - due 2016-02-11].

RS: you have modified autocomplete in this.

MK: if you look at the 1.0 text then if keep the old meanings that is one of the major things behind the confusion

<clown> http://rawgit.com/w3c/aria/master/aria/aria.html#aria-autocomplete

MK: i removed 5 paragraphs

clown: the values are incomprehensible

MK: nobody knows what do to with them

clown: I do

RS: don't want to do this now

blowing out all the other ones too (deprecating them)

MK: what is the challenge to get 2 extra values to be there

clown: sometimes quick, sometimes takes a long time

MK: this is simpler

clown: don't share that intuition

MK: if an author specifies true then can either map to inline or pass it through

RS: don't want this now

MK: in the core AAM the browsers can keep them

JF: i kind of support MK in that adding them is beneficial - but again it is just a mapping issue. Adding true/false we will see what authors do

clown: how difficult would this be?

RS: havent canvassed people

CS: would be difficult for us an inline and list are very different with how we wire them up. in UIA a list is a combo box. inline is a bunch of things in the text pattern.

they are completely unrelated

<ShaneM> If there isn't agreement to do this, back burner it to aria 2?

MK: in UIA - if the author specifies the wrong thing will be brooken

CS: in UIA they are very different

MK: would have to map true to both

<bgaraventa1979> sorry, back on the phone, my question is for aria-valuetext not aria-autocomplete

JN: if UIA is doing it differently then that is a good reason not to do it now

RS: have taken 30 mins for something i didnt want to open the can of worms on

MK: could change autocomplete guidance in combobox
... could be none or both as the only options that make any sense

RS: I would not accept the autocomplete changes
... if want to say something about what the author should do

that is fine

RS: can we have another version for next week?

MK: yes

BG: my question about aria-valuetext. If have role=combobox on an input field. If have it on a div then no value property available

MK: still think that sounds like a browser bug

BG: using a combo box has a span etc.

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/JUST/just/
Succeeded: s/ORCA/Orca/g
Succeeded: s/JS: independent/JD: independent/
Found Scribe: jamesn
Inferring ScribeNick: jamesn
Present: Joanmarie_Diggs JamesNurthen Rich_Schwerdtfeger fesch Joseph_Scheuhammer Bryan_Garaventa ShaneM JF
Regrets: MichielBijl
Found Date: 04 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/04-aria-minutes.html
People with action items: joanmarie

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.