Meeting minutes
SC Problematic for Closed functionality bullets
<maryjom> https://
<olivia> maryjom: Split vote yesterday
<olivia> maryjom: We had made a previous decision to add bullets to make it more complete. But it does cause a bit of extra repeating.
<maryjom> 3.2.3 Consistent Navigation—This Success Criterion is interpreted to only apply to "sets of software programs" which are very rare. See the second note in the section Applying SC 3.2.3 Consistent Navigation to Non-Web Documents and Software.
<maryjom> above is from Option 1
<maryjom> What is in the main guidance: NOTE 1 See set of documents and set of software programs in the Key Terms section of the Introduction to determine when a group of documents or software programs is considered a set for this success criterion. (Sets of software that meet this definition appear to be extremely rare.)
<olivia> philday: I think it is worth calling out. Happy to go with majority.
<olivia> maryjom: We will take up next week with group
<maryjom> 4.1.2 question: https://
<maryjom> Most preferred Option 2: Incorporate suggested edits 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Where another mechanism provides this information for built-in assistive technology functions, this criterion does not apply.
<olivia> maryjom: I would like to adjust what I have proposed
<maryjom> I had proposed: 4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Where another mechanism provides equivalent information as built-in assistive technology functionality, the intent of this success criterion would be met.
<olivia> maryjom: this would give us consistent phrasing
<PhilDay> +1 I'm happy with the modification - intent of SC would be met
<olivia> +1 to consistency!
<maryjom> Do you like the above modification?
<Mike_Pluke> +1 from me
<olivia> maryjom: we'll take that to full task force
<maryjom> 2.1.2 No Keyboard Trap: https://
<olivia> maryjom: Some edits, some alternative proposals
<maryjom> Proposed for 2.1.2 in survey...
<maryjom> 2.1.2 No Keyboard Trap- 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 options. In this case, there is no concept of fo[CUT]
<Chuck> olivia: My edits were structural
<maryjom> Olivia's proposed edits: 2.1.2 No Keyboard Trap - Requires a mode of operation where users can navigate and control focus using the keyboard. In some closed systems, tactile input like numeric keypads or other functional groups of keys may be available, but there is no mechanism for onscreen focus. For example, keys might be used to select options from a spoken menu rather than moving an onscreen focus element. In such cases, traditional keyb[CUT]
<maryjom> applicable due to the absence of a focus.
<olivia> PhilDay: I still think it is useful to have some note for folks not familiar with minutia of keyboard focus.
<maryjom> Mitch's suggested note:
<maryjom> This criterion applies when focus can be moved using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not offer any mechanism for focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore keyboard traps cannot exist and this criterion is met.
<Zakim> PhilDay, you wanted to say modify Mitch's
<olivia> philday: I think that would be good, but modify. Say "the intent...".
<maryjom> This criterion applies when focus can be moved using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not offer any mechanism for focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore keyboard traps cannot exist and the intent of this success criterion is met.
<olivia> mike_pluke: I agree with Phil on Mitch's note
<olivia> maryjom: Prefer this in the general SC or something in both?
<olivia> philday: Closed functionality section might be the only place somewhere looks. So it would be useful to have in both places. Then take Olivia's modifications.
<maryjom> Take Olivia's edits and use for the SC Problematic section with a reference to the main guidance and then the Mitch's edits with above change in main SC guidance.
<olivia> maryjom: will take up with group next week
<maryjom> 2.1.4 Character Key Shortcuts: https://
<maryjom> Original proposal: 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 a single function; for exampl[CUT]
<maryjom> ...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 proposed edits:
<maryjom> 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 keys are used t[CUT]
<maryjom> ...spoken menu rather than entering longer strings or commands. In such cases, the absence of keyboard shortcuts eliminates the need for modification.
<olivia> maryjom: The intent is to prevent accidental activation on single character keyboard shortcuts. I think in most closed functionality it would likely be automatically met. I was thinking it doesn't need additional guidance - it automatically meets.
<maryjom> Do we really need this bullet for 2.1.4?
<olivia> philday: we don't have any more help here for people designing closed systems. Still think it is useful to have additional context. I do worry some people might assume, for example, three buttons = keyboard.
<olivia> maryjom: should there be a wcag2ict guidance to definition of a keyboard?
<olivia> chuck: As devil's advocate, our responsibility is to state how to apply wcag to ict. Might be going beyond our charter.
<olivia> maryjom: We could add notes to keyboard interface
<olivia> maryjom: we can say something like not all ict has a true keyboard
<olivia> maryjom: Should I open an issue?
<olivia> philday: That plus Olivia's modifications would be a good place to start
<olivia> philday: one thing that helped in 508 and EN was differentiating keyboard and tactile input.
<olivia> maryjom: I'll open an issue. Figure out where it needs to go.
<olivia> philday: If we have a general definition, we can refer back to it in closed functionality section
<maryjom> 2.4.7 Focus Visible https://
<maryjom> Original proposal: 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 options. In this case, there is[CUT]
<maryjom> ...and therefore there is no need for a visible indicator.
<maryjom> Olivia's proposed edits: 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.
<maryjom> ...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 absence of a conventional focus eliminates the need for a visible indicator.
<maryjom> Mary Jo's suggestion: 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> Mitch's proposal - add to General SC guidance: "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."
<Zakim> PhilDay, you wanted to say modify Mitch's suggestions for consistency of language with others (intent of this SC is met...)
<maryjom> bullet 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]
<olivia> philday: I like the concept in Mitch's idea, work on language
<maryjom> ...to access all functionality.
<PhilDay> Edit to Mitch's suggestion. Replace "this criterion is met" with "the intent of this success criterion is met"
<maryjom> With first sentence modified for consistency: 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 the intent of this criterion is met.
<PhilDay> ... In both the general note and SC problematic notes
<olivia> maryjom: That's the survey
Work on unassigned public comments
<maryjom> Issue 230: 2.6 Software w3c/
<olivia> maryjom: There has been some discussion. Mitch added thoughts. It is an intricate topic. Do we need to add these examples? Someone asks about kiosks.
<olivia> Philday: we do differentiate between documents and software elsewhere. I wonder if that is where this is coming from. Not sure if we can add notes without confusion.
<olivia> maryjom: In document section we have examples. There are a ton of notes.
<olivia> maryjom: I can attempt to write using some of Mitch's thoughts.
<olivia> philday: is there a difference between software and user agent?
<olivia> maryjom: We do say that a user agent is software
<Chuck> hard stop, I need to jump to another call.
<olivia> mike_pluke: The grey areas may not matter greatly
<olivia> maryjom: Matters with reporting
<olivia> maryjom: I will attempt to write up something
<olivia> maryjom: take a look at other open issues for next week