See also: IRC log
<scribe> Scribe: Glenda
<Joshue108> https://github.com/w3c/wcag21/issues/501
<Joshue108> https://github.com/w3c/wcag21/pull/512
Reviewing item 3 on the survey https://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/ Response to comment on 2.4.11 Character Key Shortcuts #501
See: https://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/results#xnew2
11 accept as proposed with 3 comments requesting changes
AWK: my suggestion is a rephrasing. “I think that this one should be handled more in line with the HTML5 spec for keyboard shortcuts.
If a <a>keyboard shortcut</a> consisting entirely of one or more <a>character keys</a> is implemented by the content @@to activate or focus a control that is not currently focused@@, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key.”
JF: prefer that we use the wording “modifier key”
<JF> https://www.w3.org/2002/09/wbs/66524/20170920_survey/results#xq4
AWK: the character key question and modifier key is handled in the definiiton. We could make it clearer. But I think we should deal with that separately.
Joshue: Can everyone live with this?
David: There are 3 proposals. One from David, one from Steve/Detlev, one from AWK
<jimal> +1 to andrew proposal
<AWK> Original: If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key.
Detlev’s suggestion: would suggest to change the text from
"unless the character key is only active when a control has focus"
to
"unless the keyboard shortcut is only active when a control has focus"
<AWK> Detlev's: If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key, unless the keyboard shortcut is only active when a control has focus
<david-macdonald> unless the character key is only active when a control has focus.
<AWK> Steve's: If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key, unless the keyboard shortcut is only active when a particular user interface component has focus
<AWK> AWK's: If a <a>keyboard shortcut</a> consisting entirely of one or more <a>character keys</a> is implemented by the content @@to activate or focus a control that is not currently focused@@, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key.
<jasonjgw> +1 to Andrew's formulation.
JF: be consistent and use “control” or “user interface component”. Also have concerned about what a non-character key is. Will need a definition.
<Zakim> steverep, you wanted to say the current pull has my proposal in it
<steverep> Current pull request is http://rawgit.com/w3c/wcag21/resolve-issue-501/guidelines/#character-key-shortcuts
Joshue: I agree on consistency. Prefer “control”.
<Joshue108> If a <a>keyboard shortcut</a> consisting entirely of one or more <a>character keys</a> is implemented by the content @@to activate or focus a control that is not currently focused@@, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key, unless the keyboard shortcut is only active when a particular control component has focus.
<Joshue108> or If a <a>keyboard shortcut</a> consisting entirely of one or more <a>character keys</a> is implemented by the content @@to activate or focus a control that is not currently focused@@, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key, unless the keyboard shortcut is only active when a particular user interface component has focus.
Jason: we use the term “user interface component” more consistenly then we use the word “control”
<AWK> +AWK
<AWK> John, what if we replaced "one non-character key" with "one key that is not a character key"?
<laura> character key definition: http://rawgit.com/w3c/wcag21/resolve-issue-501/guidelines/#dfn-character-keys
JF: 26 references to user interface component and 36 references to control. We need to tighten that up. We are using both terms. We need to standardize.
AWK: the word “control” is in the
definition of “user interface component”. So, we can look at
this as a different item. Let’s focus on the proposed SC text
that Josh has just written (see next).
... reconsider the contrstuction of my proposal. easier to read
and easier to parse.
Joshue: can steve and detlev live with AWK’s proposal
<Joshue108> If a keyboard shortcut consisting entirely of one or more character keys is implemented by the content to activate or focus a control that is not currently focused, then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key.
<KimD> Should Andrew's say "...to activate or ++give++ focus ++to++ a control that --is not-- ++does not++ currently have focus..."?
Steve: Yes. I can live with AWK’s proposal.
<Ryladog> +1
<AWK> uses "focus" as a verb in mine, like in the HTML5 spec
Joshue: straw poll, who can live with AWK’s proposal?
<jimal> +1
<laura> +1
<KimD> +1 with a little clean up
<Brooks> +1
JF: real problem is single key shortcuts. so the mechanism to turn it off, I can support that. But the remapping to multiple key shortcut that includes a modifier and another key. I’m not sure this is being conveyed.
<alastairc> Sorry, i have to depart now, I'll check the minutes later tonight.
then a mechanism is available to turn it off or to remap it to a shortcut that uses at least one non-character key. (should be “at least one non-character key and a modifer key).
JF: need a modifer key plus
<Joshue108> https://en.wikipedia.org/wiki/Control_character
<jimal> modifier key for access key is controlled by the browser
<jimal> single key (hot key) in a web application is controlled by the author in javascript ... not anything like accesskey
<Zakim> Joshue, you wanted to say Single character short cuts are not accesskey
<AWK> @JF, your concern is not with my text, but with the original SC text
JF: my concern with AWK’s language is that I could map the single character shortcut key of “L” to “CTRL”. It needs to require at least 2 keys (one being a modifier).
Joshue: need to leave this open, need to do more research, I think
AWK: I’m not seeing the issue
that JF is raising is part of what we are trying to address
here. There is a cascade problem here.
... we need to address James comment first. Then we can address
JF’s issue. One at a time.
<JF> +1 Josh
Joshue: we need to have James and JF discuss this on Tuesday
RESOLUTION: leave open until Tuesday so JF and James can discuss and find a solution
<david-macdonald> I had to step out for a bit, back now
<laura> https://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/results
<steverep> https://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/results
<laura> 1.4.12 User Interface Component Contrast (Minimum) #490 should be up next: https://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/results#xnew3
AWK: TOPIC: UIC Contrast
AWK: 5 people agree. 8 say not to
accept this change. This will be a really hard one.
... my suggestion is we discuss this at TPAC
<Zakim> steverep, you wanted to point out a possible loophole in AWK's proposal if the control is not immediately focusable?
Jason: this is complex, will need to discuss this with colleagues more.
JF: I support James in 3 to 1 being sufficient.
<laura> The need is real. LVTF reached out to Gordon Legge, Distinguished low vision researcher from the University of Minnesota. His recommendation is in my survey response. He summed it up by saying, "Bottom line: Contrast requirements for form controls should be equivalent to contrast requirements for text..."
David: 2 sides and both have
valid concerns. Testing burden on this would be high. Concerned
about 3 way contrast for focus indicator.
... probably need to take this up at TPAC
<Zakim> jimal, you wanted to say many techniques to adjust focus indicator
<Zakim> AWK, you wanted to say that this also covers selection color, such as in a listbox
Jim: The 3 way contrast, there is always outline offset, to move it 3 pixels away, then you really are just dealing with a 2 color contrast (not 3). Or dashed lines, can get you to only need to be concerned about 2 colors.
<laura> If an author touches it, then they need to do it right. If they don't, then it's a browser issue and they are off the hook.
Jim: if the author didn’t make a change, then there is an exception. If they do make their own components, they need to make it visible.
<Zakim> steverep, you wanted to say there are many many ways to avoid 3-way, and those may need normative changes to convey properly
Steve: There are so many ways in CSS to make things more distinguishable. You can completely avoid the 3 way contrast problem. We just need to work on how to avoide the 3 way contrast problem.
RESOLUTION: Leave UIC Contrast discussion for TPAC
https://www.w3.org/2002/09/wbs/35422/Oct_17th_agwg/results#xcorrect
11 support, 2 suggest changes, 2 want more time or do not accept
<AWK> https://github.com/w3c/wcag21/pull/406/files
AWK: this is a simple change, and if we focus on the “OR” to “AND”
JF: I was involved in the writing of this SC. Intent all along was to say “AND”
Jason: agreeing with JF. Other issues are all separate from what this particular question. Looks like there is good support.
AWK: the other comments are important, but we will deal with the separately.
<JF> +1
RESOLUTION: Accept as proposed. Will ssend out CFC on this!
trackbot end meeting
trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/30+ references/36 references/ Succeeded: s/TOPIC: Device Sensors// Default Present: jallan, JakeAbma, interaccess, bruce_bailey, Roy, Laura, jamesn, jasonjgw, Kathy, MikeGower, kirkwood, Makoto, KimD, Greg_Lowney, Mike_Elledge, Brooks, steverep, JF, Katie_Haritos-Shea, Glenda, david-macdonald, marcjohlic, Detlev, Joshue108, alastairc, shadi__, MichaelC, jimal, AWK Present: jallan JakeAbma interaccess bruce_bailey Roy Laura jamesn jasonjgw Kathy MikeGower kirkwood Makoto KimD Greg_Lowney Mike_Elledge Brooks steverep JF MichaelC jimal Katie_Haritos-Shea david-macdonald marcjohlic Found Scribe: Glenda Inferring ScribeNick: Glenda WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 19 Oct 2017 Guessing minutes URL: http://www.w3.org/2017/10/19-ag-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]