12:58:23 RRSAgent has joined #wcag2ict 12:58:27 logging to https://www.w3.org/2024/03/15-wcag2ict-irc 12:58:27 RRSAgent, make logs Public 12:58:28 Meeting: WCAG2ICT Task Force Teleconference 12:58:29 zakim, clear agenda 12:58:29 agenda cleared 12:58:35 chair: Mary Jo Mueller 12:58:48 meeting: WCAG2ICT Task Force Extra Friday Teleconference 12:59:21 PhilDay has joined #wcag2ict 12:59:28 present+ 13:01:49 scribe+ PhilDay 13:02:23 bruce_bailey has joined #wcag2ict 13:02:27 present+ 13:02:32 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-remaining-sc/results#xq3 13:02:35 TOPIC: Survey results from q3 onwards 13:02:57 Topic: SCs Problematic for Closed: 2.4.4 Link Purpose (In Context) 13:03:48 Proposed content: https://github.com/w3c/wcag2ict/issues/274#issuecomment-1976293654 13:04:10 2 said incorporate as is, 1 (Bruce) had concerns over the use of the word "requires" 13:04:32 its not about being incorrect 13:04:50 bruce_bailey: Using requires in 2 ways - 1 about restating/paraphrasing SC, the other is to say what should be done 13:05:50 present+ Daniel 13:05:54 bruce_bailey: We've had questions from people - read "requires" then assume it is a restatement of the SC 13:08:26 PhilDay: Suggest possible change to language "Assumes the use of ..." instead of "Requires..." 13:09:12 PhilDay: Suggestion - Bruce to look through document, create a single issue to summarise where the language should be changed as above, then we go to the full TF to approve the change to language throughout the document. 13:09:32 https://github.com/w3c/wcag2ict/blob/main/success-criteria-problematic-for-closed-functionality.md 13:09:53 https://w3c.github.io/wcag2ict/ is the latest editor's draft. 13:10:28 bruce_bailey: To look through and create single pull request for clearing up the "requires" language within the SC problematic for closed section. 13:11:15 New introductory section to SC problematic for closed: https://w3c.github.io/wcag2ict/#success-criteria-problematic-for-closed-functionality 13:12:36 Edited version of link purpose. New proposal 3 - incorporating changes suggested in survey 2.4.4 Link Purpose (In Context) - Assumes the use of text and context in a programmatically determinable form. 13:13:18 2nd sentence is removed - as it is covered in the intro section 13:13:27 TOPI: SCs Problematic for Closed: 1.4.5 Images of Text 13:13:34 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-remaining-sc/results#xq4 13:13:43 Proposed content: https://docs.google.com/document/d/1fpa7fX2Hdov3lduiJtSzb0EGSflSlxivtKmKGMsMobs/edit#heading=h.v13ly0jz2vqu 13:14:32 Survey results: 2 said option 10 as is, 1 said option 9 with edits (shown as option 11 in the google doc) 13:15:29 Bruce's alternate proposal from survey: High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size) 13:16:19 Option 11: Only state the problem 1.4.5 Images of Text—High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size). Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no interoperability with assistive technology an[CUT] 13:16:23 ... support. 13:20:14 Or option 12: add last sentence from option 9 to option 11. 13:20:43 Option 12: state problem, then suggest work-around - 1.4.5 Images of Text—High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size). ... 13:20:52 ... Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text. Where this is not possible, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like assistive technology, would help meet the intent of this success criterion. 13:21:21 maryjom: Don't need the sentence starting "Where this is not possible", which takes it back to options 9 or 11 13:21:45 Agreement is to take options 9 and 11 to full FT 13:21:50 s/FT/TF 13:22:00 Option 9: Only state the problem 1.4.5 Images of Text—Requires text for high-quality modification of displayed text (e.g. high contrast, increase of font size). Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no interoperability with assistive technology and/or lack of platform support. 13:22:12 Option 11: Only state the problem 1.4.5 Images of Text—High-quality machine-readable text (and not mere images of text) is needed for assistive technology functionality to provide modification of displayed text (e.g. high contrast, increase of font size). Not all ICT with closed functionality has the capability to support visual modification of displayed text or images of text, given there is no interoperability with assistive technology an[CUT] 13:22:14 ... support. 13:22:39 TOPIC: SCs Problematic for Closed: 2.1.1 Keyboard 13:22:49 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-remaining-sc/results#xq5 13:23:03 Proposed content: https://docs.google.com/document/d/13ZzHeccY_0V79OhUFAP2Uw5-JvgkcpHEuForc_MVWjI/edit#heading=h.bof14l3ftnll 13:23:16 Only change proposed was to deal with the requires language. 13:23:49 Redo survey with options 0 and 5, with the changed language "Requires" changed for "Assumes the use of" 13:24:10 Option 0: Current text in editor’s draft 2.1.1 Keyboard—Assumes operation via a keyboard interface which allows alternative input devices. When a product with closed functionality either does not have a standard keyboard or one cannot be connected, it would need an alternate way to access all functionality that does not require accurate pointing, path-based movements, or specific timings. 13:24:25 Option 5: compromise position Assumes operation via a keyboard interface which also allows for alternative input devices. When a product with closed functionality does not have a standard keyboard or an alternative input device cannot be connected, it may not be possible to satisfy this success criterion. It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limite[CUT] 13:25:08 Option 5: compromise position Assumes operation via a keyboard interface which also allows for alternative input devices. When a product with closed functionality does not have a standard keyboard or an alternative input device cannot be connected, it may not be possible to satisfy this success criterion. ... 13:25:16 ... It may be possible to address some user needs (such as offering input methods that support users with low vision, without vision, or limited manual dexterity). 13:26:25 maryjom: Don't think we need any changes to this (apart from Requires language) so will survey the tweaked language 13:26:55 TOPIC: SCs Problematic for Closed: Other SCs that rely on programmatic information 13:27:23 2 responses, both suggested changes 13:27:40 First change was to address "Requires" language, which will already be addressed in Bruce's pull request 13:28:05 Second was a minor editorial to bring consistency between some notes in SC problematic for closed 13:28:42 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-SC-problematic-remaining-sc/results#xq5 13:29:45 1.3.2 Meaningful Sequence — Requires information in a programmatically determinable form. Instead, a closed functionality software equivalent would be to provide a meaningful reading sequence through auditory output or some other non-visual means that helps users correlate the output with the corresponding information displayed on the screen. 13:30:57 1.3.2 Meaningful Sequence — Requires information in a programmatically determinable form. 13:31:14 Intro section from Success Criteria problematic for closed 13:31:16 There are Success Criteria that can be problematic for developers of ICT with closed functionality. Some criteria discuss making information available in text (which can be read by assistive technologies), making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies), or doing something else to make content compatible with assistive technologies. 13:31:23 ... Where ICT with closed functionality doesn't support use of assistive technology or the platform is not sophisticated enough to have an accessibility API, providing equivalent information and operation through another mechanism, such as functions built into the software that behave like assistive technology, would help meet the intent of these success criteria. 13:31:54 https://w3c.github.io/wcag2ict/#success-criteria-problematic-for-closed-functionality 13:35:35 [reading through new introductory section in latest editor's draft above] 13:37:43 https://convergeaccessibility.com/2023/08/03/new-doj-web-accessibility-regulation-is-a-disaster/ 13:39:49 Survey to be sent out again to get more responses 13:40:56 TOPIC: Now working on open issues / comments 13:41:19 First one: Issue 145 - https://github.com/w3c/wcag2ict/issues/145 13:41:46 https://github.com/w3c/wcag2ict/issues/145#issuecomment-1995516434 13:46:34 Need some generic text to add to the 'sets of' SCs that state that "sets of" may not be applied to non-web documents and software by other regulations. 13:49:57 Discussion starter from Bruce: For example, some local standards such as Section 508 in the US, non-Web documents and non-Web software need not comply with WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification 13:50:47 More generally, not all SC will be applicable to all technologies 13:51:13 Not all SCs have been fully adopted in all local regulations and legislation, and may not be applicable to all technologies. For example, some local standards such as Section 508 in the US, non-Web documents and non-Web software need not comply with WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification 13:51:27 This to go on the end of Background section. 13:52:07 Not all SCs have been fully adopted in all local regulations and legislation, and may not be applicable to all technologies. WCAG2ICT was also used to determine whether or not to apply certain SCs. 13:52:16 ... For example, some local standards such as Section 508 in the US, non-Web documents and non-Web software need not comply with WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification 13:54:01 Change to go into: https://github.com/w3c/wcag2ict/blob/main/introduction.md 13:56:58 One idea: Local regulations and guidance may not apply this SC, then refer to background section in document 13:57:14 Add this verbiage to those SCs that need it (e.g. sets of) and refer back to the Background paragraph 14:02:02 Work on rest of issues next Thursday 14:02:21 And review Bruce's pull request on changes to "requires" language as well 14:02:32 rrsagent, draft minutes 14:02:33 I have made the request to generate https://www.w3.org/2024/03/15-wcag2ict-minutes.html PhilDay 14:03:33 zakim, end meeting 14:03:33 As of this point the attendees have been PhilDay, bruce_bailey, Daniel 14:03:34 RRSAgent, please draft minutes v2 14:03:35 I have made the request to generate https://www.w3.org/2024/03/15-wcag2ict-minutes.html Zakim 14:03:40 I am happy to have been of service, maryjom; please remember to excuse RRSAgent. Goodbye 14:03:42 present+ 14:03:42 Zakim has left #wcag2ict 14:03:55 rrsagent, make minutes 14:03:57 I have made the request to generate https://www.w3.org/2024/03/15-wcag2ict-minutes.html maryjom 14:04:17 rrsagent, bye 14:04:17 I see no action items