13:04:39 RRSAgent has joined #wcag2ict 13:04:43 logging to https://www.w3.org/2024/04/26-wcag2ict-irc 13:04:43 RRSAgent, make logs Public 13:04:44 Meeting: WCAG2ICT Task Force Teleconference 13:04:46 zakim, clear agenda 13:04:46 agenda cleared 13:04:52 chair: Mary Jo Mueller 13:05:08 meeting: WCAG2ICT Task Force Extra Friday Teleconference 13:05:26 scribe+ PhilDay 13:06:00 TOPIC: Issue 4 - 1.4.4 Resize Text 13:06:04 https://github.com/w3c/wcag2ict/issues/4 13:06:16 Google doc link: https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit 13:06:30 Discussion: https://github.com/w3c/wcag2ict/discussions/220 13:08:59 AG WG have been working on resize text, but no substantive input to share yet 13:09:10 https://github.com/w3c/wcag2ict/issues/4 13:09:19 Google doc link: https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit 13:09:28 Discussion: https://github.com/w3c/wcag2ict/discussions/220 13:10:02 mitch11 has joined #wcag2ict 13:10:14 present+ 13:10:16 present+ 13:10:18 present+ 13:10:58 bruce_bailey: (On AG WG calls on resize text). Most discussion has been around reflow. 13:11:43 ... what passes reflow, and does not 13:11:57 s/does not/what does not/ 13:14:37 Applying SC 1.4.4, content from latest editor's draft: https://w3c.github.io/wcag2ict/#applying-sc-1-4-4-resize-text-to-non-web-documents-and-software 13:15:49 Starting at point 3 13:16:12 Point 3: SC 1.4.4 should require scaling in native apps to the extent supported by user settings of the platform. 13:18:29 q+ 13:19:01 +1 to best practice at the very least 13:19:25 mitch11: Perplexed on this between understanding that suggests 200% always, or common sense that should include some pragmatism 13:19:31 For non-web software, there may be cases where the platform does not scale all content up to 200%, as WCAG is limited to web content. In such cases, scaling content to the extent supported by user settings in the platform is considered a best practice. 13:19:37 Chuck: suggested a modification 13:21:19 q+ 13:21:23 ack Ch 13:21:36 ack br 13:21:43 What is in current editor's draft guidance: https://w3c.github.io/wcag2ict/#applying-sc-1-4-4-resize-text-to-non-web-documents-and-software 13:22:01 bruce_bailey: Likes Chuck's statement, but strengthen best practice. "is the way to meet the intent of this success criteria" 13:22:04 For non-web software, there may be cases where the platform does not scale all content up to 200%, as WCAG is limited to web content. In such cases, scaling content to the extent supported by user settings in the platform is the best approach to meet this success criterion. 13:22:46 For non-web software, there may be cases where the platform does not scale all content up to 200%, as WCAG is limited to web content. In such cases, scaling content to the extent supported by user settings in the platform is the best approach to meet the intent of this success criterion. 13:26:58 bruce_bailey: Suggest we include this in the document as it is a helpful note 13:27:38 Agreement: take option 2 on Point 3 to task force 13:27:53 Point 4: We should allow the largest text to enlarge to less than 200%. 13:28:42 +1 but the doc might not be so explicit 13:29:07 q+ 13:30:21 Gregg response: https://github.com/w3c/wcag2ict/discussions/220#discussioncomment-7452379 13:33:04 ack Ch 13:33:24 mitch11: agrees that closed functionality suggestions from Gregg may be helpful for open systems as well - as a best practice 13:33:49 Chuck: Worried that we might be diminishing 200% 13:33:53 ... in this case 13:34:25 ... would rather have a direction that says "this is a sufficient approach to meet the 200% requirement" rather than "it's OK to not meet 200%" 13:34:29 +1 13:35:03 ... you have big text, ... this is a sufficient alternative to meet the intent of this success criterion. 13:35:05 context is large headings not scaling 200% 13:37:10 PhilDay has joined #wcag2ict 13:37:13 present+ 13:37:17 scribe+ PhilDay 13:37:48 mitch11: Would rather have a note on this question in the broader SC, not just in closed section 13:38:16 mitch11: Let's start with the issue response, then look at what needs to go back into the doc 13:38:42 https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit#heading=h.27dltro513c5 13:45:05 Latest iteration: Where a platform does not support text enlargement up to 200%, non-web software content that has large text (such as content that, in its native size, the height of letter h is greater than 0.25 inches (6.35 millimeters)), would address the user need behind this success criterion. 13:46:46 mitch11: could also include the concept of 200% 'body' text or 'normal' text when you cannot always measure the physical size 13:48:26 mitch11: low vision group may have already written a similar statement 13:50:07 We could combine Points 4 and 5 together 13:50:14 Point 5: We should allow most or all text to enlarge to less than 200%, when the text is initially not particularly small 13:52:54 Proposal: take option 1 back to task force to address points 4 & 5 13:53:04 Option 1: Potential response 13:53:04 Where a platform does not support text enlargement up to 200%, non-web software content that has large text (such as content that, in its native size, the height of letter h is greater than 0.25 inches (6.35 millimeters)) would address the user need behind this success criterion. 13:53:04 Where a non-web software does not allow measurement of physical size, the non-web software should support scaling of 200% above a typical platform default size for body text, and anything smaller than body text. 13:53:17 May need survey to refine the content 13:53:53 Point 6: We've long held that PC magnifier programs are assistive technology and therefore not a method of meeting 1.4.4. Is the same true on other platforms? 13:56:12 Assertion came from the understanding text. 13:56:27 Understanding 1.4.4: “The intent of this Success Criterion is to ensure that visually rendered text, including text-based controls (text characters that have been displayed so that they can be seen [vs. text characters that are still in data form such as ASCII]) can be scaled successfully so that it can be read directly by people with mild visual 13:56:27 disabilities, without requiring the use of assistive technology such as a screen magnifier.” 13:59:51 PhilDay: Understanding might refer to the need for adding 3rd party accessibility technology. We could differentiate 3rd party and built in (platform or application) features that enhance accessibility such as platform features for zoom 14:03:05 Mitch to work on further refinements on Point 6 14:03:13 We can then survey the TF 14:03:22 Point 7 (new, not yet mentioned in issue 4): How can 1.4.4 apply to content with no clearly defined default font size? 14:04:46 This will be raised as an issue on WCAG3 14:06:43 rrsagent, draft minutes 14:06:44 I have made the request to generate https://www.w3.org/2024/04/26-wcag2ict-minutes.html PhilDay 14:11:19 zakim, end meeting 14:11:19 As of this point the attendees have been maryjom, mitch, PhilDay 14:11:20 RRSAgent, please draft minutes v2 14:11:21 I have made the request to generate https://www.w3.org/2024/04/26-wcag2ict-minutes.html Zakim 14:11:27 I am happy to have been of service, maryjom; please remember to excuse RRSAgent. Goodbye 14:11:29 Zakim has left #wcag2ict 14:11:38 present+ Bruce 14:11:50 present+ Chuck 14:12:00 rrsagent, make minutes 14:12:02 I have made the request to generate https://www.w3.org/2024/04/26-wcag2ict-minutes.html maryjom 14:14:51 rrsagent, bye 14:14:51 I see no action items