13:42:17 RRSAgent has joined #wcag2ict 13:42:22 logging to https://www.w3.org/2024/01/05-wcag2ict-irc 13:42:22 RRSAgent, make logs Public 13:42:53 Meeting: WCAG2ICT Task Force Teleconference 13:42:53 zakim, clear agenda 13:42:53 agenda cleared 13:42:53 chair: Mary Jo Mueller 13:42:54 meeting: WCAG2ICT Task Force extra Friday meeting 13:43:08 zakim, please time speakers at 2 minutes 13:43:08 ok, maryjom 13:44:28 agenda+ SC Problematic for Closed functionality bullets 13:44:56 agenda+ Work on unassigned public comments 13:57:27 PhilDay has joined #wcag2ict 13:57:31 present+ 14:00:22 Chuck has joined #wcag2ict 14:00:34 present+ 14:00:42 Mike_Pluke has joined #wcag2ict 14:01:46 olivia has joined #wcag2ict 14:02:18 present+ 14:02:21 scribe+ olivia-hogan-stark 14:02:31 present+ 14:02:42 present+ 14:02:47 zakim, take up item 1 14:02:47 agendum 1 -- SC Problematic for Closed functionality bullets -- taken up [from maryjom] 14:02:52 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-last-5/results#xq4 14:03:11 maryjom: Split vote yesterday 14:03:26 present+ Daniel 14:05:03 maryjom: We had made a previous decision to add bullets to make it more complete. But it does cause a bit of extra repeating. 14:05:39 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. 14:05:53 above is from Option 1 14:06:55 q+ 14:07:03 ack PhilDay 14:07:42 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.) 14:07:42 philday: I think it is worth calling out. Happy to go with majority. 14:09:38 maryjom: We will take up next week with group 14:09:56 4.1.2 question: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-last-5/results#xq5 14:10:15 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. 14:11:29 maryjom: I would like to adjust what I have proposed 14:11:55 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. 14:12:22 maryjom: this would give us consistent phrasing 14:12:31 +1 I'm happy with the modification - intent of SC would be met 14:12:46 +1 to consistency! 14:12:48 Do you like the above modification? 14:12:52 +1 from me 14:13:08 maryjom: we'll take that to full task force 14:13:53 2.1.2 No Keyboard Trap: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-last-5/results#xq6 14:14:25 maryjom: Some edits, some alternative proposals 14:14:46 Proposed for 2.1.2 in survey... 14:14:47 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] 14:15:36 olivia: My edits were structural 14:15:51 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] 14:16:04 applicable due to the absence of a focus. 14:16:24 q+ 14:17:34 ack PhilDay 14:18:24 PhilDay: I still think it is useful to have some note for folks not familiar with minutia of keyboard focus. 14:19:23 Mitch's suggested note: 14:19:24 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. 14:19:25 q 14:19:34 q+ to say modify Mitch's 14:19:40 ack PhilDay 14:19:40 PhilDay, you wanted to say modify Mitch's 14:20:12 philday: I think that would be good, but modify. Say "the intent...". 14:20:15 q+ 14:20:40 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. 14:20:55 ack Mike_Pluke 14:21:04 mike_pluke: I agree with Phil on Mitch's note 14:21:39 maryjom: Prefer this in the general SC or something in both? 14:21:50 q+ 14:21:57 ack PhilDay 14:23:13 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. 14:25:13 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. 14:25:38 maryjom: will take up with group next week 14:26:08 2.1.4 Character Key Shortcuts: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-last-5/results#xq7 14:26:30 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] 14:26:42 ...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. 14:27:27 Olivia's proposed edits: 14:27:29 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] 14:27:55 ...spoken menu rather than entering longer strings or commands. In such cases, the absence of keyboard shortcuts eliminates the need for modification. 14:29:39 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. 14:30:04 Do we really need this bullet for 2.1.4? 14:30:07 q+ 14:30:13 ack PhilDay 14:31:32 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. 14:31:53 maryjom: should there be a wcag2ict guidance to definition of a keyboard? 14:31:54 q+ 14:32:05 ack Chuck 14:33:12 chuck: As devil's advocate, our responsibility is to state how to apply wcag to ict. Might be going beyond our charter. 14:33:50 q+ 14:34:24 maryjom: We could add notes to keyboard interface 14:34:53 q+ 14:35:16 present+ Daniel 14:36:09 maryjom: we can say something like not all ict has a true keyboard 14:36:19 maryjom: Should I open an issue? 14:36:42 philday: That plus Olivia's modifications would be a good place to start 14:37:42 philday: one thing that helped in 508 and EN was differentiating keyboard and tactile input. 14:38:29 maryjom: I'll open an issue. Figure out where it needs to go. 14:39:34 philday: If we have a general definition, we can refer back to it in closed functionality section 14:39:54 2.4.7 Focus Visible https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-last-5/results#xq8 14:40:15 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] 14:40:37 ...and therefore there is no need for a visible indicator. 14:41:15 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. 14:41:24 ...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. 14:42:07 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. 14:43:13 q+ to say modify Mitch's suggestions for consistency of language with others (intent of this SC is met...) 14:43:17 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." 14:43:31 ack Mike_Pluke 14:43:59 ack PhilDay 14:43:59 PhilDay, you wanted to say modify Mitch's suggestions for consistency of language with others (intent of this SC is met...) 14:44:32 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] 14:44:35 philday: I like the concept in Mitch's idea, work on language 14:44:41 ...to access all functionality. 14:45:17 Edit to Mitch's suggestion. Replace "this criterion is met" with "the intent of this success criterion is met" 14:45:26 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. 14:45:34 ... In both the general note and SC problematic notes 14:47:15 maryjom: That's the survey 14:47:23 zakim, next item 14:47:23 agendum 2 -- Work on unassigned public comments -- taken up [from maryjom] 14:48:19 Issue 230: 2.6 Software https://github.com/w3c/wcag2ict/issues/230 14:51:39 q+ 14:51:49 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. 14:51:50 ack PhilDay 14:53:29 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. 14:55:19 maryjom: In document section we have examples. There are a ton of notes. 14:55:49 maryjom: I can attempt to write using some of Mitch's thoughts. 14:57:12 philday: is there a difference between software and user agent? 14:58:10 maryjom: We do say that a user agent is software 14:59:02 hard stop, I need to jump to another call. 14:59:29 mike_pluke: The grey areas may not matter greatly 14:59:48 maryjom: Matters with reporting 15:00:54 maryjom: I will attempt to write up something 15:01:29 maryjom: take a look at other open issues for next week 15:01:36 rrsagent, make minutes 15:01:37 I have made the request to generate https://www.w3.org/2024/01/05-wcag2ict-minutes.html olivia 15:01:56 zakim, end meeting 15:01:56 As of this point the attendees have been PhilDay, Chuck, olivia, Mike_Pluke, maryjom, Daniel 15:01:58 RRSAgent, please draft minutes v2 15:01:59 I have made the request to generate https://www.w3.org/2024/01/05-wcag2ict-minutes.html Zakim 15:02:04 I am happy to have been of service, maryjom; please remember to excuse RRSAgent. Goodbye 15:02:06 Zakim has left #wcag2ict 15:02:10 rrsagent, bye 15:02:10 I see no action items