13:58:18 RRSAgent has joined #wcag2ict 13:58:23 logging to https://www.w3.org/2026/04/02-wcag2ict-irc 13:58:23 RRSAgent, make logs Public 13:58:24 Meeting: WCAG2ICT Task Force Teleconference 13:58:29 zakim, clear agenda 13:58:29 agenda cleared 13:58:29 chair: PhilDay 13:58:29 meeting: WCAG2ICT Task Force Teleconference 13:58:46 rrsagent, make minutes 13:58:48 I have made the request to generate https://www.w3.org/2026/04/02-wcag2ict-minutes.html PhilDay 13:59:08 GreggVan has joined #wcag2ict 13:59:15 zakim, please time speakers at 2 minutes 13:59:15 ok, PhilDay 13:59:15 agenda+ Announcements 13:59:15 agenda+ 2.1.3 Keyboard (No Exception) 13:59:15 agenda+ 2.2.3 No Timing 13:59:16 agenda+ 2.2.4 Interruptions 13:59:16 agenda+ 2.2.5 Re-authenticating 13:59:20 agenda? 13:59:54 bbailey has joined #wcag2ict 14:00:05 rrsagent, make minutes 14:00:06 I have made the request to generate https://www.w3.org/2026/04/02-wcag2ict-minutes.html PhilDay 14:00:24 Laura has joined #wcag2ict 14:01:02 present+ 14:01:04 regrets: Loïc Martínez Normand 14:01:25 present+ 14:01:32 scribe+ LauraM 14:01:40 scribe+ Laur 14:01:46 scribe+ Laura 14:02:05 present+ 14:02:30 zakim, take up item 1 14:02:30 agendum 1 -- Announcements -- taken up [from PhilDay] 14:02:35 Reminder – there will be no meeting next week (9th April) but we will be meeting on the 16th April 2026. 14:03:11 present+ 14:04:45 Survey: information in-line or links out to separate content? 14:04:45 https://www.w3.org/wbs/55145/AAA-213-to-225/results/#xq99 14:04:46 present+ Daniel 14:05:32 Survey link: https://www.w3.org/wbs/55145/AAA-213-to-225/ 14:05:54 GreggVan: I prefer both the information in-line and links out. 14:07:00 zakim, take up next 14:07:00 agendum 2 -- 2.1.3 Keyboard (No Exception) -- taken up [from PhilDay] 14:07:08 Link to issue: https://github.com/w3c/wcag2ict/issues/543 14:07:30 Applying SC 2.1.3 Keyboard (No Exception) to non-web documents and non-web software 14:07:30 This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.3. 14:07:30 NOTE 14:07:30 Keyboard interface does not refer to a physical device but to the service of platform software (e.g. operating system, browser, etc.) that provides the software with keystrokes from any keyboard or keyboard substitute. When the non-web software supports such a device-independent service of the platform software, and the non-web software 14:07:32 functionality is made fully operable through the service, then this success criterion would be satisfied. 14:07:32 NOTE 14:07:32 A "device-independent keyboard interface service" refers to the platform service that provides keystrokes to any software running on the platform. 14:07:33 NOTE 14:07:33 Inclusion of an on-screen keyboard can be done as well but does not satisfy this requirement since it does not allow for the use of keyboard alternatives whereas support of input from the device-independent keyboard interface service does. 14:07:33 NOTE 14:07:34 This success criterion does not imply that non-web software always needs to directly support a keyboard or “keyboard interface” if one is not provided by the platform software. But if one is provided, the software needs to make all functionality available through it - unless the exception applies. 14:07:34 NOTE 14:07:34 This success criterion also does not imply that non-web software always needs to provide its own virtual keyboard. But if it does, then the non-web software still needs to support keyboard input from any keyboard interface provided by the platform software. 14:07:35 NOTE 14:07:35 See also the Comments on Closed Functionality. 14:07:35 And proposed content for SC problematic for closed functionality (again, derived from 2.1.1): 14:07:39 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 functionality. 14:07:39 NOTE 14:07:39 A keypad that provides full access to functionality might be considered a keyboard. 14:07:39 Link to results for this question: https://www.w3.org/wbs/55145/AAA-213-to-225/results/#xq4 14:08:16 Loic's comment from survey: I suggest that we use the already existing approach for 2.1.1 Keyboard (https://www.w3.org/TR/wcag2ict-22/#keyboard). In that approach we split the success criterion into two sections: (a) non-web documents, where it is "as-is", (b) non-web software, where we have a precondition "Where ICT is or includes non-web software 14:08:16 that can be run on a software platform that provides a device-independent keyboard interface service". Then we have specific notes for non-web software, providing detailed information. 14:08:16 I don't see any reason why not to apply the same thinking to 2.1.3. 14:09:24 PhilDay: Do we agree with Loic, keep it as is, or suggest something else. 14:09:45 +1 to Loic proposal 14:10:33 Gregg: +1 to Loic 14:10:39 Sam: +1 to Loic 14:10:54 Sam present+ 14:10:59 Sam: present+ 14:12:29 https://w3c.github.io/wcag2ict/#applying-guideline-2-1-keyboard-accessible-to-non-web-documents-and-software 14:12:50 Gregg: Should have a note that if there is active scripting in the document, it should be software 14:13:15 bbailey: If we are making changes to this, we probably need to also change the note. 14:13:33 https://w3c.github.io/wcag2ict/#keyboard 14:13:44 PhilDay: Next are the comments on Closed Functionality 14:13:51 SC problematic: 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 functionality. 14:13:51 NOTE 14:13:51 A keypad that provides full access to functionality might be considered a keyboard. 14:14:36 DRAFT RESOLUTION: For 2.1.3 Keyboard (No Exception), incorporate proposal into the editor’s draft, with edits shown in the meeting minutes (split up documents and software) above 14:14:59 +1 14:14:59 +1 14:15:01 +1 14:15:03 +1 14:15:06 Sam: +1 14:15:08 Sam +1 14:15:13 +1 14:15:21 RESOLUTION: For 2.1.3 Keyboard (No Exception), incorporate proposal into the editor’s draft, with edits shown in the meeting minutes (split up documents and software) above 14:15:43 zakim, take up next 14:15:43 agendum 3 -- 2.2.3 No Timing -- taken up [from PhilDay] 14:15:45 s/Sam +1// 14:15:49 Link to issue: https://github.com/w3c/wcag2ict/issues/544 14:16:10 Applying SC 2.2.3 No Timing to non-web documents and non-web software 14:16:10 This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.3. 14:16:19 Link to results for this question: https://www.w3.org/wbs/55145/AAA-213-to-225/results/#xq5 14:17:00 DRAFT RESOLUTION: For 2.2.3 No Timing, incorporate proposal into the editor’s draft, as-is 14:17:05 +1 14:17:09 +1 14:17:10 +1 14:17:12 +1 14:17:13 +1 14:17:17 Sam +1 14:17:20 SAM +1 14:17:29 RESOLUTION: For 2.2.3 No Timing, incorporate proposal into the editor’s draft, as-is 14:17:43 zakim, next item 14:17:43 agendum 4 -- 2.2.4 Interruptions -- taken up [from PhilDay] 14:17:49 Link to issue: https://github.com/w3c/wcag2ict/issues/545 14:17:59 Applying SC 2.2.4 Interruptions to non-web documents and non-web software 14:17:59 This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.4. 14:18:07 Link to results for this question: https://www.w3.org/wbs/55145/AAA-213-to-225/results/#xsc224 14:18:12 +1 14:18:33 Glad to see some SC where we dodn't need to split into non-web documents and non-web software! 14:18:36 DRAFT RESOLUTION: For 2.2.4 Interruptions, incorporate proposal into the editor’s draft, as-is 14:18:46 +1 14:18:46 +1 14:18:52 +1 14:18:53 SAM +1 14:18:56 +1 14:19:05 +1 14:19:06 RESOLUTION: For 2.2.4 Interruptions, incorporate proposal into the editor’s draft, as-is 14:19:24 zakim, next item 14:19:24 agendum 5 -- 2.2.5 Re-authenticating -- taken up [from PhilDay] 14:19:38 Link to issue: https://github.com/w3c/wcag2ict/issues/546 14:19:51 Applying SC 2.2.5 Re-authenticating to non-web documents and non-web software 14:19:51 This applies directly as written, and as described in Intent from Understanding Success Criterion 2.2.5. 14:19:51 NOTE 14:19:51 See also the Comments on Closed Functionality. 14:19:52 And the proposed content for SC problematic for closed: 14:19:52 2.2.5 Re-authenticating (Level AAA) — ICT with closed functionality may offer more limitations on how much data can be kept between sessions. This is particularly true of systems that are designed to be used in public environments. 14:19:59 Link to results for this question: https://www.w3.org/wbs/55145/AAA-213-to-225/results/#xsc225 14:21:36 DRAFT RESOLUTION: For 2.2.5 Re-authenticating, incorporate proposal into the editor’s draft, as-is 14:21:39 +1 14:21:48 +1 14:21:49 +1 14:21:51 +1 14:21:51 SAM +1 14:21:54 +1 counting Phil's addition 14:22:12 RESOLUTION: For 2.2.5 Re-authenticating, incorporate proposal into the editor’s draft, as-is 14:23:10 TOPIC: 1.2.6 Sign Language (Prerecorded) (Level AAA) 14:23:14 https://github.com/w3c/wcag2ict/issues/532 14:23:43 Latest proposal 14:23:44 Applying SC 1.2.6 Sign Language (Prerecorded) to non-web documents and non-web software 14:23:44 This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6. 14:23:44 NOTE 14:23:44 To date, meeting this success criteria has proven to be challenging, as it is logistically impossible for all existing sign language interpreters to handle all content. Emerging technologies may, in the future, allow translation from text or speech to sign language directly. At that time, those who need sign language could use such an automated 14:23:46 translation tool in the same way people who are blind use a screen reader. This would give people who need to have audio content presented in sign language the same ability to access to this content that people who are blind have access to by using their screen readers. 14:23:46 As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the signing community. In the meantime, providing sign language interpretation continues to be a need for native sign language users, especially in the context of any public service content. 14:23:52 Direct link: https://github.com/w3c/wcag2ict/issues/532#issuecomment-4177814387 14:26:03 q+ 14:26:05 q+ 14:26:28 ack bbailey 14:26:37 GreggVan: to say that it's impossible for sign language to handle the content is really that they couldn't handle the volume so should say that. 14:26:55 bbailey: not clear that we are talking about human sign language interpreters 14:27:00 bbailey: I don't think it's clear that we are talking about human intepretters. 14:27:17 GreggVan: Should we add the word human? I've added the word "human" 14:27:43 q? 14:27:49 ack Daniel 14:27:58 seems a little hyperbolic 14:29:06 GreggVan: The volume of content generated is enormous. 14:29:17 q+ 14:29:22 q? 14:29:32 ack bbailey 14:29:58 bbailey: I'm uncomfortable with where this is going because it says that it will slow down the production cycle. 14:30:05 ack Sam 14:30:16 q+ 14:30:35 Alternative proposal: To date, meeting this success criteria has proven to be challenging, as it is logistically impossible for all existing human sign language interpreters to handle the volume of content that could be generated. 14:30:40 Sam: I agree with the sentiment, but not sure if we can avoid the day/year reference as it is at the moment or on demand. 14:31:08 q? 14:31:12 ack GreggVan 14:32:11 GreggVan: it's out of scale. It's not that it is just going too fast. Not just anyone can do sign language. 14:32:16 q? 14:33:17 q? 14:34:39 Proposed: To date, meeting this success criteria has proven to be challenging, as there are not enough human sign language interpreters available to handle the volume of video content. 14:35:20 q+ 14:35:28 ack Daniel 14:35:38 Daniel: This phrase is saying what we are saying. 14:35:45 Gregg edit: To date, meeting this success criteria has proven to be challenging, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content. 14:35:59 Proposed: To date, meeting this success criteria has proven to be challenging, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content. 14:37:08 Latest proposed text with Bruce & Gregg's suggestions: 14:37:08 Applying SC 1.2.6 Sign Language (Prerecorded) to non-web documents and non-web software 14:37:08 This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6. 14:37:08 NOTE 14:37:10 To date, meeting this success criteria has proven to be challenging, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content. Emerging technologies may, in the future, allow translation from text or speech to sign language directly. At that time, those who need sign language could use 14:37:10 such an automated translation tool in the same way people who are blind use a screen reader. This would give people who need to have audio content presented in sign language the same ability to access this content that people who are blind have access to by using their screen readers. 14:37:10 As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the signing community. In the meantime, providing sign language interpretation continues to be a need for native sign language users, especially in the context of any public service content. 14:37:15 Proposed: As compared to captioning and audio description, sign language interpretation is a very specialized skill. 14:37:48 PhilDay: we are just talking about the first sentence of the note. 14:38:13 GreggVan: "volume being generated"? Otherwise it sounds like "all of history" 14:38:53 Proposed: To date, meeting this success criteria has proven to be infeasible, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content being produced. As compared to captioning and audio description, sign language interpretation is a very specialized skill. 14:39:05 To date, meeting this success criteria has proven to be logistically impossible, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content being generated. 14:40:14 Full text: Applying SC 1.2.6 Sign Language (Prerecorded) to non-web documents and non-web software 14:40:14 This applies directly as written, and as described in Intent from Understanding Success Criterion 1.2.6. 14:40:14 NOTE 14:40:14 To date, meeting this success criteria has proven to be infeasible, as there are not enough human sign language interpreters available to handle a fraction of the volume of video content being produced. As compared to captioning and audio description, sign language interpretation is a very specialized skill. Emerging technologies may, in the 14:40:16 future, allow translation from text or speech to sign language directly. At that time, those who need sign language could use such an automated translation tool in the same way people who are blind use a screen reader. This would give people who need to have audio content presented in sign language the same ability to access this content that 14:40:16 people who are blind have access to by using their screen readers. 14:40:16 As always, authors should not rely on such solutions until they are commonly available at a quality accepted by the signing community. In the meantime, providing sign language interpretation continues to be a need for native sign language users, especially in the context of any public service content. 14:41:31 GreggVan: Could say "specialized skills for another language". People don't realize that signing is another language. 14:41:55 DRAFT RESOLUTION: For 1.2.6 Sign Language (Prerecorded), incorporate proposal into the editor's draft, with edits shown in the meeting minutes above 14:42:03 +1 14:42:40 +1 14:42:42 +1 14:42:51 +1 14:42:52 +1 14:42:53 SAM +1 14:43:20 RESOLUTION: For 1.2.6 Sign Language (Prerecorded), incorporate proposal into the editor's draft, with edits shown in the meeting minutes above 14:43:33 rrsagent, draft minutes 14:43:34 I have made the request to generate https://www.w3.org/2026/04/02-wcag2ict-minutes.html Daniel 14:44:03 PhilDay: we can work on the introduction now. 14:44:04 rrsagent, draft minutes 14:44:05 I have made the request to generate https://www.w3.org/2026/04/02-wcag2ict-minutes.html bbailey 14:44:41 TOPIC: introductory text for AAA 14:44:49 Editor's draft: https://w3c.github.io/wcag2ict/ 14:44:52 q+ 14:45:03 ack bbailey 14:45:18 bbailey: at the end of the last call I made work for Daniel. 14:45:28 Daniel: IDs for closed functionality? 14:45:30 bbailey: Yes 14:45:41 Section that may need some work to introduce level AAA: https://w3c.github.io/wcag2ict/#comments-on-level-aaa-success-criteria 14:47:06 bbailey: my recollection, we went to more simple phrasing. We merged it? Introduction for AAA. 14:47:22 PhilDay: Issue 811. Yes, we have done this and merged it into the draft. 14:47:44 PhilDay: Guidance for Level AAA, we list SCs in Editors note. 14:48:28 EDITOR'S NOTE 14:48:28 This is where we could add a note with the overarching caveats regarding Level AAA criteria and the application of these SC to non-web documents and non-web software. Here is the info in WCAG 2.2 regarding Level AAA conformance. We will need to have some proposals for what content would actually be included in here. 14:48:28 From the WCAG 2 Layers of Guidance section of WCAG 2.2: 14:48:28 Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, Making Content Usable for 14:48:30 People with Cognitive and Learning Disabilities, as well as to seek relevant advice about current best practice to ensure that web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs. 14:48:30 From the Conformance level section of WCAG 2.2: 14:48:30 NOTE 1 14:48:31 It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content. 14:49:20 Proposal for editor's note 14:49:25 GreggVan: It should say "these apply as written". 14:49:28 Replace "This is where we could add a note..." 14:50:44 "These 2 following quotes apply as written to non-web documents and non-web software." then the 2 notes (from guidance and conformance). 14:52:06 Draft resolution: Repleace the folowing placeholder text "This is where we could add a note with the overarching caveats regarding Level AAA criteria and the application of these SC to non-web documents and non-web software. Here is the info in WCAG 2.2 regarding Level AAA conformance. We will need to have some proposals for what content would actually be included in here. 14:52:15 DRAFT RESOLUTION: Replace placeholder text in editor's note with edits as above 14:52:40 q+ for minor quibble 14:52:41 with 'These two notes apply as writen to non-web softward and non-web documents 14:52:57 s/softward/software 14:53:07 s/writen/written 14:53:17 ACTION PhilDay to create draft PR, then add all meeting attendees as reviewers for the draft PR 14:53:59 Daniel: Suggests tweaking the wording so we use something other than "apply as written" as this is used for SCs 14:54:04 q? 14:54:26 ack bbailey 14:54:26 bbailey, you wanted to discuss minor quibble 14:54:26 ack bbailey 14:54:51 bbailey: I'd like to see what the PR looks like. We may not need the editors note, and may just need the paragraph above and the excerpts. 14:54:59 bbailey: want to see the PR - we may not need the editor's note - just have an introductory sentence 14:55:18 ... Also from note 1 of the conformance level of WCAG 2.2 (then lose the nested NOTE 1) 14:55:35 rrsagent, draft minutes 14:55:36 I have made the request to generate https://www.w3.org/2026/04/02-wcag2ict-minutes.html bbailey 14:58:10 PhilDay to discuss with AG WG chairs the approach for reviewing the first few level AAA SCs 14:58:20 q? 14:58:48 rrsagent, draft minutes 14:58:49 I have made the request to generate https://www.w3.org/2026/04/02-wcag2ict-minutes.html Laura 14:58:55 s/Repleace/Replace/ 14:59:31 rrsagent, make minutes 14:59:33 I have made the request to generate https://www.w3.org/2026/04/02-wcag2ict-minutes.html PhilDay 14:59:47 zakim, end meeting 14:59:47 As of this point the attendees have been bbailey, Laura, PhilDay, GreggVan, Daniel 14:59:52 RRSAgent, please draft minutes v2 14:59:53 I have made the request to generate https://www.w3.org/2026/04/02-wcag2ict-minutes.html Zakim 14:59:58 I am happy to have been of service, PhilDay; please remember to excuse RRSAgent. Goodbye 14:59:59 Zakim has left #wcag2ict 15:00:21 rrsagent, bye 15:00:21 I see no action items