Minutes: April 28, 2016 WAI-ARIA Working Group

Draft minutes for today's teleconference are at:
https://www.w3.org/2016/04/28-aria-minutes.html
A text version is below. 
Matt King

W3C <http://www.w3.org/>

 - DRAFT -

  Accessible Rich Internet Applications Working Group Teleconference


    28 Apr 2016

See also: IRC log <http://www.w3.org/2016/04/28-aria-irc>


    Attendees

Present
    Joanmarie_Diggs, Rich_Schwerdtfeger, fesch, matt_king, MichaelC,
    Joseph_Scheuhammer, Bryan_Garaventa
Regrets
    MichielBijl
Chair
    Rich
Scribe
    matt_king, MichaelC


    Contents

  * Topics <#agenda>
     1. CFC results <#item01>
     2. Password role <#item02>
     3. ACTION 2054 - haspopup <#item03>
     4. ACTION-1490 combobox <#item04>
     5. ISSUE-1023 <#item05>
  * Summary of Action Items <#ActionSummary>
  * Summary of Resolutions <#ResolutionSummary>

------------------------------------------------------------------------

<mck> Testing JAWS readback of typed info

<mck> not working, bummer.

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

<mck> testing again with JAWS 16 instead of 17.0.1962

<mck> scribe: matt_king


      CFC results

<mck> keyshortcuts CFC successful.

<mck> RS: could possibly make changes to guidance language if Matt has
APG section ready. Will pull in as-is for now.

<mck> RS: will take separate action to update based on APG after APG is
ready.

<mck> RS: Joanie will incorporate language in editor's draft now.

