See also: IRC log
<mck> Testing JAWS readback of typed info
<mck> not working, bummer.
<Rich> 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
<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.
<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.
<MichaelC> scribe: MichaelC
<mck> 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
<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
<Rich> 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
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].
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 diagnostic output]