Meeting minutes
<Chuck> Hey Bruce! We are here, take your time.
<Chuck> Done yet? How about now?
maryjom: Hoping we can use this working session to find consensus within this smaller group on outstanding issues
… Last week we had worked on several SCs, including the one yesterday that generated some lively discussion
2.1.4 Character key shortcuts
<maryjom> https://
maryjom: opinions varied on this - 2 as is, 2 with edits, 2 something else
<maryjom> Proposed text for 2.1.4 Character Key Shortcuts 2.1.4 Character Key Shortcuts- Requires the system to provide character key shortcuts, and thus implies the entry of longer strings or commands through the keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for keyboard shortcuts, as their mode of operation is for a single key to operate[CUT]
<maryjom> ...for example, the keys are used to select options from a spoken menu rather than to enter longer strings or commands. In this case, there are no keyboard shortcuts, and thus no need to modify them.
<maryjom> Olivia's edits: 2.1.4 Character Key Shortcuts - Requires the system to offer character key shortcuts, implying the entry of longer strings or commands through the keyboard. While certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function. For example, the[CUT]
maryjom: Thought we might not need additional guidance for closed functionality
… Last week we talked about an option 3: clarify with a keyboard definition to say what is considered to be a full keyboard interface
… As closed products may have some tactilely discernible input (keys), but these might not operate in the same way as a full alphanumeric keyboard
… Then have a note in SC problematic for closed functionality that then refers to this definition of keyboard interfaces
… We could use the same approach for the keyboard operable SC
mitch11: This is interesting - unlike other kbd criteria, where absence of kbd interface, in this case absence could make it pass, as there are no single key shortcuts. So don't think this one will be identical with keyboard operable SC notes
maryjom: <looking up definition of keyboard and closed functionality>
2.1.1 keyboard had some similar notes for closed functionality
<Chuck> Note: This means that if there is no content to which a success criterion applies, the success criterion is satisfied.
Chuck: What are we trying to do? Technically we don't need to say anything about if you don't have full keyboard, you pass. As WCAG is satisfied if there is no content which satisfies the SC, then you pass
Note from Applying "keyboard interface"
<maryjom> https://
Chuck: Technically, we don't need to state anything here, but it might help clarify things for some users, then we could say something additional
mitch11: +1 to Chuck
bruce_bailey: Agree we need to help people reading this - if SC doesn't apply, then it is satisfied. May help to be explicit for these more complex SCs
maryjom: Any ICT that doesn't have character key shortcuts - not applicable - therefore automatically meet.
<Chuck> Does not contain a keyboard interface, or does not contain mechanisms that support keyboard shortcuts, or does not contain a mechanism to personalize keyboard shortcuts, the criteria is met.
Chuck: Not suggesting this is how we state it, this is just my thought process
… Logic - if keyboard shortcuts are implemented... determines whether this SC is applicable or not
… User agent could support keyboard shortcuts.
<mitch11> New draft: If a product does not have a keyboard interface, there is no possibility of keyboard shortcuts and this criterion is met. If a product relies on single key presses (e.g., on a numeric keypad) as the sole mechanism for performing a function, then this is not a "keyboard shortcut".
<mitch11> New draft: If a product does not have a keyboard interface, there is no possibility of keyboard shortcuts and this criterion is met. If a product relies on single key presses (e.g., on a numeric keypad) as the sole mechanism for performing a function, then this is not a "keyboard shortcut" and this criterion is met.
PhilDay: Just state if you don't have keyboard shortcuts, then intent of SC is met
"this criterion is met" -> change to "the intent of this SC is met" for consistency?
mitch11: Notes above are sufficient points for clarification
Chuck: mitch11 new draft looks good
<maryjom> Where there are no keyboard shortcuts or keyboard interface that provides character key input, this criterion would be met.
<maryjom> Where there are no keyboard interface that provides character key input or keyboard shortcuts, this criterion would be met.
bruce_bailey: flip around to match SC language
<maryjom> Where there is no keyboard interface that provides character key input or keyboard shortcuts, this criterion would be met.
<Chuck> Where there is no keyboard interface that provides character key input or keyboard shortcuts, this criterion is met.
Chuck: 1 minor edit to proposal. This criterion is met, not would be met.
<Chuck> Where there is no keyboard interface that provides character key input or keyboard shortcuts, the intent of this criterion is met.
mitch11: We actually do meet the criterion - not meeting the intent, so "this criterion is met" is more accurate
maryjom: intent of SC - you are meeting it in a different way, which is not the case here
<Chuck> Where there is no keyboard interface that provides character key input or keyboard shortcuts, this criterion is met.
Chuck: So we revert to this criterion is met
+1 for proposal
<olivia> +1
<maryjom> Where there is no keyboard interface that provides character key input or keyboard shortcuts, this criterion is satisfied.
this SC is satisfied, rather than met - input from bruce_bailey
mitch11: Brevity is good, but we don't quite capture the case when keys exist but no character shortcuts are present
… e.g. Olivia's proposal in survey
… worth including that use case in the note as well (mode of operation involves a single key press)
<bruce_bailey> > because their mode of operation revolves around a single key performing a single function
<maryjom> Certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, so they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function.
PhilDay: Think this is helpful to include - after the previous proposal
<maryjom> Where there is no keyboard interface that provides character key input or keyboard shortcuts, the intent of this criterion is met.
<maryjom> Certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function.
<maryjom> Where there is no keyboard interface that provides character key input or keyboard shortcuts, the intent of this criterion is satisfied.
<mitch11> Instead of "provide tactile input" I would prefer "use tactilely discernible input controls"
<Chuck> Certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function. For such systems, this criterion is satisfied.
<Chuck> Certain closed systems may use tactilely discernible input contros like numeric keypads or other functional groups of keys, they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function. For such systems, this criterion is satisfied.
<Chuck> Certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
<Chuck> Certain closed systems may provide input like numeric keypads or other functional groups of keys, they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function. For such systems, this criterion is satisfied.
Certain closed systems may provide input like numeric keypads or other functional groups of keys, they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function. For such systems, this success criterion is satisfied.
<mitch11> Certain closed systems, using input mechanisms like numeric keypads or other functional groups of keys, lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this criterion is satisfied.
<Chuck> Certain closed systems, using input mechanisms like numeric keypads or other functional groups of keys, and lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this criterion is satisfied.
<maryjom> Certain closed systems use input mechanisms that are not a full keyboard interface, such as numeric keypads or other functional groups of keys, and lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this criterion is satisfied.
<mitch11> Certain closed systems lack a mechanism for keyboard shortcuts because their mode of operation revolves around a single key performing a single function. For such systems, this criterion is satisfied.
+1 to mitch11
… and thanks to bruce_bailey for the suggested edit
<maryjom> Where there is no keyboard interface that provides character key input or keyboard shortcuts, the intent of this criterion is met.
<bruce_bailey> or ? >Where there is no keyboard interface that provides character key input or keyboard shortcuts, the criterion is satisfied
mitch11: Suggestion is to use formatting to separate the 2 thoughts - 2 notes, or 2 lines, or 2 paragraphs
bruce_bailey: Q: intent of this criteria. Should be this SC is satisfied
<Chuck> Now I'm having an issue with my headset. I'm not in via audio, I'm working the issue.
We have a proposal for that one.
2.4.7 Focus Visible
<maryjom> https://
<maryjom> Original Proposed text for 2.4.7 Focus Visible 2.4.7 Focus Visible - Requires a mode of operation where focus can be moved and controlled by keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for focus; for example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple o[CUT]
mitch11: Question on which to present on the previous SC work. So just present new proposal, or no comment at all to avoid confusion.
maryjom: Reverting to 2.4.7 survey results
<maryjom> From Olivia: 2.4.7 Focus Visible - Requires a mode of operation enabling focus movement and control by keyboard. While certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, they lack a mechanism for traditional onscreen focus. For example, keys might be used to select options from a spoken menu rather than navigating an onscreen focus element between multiple options. In such cases, the abse[CUT]
<maryjom> ... focus eliminates the need for a visible indicator.
<maryjom> From Mary Jo: This Success Criterion assumes there is a user interface component that receives keyboard focus. Menu-driven interfaces do not necessarily have visible components that receive focus, as they may have tactilely discernible input keys used to choose from a spoken menu of options. In such cases, there is no concept of focus or need for a visible focus indicator.
<maryjom> From Mitch: two things
<maryjom> 1) General note for SC: "This criterion applies where there are user interface controls that are focusable using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not display user interface controls; for example, the keys are mapped directly to functions without activating on-screen controls. In this case, there is no concept of focus and this criterion is met
<maryjom> 2) Note in SC problematic: As noted in the section [Applying SC 2.4.7 Focus Visible to Non-Web Documents and Software], when there are no on-screen controls this criterion is met. In addition, when a product with closed functionality has on-screen controls (for example, buttons on a touchscreen) and does not have a keyboard interface, there is no concept of keyboard focus and this criterion is met; however, as noted for 2.1.1 Keyboard it woul[CUT]
<Chuck> +1 Mitch
<Zakim> bruce_bailey, you wanted to note
bruce_bailey: Sometimes we say required when it is an implication, sometimes requires is an assumption, so we need to be careful in language
maryjom: Agree - need to be careful with language and not imply a requirement to have a certain aspect (e.g. focus visible).
Chuck: Like mitch11, would change met to satisfied. However, all 3 are close - mitch11 is closest IMO
<bruce_bailey> +1 to mitch (sub satisfied for met)
<olivia> +1 to mitch
+1 to Mitch (satisfied)
We will go with that proposal then
<Chuck> I need to go to another W3C call :-)
public comment issues
Take a look at them if you have time & propose updates
Next Friday we will focus on developing comments for the remaining Public Comment issues
maryjom: Suggest the contentious issue Name Role Value be opened as dicussion on GitHub to avoid taking another meeting over