<Rich> *ACTION:* Rich update aria-keyshortcuts based on pending APG
guidance [recorded in
http://www.w3.org/2016/04/28-aria-minutes.html#action01]

<trackbot> Created ACTION-2058 - Update aria-keyshortcuts based on
pending apg guidance [on Richard Schwerdtfeger - due 2016-05-05].

<mck> Joanie: I will merge in keyshortcuts.


      Password role

<mck> RS: sent message to security team.

<mck> MC: Their response was not a "lets meet" response. Seems like they
are declining to meet; they do not see need; so we should go foreard.

<mck> RS: Last I heard from Brad is that he didn't have issues as long
as we indicate to AT that it is a custom password field.

<mck> MC: I don't recall that last part about AT requirement.

<mck> MC: this discussion was not a publicly archived list.

<mck> MC: we should get something public.

<mck> MC: Reading from a note from Brad

<mck> MC: Does not clearly say we need to indicate that it is a custom
password field.

<mck> RS: Perhaps I should write another note to Brad ans summarize a
proposal and ask if it is acceptable.

<mck> MC: cc both web security and aria lists.

<mck> MK: What about using a boolean prop on text fields instead of a
password role.

<Zakim> clown, you wanted to ask what the aria markup is for a custom
password input that does not obfuscate?

<mck> RS: Prefer role as think it is simpler for author

<mck> rs: Léonie asked if 1.1 exit criteria could include 2
implementations by AT of the password role

<mck> Orca already does it so we would need only one more.

<mck> MC: Reluctant to add it as a formal exit criterion.

<mck> Janina: that is a slippery slope

<bgaraventa1979> I agree that this may be an issue

<mck> Joanie: agree it is slippery slope to go down that as exit
criteria for AT

<mck> MC: Adding exit criteria for requirements that are not normative
is not reasonable.

<mck> MC: Adding a normative req would raise a new set of issues.

<mck> Consensus: should not add exit criteria for screen reader behavior
in custom password field (role="password") but that it is very important
to seek screen reader implementations before ARIA 1.1 is final.


      ACTION 2054 - haspopup

<MichaelC> scribe: MichaelC

<mck>
http://rawgit.com/w3c/aria/action2054-haspopup/aria/aria.html#aria-haspopup
<http://rawgit.com/w3c/aria/action2054-haspopup/aria/aria.html#aria-haspopup
>

<mck> Revised aria-haspopup definition so that it specifies the haspopup
value indicates both the availability and type of popup element.

<mck> Removed sentence: "This means that activation renders conditional
content."

<mck> Reason: Activation implies default action. not all popups, e.g.,
context menues, open with the default action.

<mck> Changed this sentence into a note:

<mck> Note that ordinary tooltips are not considered popups in this context.

<mck> Added language to specify allowed values of menu, listbox, tree,
grid, and dialog in addition to true and false.

<mck> Added language to describe how missing, empty, and false values
must be treated by user agents.

<mck> Added language to specify that a value of true equals menu.

<mck> Added authoring requirements for keyboard accessibility and focus
management.

<mck> Change properties table to specify the value as a token.

<mck> Added rows to the values table for the new allowed values.

<mck> Removed the following language about ownership relationship from
values table, ", either as a descendant or referenced by
<pref>aria-owns</pref>."

rs: unsure if we need menu

mck: could delete because values equal

but could be confusing to authors because of exception to being able to
specify role

so want consistent for authors

rs: also say combobox should pull up menu instead of listbox

mck: no, because @@

because @@ is global is weird because could be put on anything

now need to make focusable

potentially to whole document?

rs: menu on body

mck: wouldn´t expect haspopup there

rs: if you want help, might want it

mck: need haspopup on some element, and not on every one

if put on doc, and whole doc focusable, AT needs to know

is haspopup really for this?

rs: it´s global, so can

mck: so then need to manage focus, indicate interactive to user

rs: concern about requiring focus

could just have keyboard handler

mck: how would AT tell user?

maybe a separate key property to inform of the key that activates the popup

<Zakim> joanie, you wanted to ask about the MUST NOT.

@@ popup activation

jd: why forbid exposing if value false?

mck: confusing to say is not there

jd: in platform mappings, may need to explicitly provide a value

mck: we did for current; maybe this is different

rs: @@ linux

jd: not by choice

mck: should empty be same as false? or ignored?

clown: in past, no value meant false

mck: ok, so maybe that´s a ¨should not¨ for AT

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

<Zakim> clown, you wanted to ask what the default value for
aria-haspopup is (is it false?)

clown: what is default value?

oh, see the false now

suggest wording of value descriptions to ¨indicates the popup is a menu¨

to avoid passive voice

fe: <missed>

jd: might need to include application as widget type

various: no

mck: but could say dialog is any sort of application

it´s your out, just another window

jd: ok, whatevs

clown: if there is an enumerated type, authors will try
aria-haspopup=menu and expect it to work

rs: do we want it global?

mck: worry about putting on anything not designed to be interactive and
focusable

putting on random node seems unnecessary, and if done has attributes of
easter egg

so very confusing for screen readers

creates a whole new kind of problem

rs: can put tabindex on anything

so fair to say it must be keyboard focusable

jn: or via activedescendant

rs: yikes

clown: further expands what it can apply to

mck: have never seen on anything except a button heretofore

just worried AT has to keep telling user they can click on something
they can´t move to

clown: just tab to body and hit F10

to get context menu

mck: not all browsers allow that

and rare screen readers intentionally focus body

bg: trying it out, get ¨has popup¨ notice on everything

mck: and then what if there are also descendants with popups

that´s nutso (literal scribing)

jn: we have use case for this

table with activedescendant

focus on header cells

<and other stuff missed in audio outages>

mck: if were not global, can address that use case on grids

fe: use case where people look at text docs, pull out terms and
relationships

there are focusable spans

<jamesn> anything in any of our SVG graphs could have a popup too

get a popup that tells relationships to other terms etc.

mck: why not have a link role?

fe: tells you additional info about that span

mck: button

fe: that seems to bend the role

mck: er, um

fe: e.g., walk to set of words, see it´s a term, look for other terms in
doc that are similar

doing with buttons would be hard on reading

but you can get info about that term

mck: haspopup has been global for a while, and haven´t seen too much
bizarre use

just checking if we have enough language

maybe can address in Practices

but the thing about focusable is agreed?

various: yes

rs: so seems values are ok

need to leave global

important to be focusable

rs: @@

mck: played with idea of key property

fe: why a separate one?

mck: popup keys are different from shortcut keys

e.g., a shortcut might move focus to the field, but another key open the
popup

rs: could use describedby for now

mck: yeah, authors could if they wanted

fe: would author be wrong to use kbdshortcuts to describe the key that
opens a popup?

mck: if popup is default action, no

e.g., on a menu

but confusing in other use cases

in use case of terms, which term opens?

fe: opens the one with focus

mck: shortcut key not really for the thing that has focus

clown: maybe down arrow is a defacto standard

mck: if you´re inside menu, you´re navigating

but can have sub-menus

clown: in which case you go right

mck: depending on layout

there´s also question of owning element

most menu buttons don´t work well if menu is owned by button

rs: also bad for dialog

mck: in combobox we use controls, but explicit for that role

I removed specfiying, and in cases where relationship is needed, should
be put in

not part of the property

rs: are these changes ok?

mck: need to adjust language how values expressed

and change MUST to SHOULD for AT

*RESOLUTION: Accept Matt’s proposal to change aria-haspopup for action 2054*


      ACTION-1490 combobox

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

mck: haven´t circled back to this from haspopup

would need to update example code

and change default to listbox

clown: need to change implicit value

rs: clarify that if not a listbox, say so

mck: yes <thinks aloud the rewording>

rs: how substantial are these changes?

mck: can do shortly after call, update the branches

clown: @@

mck: implicit value means it´s required

rs: controls should be required?

mck: is; need to add to table apparently
...

clown: mapping needs update to fix errors

<clown> action-2056

<trackbot> action-2056 -- Richard Schwerdtfeger to Coordinate the
mappings for the various AAPIs of the enumerated aria-haspopup values --
due 2016-05-17 -- OPEN

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

rs: sounds like we´re good with these changes


      ISSUE-1023

clown: will allow an item where difference is @@

?

rs: yes

in a big map, might put divisions in a menu

might not all be in DOM

does it hurt to include?

jd: could

finding practice confusing

and what if you have radiomenuitem and menuitem

how do the positions resolve?

mck: thought needed to support in spec

for mapping guide to be able to say anything

jd: don´t need that to be speced to calculate

bg: sometimes not conveyed unless explicitly set

and can have incorrect calculation

so think needs to be there

bad authoring, and can say so, but need a way to handle

jn: incorrect calculation happens with intermediate elements eg divs

rs: ok to allow author override

so ok to add?

clown: as supported?

rs: yes

<Zakim> jamesn, you wanted to say that the normal use is when the AT
messes up the computation

jd: when I do the edit, will double check there are issues we missed

<Rich> *ACTION:* Joanie add aria-posinset, aria-setsize as supported
states and properties to roles: menutitem, menuitemcheckbox, and
menuitemradio [recorded in
http://www.w3.org/2016/04/28-aria-minutes.html#action02]

<trackbot> Created ACTION-2059 - Add aria-posinset, aria-setsize as
supported states and properties to roles: menutitem, menuitemcheckbox,
and menuitemradio [on Joanmarie Diggs - due 2016-05-05].


    Summary of Action Items

*[NEW]* *ACTION:* Joanie add aria-posinset, aria-setsize as supported
states and properties to roles: menutitem, menuitemcheckbox, and
menuitemradio [recorded in
http://www.w3.org/2016/04/28-aria-minutes.html#action02]
*[NEW]* *ACTION:* Rich update aria-keyshortcuts based on pending APG
guidance [recorded in
http://www.w3.org/2016/04/28-aria-minutes.html#action01]
 


    Summary of Resolutions

 1. Accept Matt’s proposal to change aria-haspopup for action 2054
    <#resolution01>

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version
1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/04/28 18:13:54 $

------------------------------------------------------------------------


    Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]

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/Joanie/Léonie/
Succeeded: s/password field/custom password field (role="password")/
Succeeded: s/RESOLUTION: accept Matt´s changes modulo today´s discussion//
Found Scribe: matt_king
Found Scribe: MichaelC
Inferring ScribeNick: MichaelC
Scribes: matt_king, MichaelC
Present: Joanmarie_Diggs Rich_Schwerdtfeger fesch matt_king MichaelC
Joseph_Scheuhammer Bryan_Garaventa
Regrets: MichielBijl
Found Date: 28 Apr 2016
Guessing minutes URL: http://www.w3.org/2016/04/28-aria-minutes.html
People with action items: add aria-posinset aria-setsize as joanie
properties rich states supported

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


[End of scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm>
diagnostic output]

Received on Thursday, 28 April 2016 18:28:14 UTC