13:45:07 RRSAgent has joined #wcag2ict 13:45:11 logging to https://www.w3.org/2026/07/02-wcag2ict-irc 13:45:11 agenda cleared 13:45:11 RRSAgent, make logs Public 13:45:12 Meeting: WCAG2ICT Task Force Teleconference 13:45:19 meeting: WCAG2ICT Task Force Teleconference 13:45:19 rrsagent, make minutes 13:45:20 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html PhilDay 13:45:45 zakim, please time speakers at 2 minutes 13:45:45 I don't understand 'please time speakers at 2 minutes', PhilDay 13:45:56 zakim, please time speakers at 2 minutes 13:45:56 ok, PhilDay 13:46:05 agenda+ Announcements 13:46:05 agenda+ SC 2.1.1 'Problematic for Closed' suggests ways of meeting SC 2.1.1 Keyboard that don't align with the SC. 13:46:05 agenda+ SC 1.4.11 Non-text Contrast 'Problematic for Closed' needs improvement. 13:46:05 agenda+ Editorial "Document(s)" vs "Non-web documents" #949 13:46:12 present+ 13:46:31 RRSAgent, make minutes 13:46:32 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html PhilDay 13:46:53 chair+ PhilDay 13:47:00 RRSAgent, make minutes 13:47:01 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html PhilDay 13:59:07 GreggVan has joined #wcag2ict 14:00:36 present+ 14:00:53 loicmn has joined #wcag2ict 14:00:57 present+ Daniel 14:01:30 bbailey has joined #wcag2ict 14:01:57 present+ 14:02:00 zakim, agenda? 14:02:00 I see 4 items remaining on the agenda: 14:02:01 1. Announcements [from PhilDay] 14:02:01 2. SC 2.1.1 'Problematic for Closed' suggests ways of meeting SC 2.1.1 Keyboard that don't align with the SC. [from PhilDay] 14:02:01 3. SC 1.4.11 Non-text Contrast 'Problematic for Closed' needs improvement. [from PhilDay] 14:02:01 4. Editorial "Document(s)" vs "Non-web documents" #949 [from PhilDay] 14:02:05 present+ 14:02:13 zakim, take up next 14:02:13 agendum 1 -- Announcements -- taken up [from PhilDay] 14:02:30 PhilDay: No announcements from me 14:02:42 ... We will get through a few items today, there are other that are mainly editorial 14:03:05 ... The problematic for close appendix requires more work, Daniel will take it 14:03:28 ... Then a couple more editorials, and read through the whole document, and then AGWG review 14:03:28 zakim, close item 14:03:28 I don't understand 'close item', Daniel 14:03:29 zakim, take up next 14:03:30 agendum 2 -- SC 2.1.1 'Problematic for Closed' suggests ways of meeting SC 2.1.1 Keyboard that don't align with the SC. -- taken up [from PhilDay] 14:03:35 Link to issue: https://github.com/w3c/wcag2ict/issues/947 14:03:52 Proposal 1 - 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. In a closed environment where a keyboard interface is not available, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by persons with 14:03:52 disabilities. 14:03:52 Proposal 2 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices. 14:03:52 Proposal 3 - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT which then allows for alternate input devices. 14:03:54 Proposal 4 (which is Proposal 3 with some of Proposal 1) - 2.1.1 Keyboard — Assumes access to a keyboard interface by AT is not true for closed functionality. This access allows for alternate input devices. Therefore some other non-WCAG requirements would be needed to ensure that content is operable by persons with disabilities. 14:03:54 Proposal 5 - Phil possible reword of proposal 1 14:03:54 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternate input devices to be used. In a closed environment where external access to a keyboard interface is not allowed, it may not be possible to meet this criterion, and some other non-WCAG requirements would be needed to ensure that content is operable by 14:03:55 persons with some disabilities including limited mobility and persons without vision. 14:03:55 Proposal 6 - Gregg's latest 14:03:55 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface or where access to the 14:03:56 keyboard interface is closed off for assistive technologies, some other non-WCAG requirements would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input. 14:04:17 PhilDay: Six proposals, with some updates put into the issue, plus a comment by Bruce on the issue some minutes ago 14:04:54 q+ to ask that they seem very close to each other? 14:05:02 q+ Laura 14:05:05 ack bbailey 14:05:05 bbailey, you wanted to ask that they seem very close to each other? 14:05:22 bbailey: I think we could reduce this to two-three proposals instead of six 14:05:30 ack bbailey 14:05:36 ... And then go one sentence at a time 14:06:07 Laura: I just have an issue with EZ 14:06:26 GreggVan: It's a technique, not a brand, but still it's a name of a specific solution 14:06:31 Laura: Accessible keypad maybe 14:06:38 bbailey: I don't have these worddsin what I proposed 14:06:50 GreggVan: Also don't use keypad, there are solutions that do not necessarily involve keypads 14:07:22 loicmn has joined #wcag2ict 14:07:25 ... Have a look at my otheer comment 14:07:31 present+ 14:08:03 bbailey: Proposals 4 and 5 14:08:20 PhilDay: I think proposals 4, 5 and 6 were all built on 1, 2, 3. Should we just focus on 4, 5, and 6? 14:08:50 GreggVan: I think we should go with 6 which is longer ,but there is so much confusion about this 14:08:55 I am all for longer explanation myself! 14:09:02 This is what we currently have in the editor's draft for reference. 14:09:02 We are just discussing a change to NOTE 6 14:09:02 2.1.1 Keyboard — Assumes operation via a keyboard interface which also allows for alternative input devices. It may not be possible to satisfy this success criterion when the ICT does not have a built-in keyboard, and it also does not support an alternative input method (hardware or software) that provides keyboard-like access to all 14:09:02 functionality. 14:09:04 NOTE 6 14:09:04 A keypad that provides full access to functionality might be considered a keyboard. 14:09:13 Daniel: +1 for expanding and explaining 14:10:31 GreggVan: There's duplication around not accepting input from a keyboard interface and having closed keyboard interfaces 14:10:39 bbailey: Agree, just to follow your second sentences 14:10:44 +1 to explanatory text. 14:11:08 PhilDay: Looks like everybody is in agreement about proposing some level of elaboration 14:11:22 ... We are just talking about the replacement for note 6, the bullet above will remain 14:11:38 ... Does anyone prefer something other than proposal 6? 14:12:52 PhilDay: Let's work on proposal 6 14:13:13 Proposal 6a - Gregg's original 14:13:13 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface or where access to the 14:13:13 keyboard interface is closed off for assistive technologies, some other non-WCAG requirements would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input. 14:13:13 Proposal 6b - Bruce's edit 14:13:15 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface or where access to the 14:13:15 keyboard interface is closed to assistive technologies, other requirements would be needed to ensure accessibility. 14:14:21 bbailey: I don't want it to be specific about alternativekeyboard input, unless we want to say that supporting easy keys would meet that 14:14:33 GreggVan: Easy keys is a solution, not the problem 14:15:10 Proposal 6c - Gregg's latest 14:15:10 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed for 14:15:10 assistive that involve alternate keyboards technologies, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input. 14:16:01 closed FOR assisistive technology - or - closed TO assistive technology ? 14:16:15 Proposal 6c - Gregg's latest 14:16:15 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed to 14:16:15 assistive technologies that involve alternate keyboards, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input. 14:16:18 Laura: Should be closed to 14:16:21 GreggVan: Yes 14:16:47 +1 to the last proposal 14:16:48 i like 6c 14:17:01 GreggVan: We should stop at how you solve the problem. Anything we say is going to codify that we think you should solve it this or the other way 14:17:20 ... Easy Keys is codified in ISO 9241171 14:17:45 Daniel: Like proposal 6c 14:18:13 Daniel: There's tyuwoh insthahhhnhhhhchyetsu of puruuuouuuuvide 14:18:41 GreggVan: I think they should stay, if you say a different word it means it is implying something else 14:18:47 Dainel: Not oging to die on this one 14:18:58 s/tyuwoh insthahhhnhhhhchyetsu of puruuuouuuuvide/two instances of provide/ 14:19:25 Daniel: "provide alternativewaysa to provide" I really meant these two 14:20:00 s/Not oging to die on this one/Not going to object to this one/ 14:20:06 Daniel: Should substitute for the first "provide" 14:20:11 Proposal 6c - Gregg's latest 14:20:11 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways to provide "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed to 14:20:11 assistive technologies that involve alternate keyboards, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input. 14:20:25 s/alternativewaysa/alternative ways/ 14:20:51 GreggVan: Still think these are good as they are 14:21:05 PhilDay: Enable? 14:21:17 GreggVan: Enable means it's there and you just have to enable it 14:21:24 RRSAgent, draft minutes 14:21:26 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html bbailey 14:22:07 Copy of latest proposal: https://github.com/w3c/wcag2ict/issues/947#issuecomment-4866779149 14:23:00 scribe+ Daniel 14:23:19 Laura: What about "beyond"? We are talking about the software and not go into the harddware space, we should be cautions 14:23:35 ... Also, requirements beyond WCAG is really requirements beyond software, which would be out of scope 14:24:14 GreggVan: You cannot get to harware from within WCAG, if you go beyond WCAG you can then get into software 14:24:28 Laura: But that'd be out of scope for WCAG2ICT anyways 14:24:35 q+ to say i think proposal 6c is okay scope wise 14:24:51 PhilDay: Laura, are you concerned with the phrase "requirements beyond WCAG"? 14:25:01 Laura: Yes. Also with the way we are talking about keyboard 14:25:14 ... We are talking about the keyboard functionality, not about a physical keyboard 14:25:40 PhilDay: I've checked the current Editor's Note and we've used the phrase "other non-WCAG requirements in other SCs already" 14:25:54 bbailey: Agree with consistency, we should take the edit here and apply to the others 14:26:00 ack bbailey 14:26:00 bbailey, you wanted to say i think proposal 6c is okay scope wise 14:26:19 bbailey: I think we are hitting the right amountof detail 14:26:45 Latest version with offer instead of provide: 14:26:45 Proposal 6c - Gregg's latest 14:26:45 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways for "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed to 14:26:45 assistive technologies that involve alternate keyboards, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input. 14:27:30 Latest edits from Gregg on proposal 6c: 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways FOR "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard 14:27:30 interface and are therefore closed to assistive technologies that involve alternate KEYBOARD INPUT, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input. 14:27:53 PhilDay: Methods rather than techniques? 14:27:56 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways FOR "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed to 14:27:57 assistive technologies that involve alternate KEYBOARD INPUT METHODS, some requirements beyond WCAG's would be needed to ensure that content is operable by persons with disabilities that require them to use alternate keyboard input. 14:28:07 Daniel: Resolves my concern 14:28:11 Daniel: That would resolve my comment 14:28:26 Laura: Mine too, that's fine 14:28:32 DRAFT RESOLUTION: For SC problematic for 2.1.1 Keyboard on incorporate proposal 6c into the editor’s draft, with edits shown in the meeting minutes above 14:28:35 +1 14:28:39 +1 14:28:40 +1 14:28:42 +1 14:28:46 +1 14:28:47 Laura: +1 14:28:49 q+ 14:28:57 RESOLUTION: For SC problematic for 2.1.1 Keyboard on incorporate proposal 6c into the editor’s draft, with edits shown in the meeting minutes above 14:29:03 ack laur 14:29:09 ack bbailey 14:29:53 q+ 14:30:08 ack Daniel 14:30:39 Daniel: We should use "people" instead of "persons with edisabilities" 14:31:07 bbailey: Necessary? 14:31:11 PhilDay: Yes. 14:31:14 GreggVan: Yes 14:31:34 Final edit: 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways for "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed 14:31:34 to assistive technologies that involve alternate keyboard input methods, some requirements beyond WCAG's would be needed to ensure that content is operable by people with disabilities for whom it is necessary to use alternate keyboard input. 14:32:39 Final edit: 2.1.1 Keyboard — is based on the assumption that assistive technologies have access to the keyboard interface and can thus provide alternate ways for "keyboard" input alongside any other mechanism (internal or external) provided for keyboard input. In products that do not accept input from a keyboard interface and are therefore closed 14:32:39 to assistive technologies that involve alternate keyboard input methods, some requirements beyond WCAG's would be needed to ensure that content is operable by people with disabilities for whom it is necessary to use alternate keyboard input methods. 14:32:58 Laura: Only concern is how long it is, but we don't seem to have another alternative 14:33:21 PhilDay: I think that's good, as we are reading it people will be able to put it in context 14:33:45 s/edisabilities/disabilities/ 14:33:56 ACTION: Editors to check SC problematic for closed for use of the phrase "other non-WCAG requirements" and substitute with "requirements beyond WCAG's" 14:34:23 zakim, take up next 14:34:23 agendum 3 -- SC 1.4.11 Non-text Contrast 'Problematic for Closed' needs improvement. -- taken up [from PhilDay] 14:34:29 Link to issue: https://github.com/w3c/wcag2ict/issues/946 14:34:41 Proposal 0 - current version 14:34:41 1.4.11 Non-text Contrast — There are cases where applying this success criterion to non-web software on ICT with closed functionality is problematic: 14:34:41 When the contrast of the content is determined by the hardware and not modifiable by the software author, it may not be possible to meet this success criterion. 14:34:41 Note 4 Contrast requirements for hardware are out of scope for WCAG2ICT (and this success criterion). 14:34:43 When the color contrast ratio cannot be programmatically measured due to system limitations (e.g. lockdown), precise quantifiable testing of color contrast cannot be performed by a third party. In such cases, the software author would need to confirm that the color combinations used meet the contrast requirement. 14:34:43 Note 5 Photographs are not sufficient for testing that content meets this success criterion. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes. 14:34:52 Proposal 1 - Mitch's edit 14:34:52 1.4.11 Non-text Contrast — There are cases where applying this success criterion to non-web software on ICT with closed functionality is problematic: 14:34:52 When software authors can modify the appearance of content, but only within a limited contrast range determined by hardware, it may not be possible to meet this success criterion. 14:34:52 [Following notes are unchanged] 14:36:48 PhilDay: I am happy with the edit 14:37:21 +1 to Mitch's proposal 14:37:52 GreggVan: I don't understand why that's different from software as a whole 14:38:21 ... Authors are only responsible for the specified content 14:38:39 ... If your software specifies a valid contrast even if the hardwaare doesn't render it, you comply 14:38:47 +1 to moving some of these comments out of closed and make them notes to the SC 14:38:54 PhilDay: If your hardware limits you you may not have the same freedom 14:39:13 GreggVan: It's just the reality of life problem, doesn't have to do with the limits of the hardware 14:40:07 GreggVan: If we talk about the contrast of the label or control that are inked that is a different topic 14:40:23 PhilDay: We are talking about onscreen, not labels affixed to the hardware 14:40:50 q+ 14:41:22 ack Daniel 14:42:20 Daniel: The product wouldn't be meeting the contrastratio regardless of whether the author can specify the contrast 14:43:14 GreggVan: What I am saying is that it is a problem, but ont only for closed functionality, it would be for all software 14:43:17 https://w3c.github.io/wcag2ict/#applying-sc-1-4-11-non-text-contrast-to-non-web-documents-and-non-web-software 14:43:36 https://w3c.github.io/wcag2ict/#contrast-minimum 14:44:28 q+ 14:44:31 1.4.3 and 1.4.11 need to be consistent 14:44:35 ack bbailey 14:44:43 GreggVan: 1.4.3 and 1.4.11 would have to be the same, whether it's hardware or all software 14:45:07 bbailey: I wonder if we should have a section on how to use WCAG in the context of hardware 14:45:29 loicmn has joined #wcag2ict 14:45:38 present+ 14:45:48 PhilDay: I do see Gregg's point. We give guidance about harwdare and later we say hardware is out of scope 14:46:31 +1 that there is value in keeping these hardware-oriented notes! 14:46:31 q+ 14:46:55 ack loicmn 14:47:02 Daniel: I think these are good to stay, we are acknowledging that these things can happen but we are notproviding guidance for hardware because as you said it's out of scope 14:47:39 q+ 14:47:42 loicmn: Two issues. I think it's good to keep it in to acknowledge that sometimes it won't be possible to meet, and also, whatever we do we should do for 1.4.3 and 1.4.11 14:47:59 +1 that what we do here for 1.4.11 be replicated in 1.4.3 14:48:50 ... Mitch's issue -- ometimes you have a limited number of colors to choose from. Interesting thing, but should probably come in the form of a note and also not only for closed 14:49:12 ... If we're taking it, I'd suggest we put it outside closed 14:49:25 PhilDay: Mitch's proposed new edit is raising a new thing that we hadn't cover before, right? 14:49:34 loicmn: Yes, it's a different issue 14:49:49 s/ometimes/sometimes/ 14:49:55 RRSAgent, draft minutes 14:49:57 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html bbailey 14:50:38 ... My suggestion would be to keep what we have for closed but then if we think this proposal is interesting I would add it as a new note in 1.4.3 and 1.4.11 main sections 14:50:47 ack GreggVan 14:51:32 GreggVan: I don't think either one of these things belong in closed functionality at all. Whether the system limits the colors is not a function of the software being closed, it would apply whether the software is closed or open 14:51:35 s/contrastratio/contrast ratio/ 14:52:07 q? 14:52:16 ... If you are limited in colors you just have to limit your creativity, but you could still do for example black and white 14:52:39 ... AT don't change contrast 14:53:03 ... If you use zoom text in zoom mode you still have the ability to do black and white, which means you can override the author intent and introduce your own 14:53:24 s|^s|| 14:53:27 ... But that doesn't have to do with the author 14:53:44 q+ to say this is an issue with AT 14:54:29 q? 14:55:24 PhilDay: I think the notes 4 and 5 are specific to closed systems 14:55:38 GreggVan: That would be a testing problem 14:55:39 q+ 14:55:48 ack PhilDay 14:55:48 PhilDay, you wanted to say this is an issue with AT 14:55:54 q? 14:56:14 ack bbailey 14:56:31 bbailey: Note 5 about photograph in the screen is a bit older 14:56:39 PhilDay: We've been having them since we wrote this 14:56:48 GreggVan: We should say is problematic for testing 14:58:27 GreggVan: Also flashing would be difficult to test and we are not saying anything about it now 14:58:58 s/Also flashing would be/Flashing would be also/ 14:59:12 PhilDay: We'll need to have a think about it, and solve it next week 14:59:26 ... For now I agree with loicmn that what we have is better 15:00:04 ... We've had similar discussions when something is not clear on whether it affects closed alone or all software 15:00:05 +1 for keeping what we have , and being open to adding something additional 15:00:09 rrsagent, draft minutes 15:00:11 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html Daniel 15:00:26 q+ to mention filed issued 15:00:45 https://github.com/w3c/wcag2ict/issues/956 15:00:46 GreggVan: Two angles: whether or not it's for closed alone or for all software: whether or not it is difficult to test 15:00:48 ack bbailey 15:00:48 bbailey, you wanted to mention filed issued 15:01:08 bbailey: Please make sure about the "non-WCAG requirement" 15:01:13 rrsagent, draft minutes 15:01:14 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html Daniel 15:02:00 loicmn has left #wcag2ict 15:02:06 rrsagent, make minutes 15:02:07 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html PhilDay 15:02:45 s/Dainel/Daniel/ 15:02:46 rrsagent, draft minutes 15:02:47 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html Daniel 15:03:00 zakim, end meeting 15:03:00 As of this point the attendees have been PhilDay, GreggVan, Daniel, loicmn, bbailey 15:03:02 RRSAgent, please draft minutes v2 15:03:04 I have made the request to generate https://www.w3.org/2026/07/02-wcag2ict-minutes.html Zakim 15:03:09 I am happy to have been of service, PhilDay; please remember to excuse RRSAgent. Goodbye 15:03:09 rrsagent, bye 15:03:09 I see 1 open action item saved in https://www.w3.org/2026/07/02-wcag2ict-actions.rdf : 15:03:09 ACTION: Editors to check SC problematic for closed for use of the phrase "other non-WCAG requirements" and substitute with "requirements beyond WCAG's" [1] 15:03:09 recorded in https://www.w3.org/2026/07/02-wcag2ict-irc#T14-33-56 15:03:10 Zakim has left #wcag2ict