- From: Matt King <a11ythinker@gmail.com>
- Date: Thu, 28 Apr 2016 11:27:43 -0700
- To: "'ARIA Working Group'" <public-aria@w3.org>
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