14:02:08 RRSAgent has joined #wcag2ict 14:02:12 logging to https://www.w3.org/2025/08/28-wcag2ict-irc 14:02:12 RRSAgent, make logs Public 14:02:13 Meeting: WCAG2ICT Task Force Teleconference 14:02:13 zakim, clear agenda 14:02:13 agenda cleared 14:02:18 chair: Mary Jo Mueller 14:02:26 present+ 14:02:26 rrsagent, make minutes 14:02:27 I have made the request to generate https://www.w3.org/2025/08/28-wcag2ict-minutes.html maryjom 14:02:35 scribe+ PhilDay 14:02:42 Zakim, please time speakers at 2 minutes 14:02:42 ok, maryjom 14:02:46 agenda+ Announcements 14:02:51 Hi all, I would scribe but need to trust IRC, it keeps dropping. Thanks for the welcoming! 14:03:03 present+ 14:03:17 agenda+ AG WG comment: 1.4.4 Resize Text 14:03:30 agenda+ TF review of the WCAG2Mobile document 14:03:56 zakim, next item 14:03:56 agendum 1 -- Announcements -- taken up [from maryjom] 14:04:08 https://github.com/w3c/wcag2ict/wiki/Work-for-the-week#28-august 14:04:13 EN v16 draft is out (EN 301 549). Comments due by this Sunday 14:05:24 Woot! 14:05:27 WCAG2ICT was published on 21 Aug. We still have more work to do - but that was good progress 14:05:41 https://www.w3.org/TR/wcag2ict-22/ 14:05:49 Published version - see link 14:05:56 WCAG2ICT overview page: https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/ 14:05:57 Also updated the overview page 14:07:34 GreggVan: new EN draft is out. Do you have a link? 14:07:55 I am happy to see that previous URL works as expected: https://www.w3.org/TR/wcag2ict/ 14:08:56 Don't think it is uploaded - was sent via email. 14:09:03 TF welcome Chris 14:09:44 zakim, next item 14:09:44 agendum 2 -- AG WG comment: 1.4.4 Resize Text -- taken up [from maryjom] 14:10:17 https://github.com/w3c/wcag2ict/issues/772 14:10:25 We did have comments on resize text - didn't block publication, but we still want to review the feedback 14:10:56 Issue 772 took comments from the AG WG general review thread, and also added some proposals for revised langauge 14:11:03 s/langauge/language 14:11:40 Chris_Loiselle has joined #wcag2ict 14:12:08 [Mary Jo sharing screen, currently showing issue https://github.com/w3c/wcag2ict/issues/772] 14:12:41 Introductory language - some concerns were expressed. 14:12:49 Proposal 0: This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Non-web software needs to work with platform capabilities where they exist, but when the platform has text resizing that up to 200%, but not all text types 14:12:49 scale to 200%, it is unreasonable for all apps on a particular platform to be required to build in their own text resizing. A reasonable expectation would be for non-web software to work with the text sizing features to the extent the platform provides. Doing so would still address the user needs identified in the Intent from Understanding Success 14:12:49 Criterion 1.4.4. The following criterion is recommended as a substitute for the WCAG language: 14:13:26 Latest from v16 of EN: 10.1.4.4 Resize text 14:13:26 Where ICT is, or includes, a non-web document, 14:13:26 the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.4.4 Resize text. 14:13:26 NOTE 1: Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with zoom. 14:13:28 NOTE 2: It is best practice to use only fonts that allow for scaling without loss of quality (e.g. pixelized presentation). This applies in particular to embedded fonts. 14:13:28 NOTE 3: Best practice is for the default presentation of text to have an x-height of at least 1.2mm. For a 14 inch screen at 1920 x 1080 screen resolution with no zooming or display scaling, this means the x-height of the text needs to be at least as big as Arial at 16 CSS px. 14:15:30 WCAG2ICT TF - we modified the SC. Looks like the EN committee didn't take this change - probably as they were focusing solely on the latest comments rather than making new technical changes. 14:16:47 The issue (772) concerned the introductory text along with one of the notes 14:17:58 Jon's proposal rewords the penultimate sentence (proposal 2). Gregg's (proposal 1) rewords most of the paragraph. 14:18:19 Gregg also added proposal 3 with further refinements 14:18:34 Proposal 0 - Current language in WCAG2ICT 14:18:34 This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Non-web software needs to work with platform capabilities where they exist, but when the platform has text resizing that up to 200%, but not all text types scale to 200%, 14:18:34 it is unreasonable for all apps on a particular platform to be required to build in their own text resizing. A reasonable expectation would be for non-web software to work with the text sizing features to the extent the platform provides. Doing so would still address the user needs identified in the Intent from Understanding Success Criterion 14:18:34 1.4.4. The following criterion is recommended as a substitute for the WCAG language: 14:18:36 Proposal 1 - from Gregg's comment 14:18:36 Modifies most of the introductory text. 14:18:36 This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Some platforms such as some mobile platforms do not provide built-in utilities to allow scaling of all text to 200% whereas all browsers did when the SC was written. The 14:18:37 task force felt that the intent was to support scaling up to at least 200% by the platform, not to require that all software provide its own scaling function. However, if there is no scaling function in the platform at all then text scaling should be provided to ensure that text is large enough for those with 20/40 vision (the equivalent of 200% of 14:18:37 20/20). Note that this success criterion also has special considerations for ICT with closed functionality. The following criterion is recommended as a substitute for the WCAG language: 14:18:37 Proposal 2 - from Jon's comment 14:18:48 Rewords the second from the last sentence starting with "A reasonable expectation..." 14:18:48 This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Non-web software needs to work with platform capabilities where they exist, but when the platform has text resizing that up to 200%, but not all text types scale to 200%, 14:18:48 it is unreasonable for all apps on a particular platform to be required to build in their own text resizing. A reasonable expectation would be for non-web software, where the platform has text resizing support up to 200%, but where not all text resizes to 200% of it's default due to the resized text already being 200% of the default body text size, 14:18:49 resizes to the extent the platform provides. Doing so would still address the user needs identified in the Intent from Understanding Success Criterion 1.4.4. The following criterion is recommended as a substitute for the WCAG language: 14:18:49 Proposal 3 14:18:49 Here is a variation on that -- that I think covers all the angles including places where no resizing is needed to achieve the same thing as 200% increase over normal sized text. 14:18:49 This success criterion is problematic to apply directly to non-web software when platforms do not provide text enlargement features that increase all displayed text to 200%. For example some mobile platforms do not provide built-in utilities to allow scaling of all text to 200% whereas all browsers did when the SC was written - and the intent when 14:18:49 the original SC was written was to support and not interfere with that (not require software to provide their own). However, if there is no scaling function in the platform at all, then text scaling should be provided to ensure that text is large enough for those with 20/40 vision (the equivalent of 200% of 20/20). Note that this success criterion 14:18:51 also has special considerations for ICT with closed functionality. The following criterion is therefor recommended as a substitute for the WCAG language when applying to non-web software: 14:18:51 Except for captions and images of text one of the following is true 14:18:51 a) text can be resized without loss of content or functionality without assistive technology up to 200 percent using text resizing functionality of the platform or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform. 14:18:52 b) if the non-web software is designed to work on a platform that has no text resizing capabilities, or that functionality is not exposed to the user when using the software, text can be resized without loss of content or functionality without assistive technology up to 200 percent using text resizing functionality of the software 14:19:19 c) software is running on a known hardware platform and all text is already known to be 3/8 of an in or larger in size. 14:20:17 Gregg: This was written way back when - so can comment on that, and talk about the assumptions about 200% in all browsers. We are now talking about non-web content. 14:20:17 If it is all on a kiosk or something and it already has very large text - then there shouldn't be a requirement to also provide additional zoom. 14:20:56 q? 14:21:04 3rd option - if there is no zoom on the platform - then you don't have to do anything (particularly in a closed system that doesn't allow access to any accessibility features). 14:21:36 Gregg: This is complicated; I've tried to cover all possibilities but it is rather complex and is therefore a little longer 14:22:18 +1 to Gregg's proposal 3 14:22:48 maryjom to poll options 14:23:13 POLL: Which proposal do you prefer? 0) Proposal 0 – leave as-is, 1) Proposal 1, 2) Proposal 2, or 3) Proposal 3, or 4) something else 14:23:45 bbailey has joined #wcag2ict 14:23:57 3, but would also accept 2 or 1 14:23:58 3 14:23:59 Per what Gregg shared today, I lean to proposal 3 14:24:16 q+ 14:24:21 ack bbailey 14:24:50 bbailey: Nice to use somebody else's suggestion. Jon's edit was fairly minimal over the previous suggestion which is nice, but Gregg's proposal 3 is more complete. 14:25:51 q+ for another comment 14:25:58 maryjom: Suggested next stage is to put in a PR and allow wider TF to review. 14:27:13 maryjom: Think that we can't get this into the EN at this late stage - only comments that are being accepted are updates to previous work. 14:27:21 I like Gregg's Proposal 3 but it seems to be missing Jon's key addition: where the platform has text resizing support up to 200%, but where not all text resizes to 200% of it's default due to the resized text already being 200% of the default body text size 14:27:30 q? 14:27:58 ack bbailey 14:27:58 bbailey, you wanted to discuss another comment 14:28:23 bbailey: Another argument for using Jon's proposal as it is less change. 14:29:19 maryjom working on tweak to proposal 3 to address bbailey's concern above 14:29:26 For example some mobile platforms provide built-in utilities to allow scaling of some, but not all text to 200%, whereas all browsers did when the SC was written... 14:29:58 For example some mobile platforms provide built-in utilities to allow scaling of some, but not all text to 200%, whereas all browsers did scale all text to 200% when the SC was written... 14:30:24 GreggVan: Agree with the wording - but put it in the exceptions (a-c) 14:32:15 I think all these are just for non-web software and we don't say anything for non-web documents. 14:33:01 maryjom: We didn't pull this one into separate sections for non-web documents vs non-web software 14:35:21 q+ to suggest we could just add or documents in the introductory paragraphs 14:35:49 ack PhilDay 14:35:49 PhilDay, you wanted to suggest we could just add or documents in the introductory paragraphs 14:36:46 Discussion ensued on whether this should also apply to non-web documents. If you embed code in a document, does it become software? 14:36:57 PhilDay: suggest we just add non-web documents or software 14:37:04 This success criterion is problematic to apply directly to non-web documents or software when the user agent or platform does not provide text enlargement features that increase all displayed text to 200%. 14:37:22 +1 to maryjom's modified text 14:38:13 q+ 14:38:39 ack 14:38:41 ack bbailey 14:38:54 bbailey: can we move on and come back to this later in the meeting? 14:39:28 [maryjom adding Google doc to help with editing this introductory text to resize text] 14:39:39 agenda? 14:39:52 Current phrasing seems to miss that SOME text much increase to %200 (or min 3/8). 14:40:37 s/text much increase/text much increase/ 14:40:45 s/text much increase/text must increase/ 14:41:19 rrsagent, draft minutes 14:41:20 I have made the request to generate https://www.w3.org/2025/08/28-wcag2ict-minutes.html bbailey 14:42:07 Google doc: https://docs.google.com/document/d/17Ih8--GfBZEnuiKxIJJ95w4oI3x17ROLw_wuKzxtTws/edit?usp=sharing 14:42:22 q? 14:44:03 Gregg has done a modified version to address Jon's comment 14:45:00 (Replaced proposal 3 with a new edit) 14:45:26 +1 to Proposal 3 (with 4 options) 14:46:02 s/1 to Proposal 3 (with 4 options)/1 to Proposal 3 (with its four options)/ 14:46:10 Gregg's latest edit (taken from google doc): 14:46:10 Proposal 3 - From Gregg’s comment in the new issue 14:46:10 Here is a variation on that -- that I think covers all the angles including places where no resizing is needed to achieve the same thing as 200% increase over normal sized text. 14:46:10 This success criterion is problematic to apply directly to non-web documents or software when the user agent or platform does not provide text enlargement features that increase all displayed text to 200%. For example some mobile platforms do not provide built-in utilities to allow scaling of all text to 200% whereas all browsers did when the SC 14:46:12 was written - and the intent when the original SC was written was to support and not interfere with that (not require software to provide their own). However, if there is no scaling function in the platform at all, then text scaling should be provided to ensure that text is large enough for those with 20/40 vision (the equivalent of 200% of 20/20). 14:46:12 Note that this success criterion also has special considerations for ICT with closed functionality. The following criterion is therefore recommended as a substitute for the WCAG language when applying to non-web software: 14:46:12 Except for captions and images of text one of the following is true 14:46:13 a) text can be resized without loss of content or functionality without assistive technology up to 200 percent using text resizing functionality of the platform or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform, or 14:46:13 b) if the non-web software is designed to work on a platform that has no text resizing capabilities, or that functionality is not exposed to the user when using the software, text can be resized without loss of content or functionality without assistive technology up to 200 percent using text resizing functionality of the software, or 14:46:19 c) the platform has text resizing support that enlarges all text is up to 200% of the size of the default body text or larger and that feature is supported, or 14:46:19 d) software is running on a known hardware platform and all text is already known to be 3/8 of an in or larger in size. 14:46:56 q+ 14:47:06 ack bbailey 14:48:46 q+ 14:49:17 q? 14:50:37 ack Chris_Loiselle 14:51:19 Chris_Loiselle: Gregg's point - the OS on mobile - should be held responsible for meeting this. We don't have to provide an exception. What we are writing here makes sense. 14:51:51 ... Don't want to give an exception along the lines of "if you OS doesn't support it, then you are OK..." 14:52:20 maryjom: How do we cover the fact that mobile apps don't have to provide additional zoom in addition to the platform 14:53:39 Discussion about pinch-zoom in mobile. Is pinch-zoom AT? This requirement is without AT. 14:54:05 q+ 14:54:25 GreggVan: AT is not all the accessible features of the platform 14:55:01 ack Chris_Loiselle 14:55:03 ack Chris_Loiselle 14:55:29 Chris_Loiselle: Remember we discussed accessibility features vs AT. Pinch zoom is a feature, not AT. 14:55:51 What Jon was mentioning was lived experience of what could be considered as AT. 14:56:50 The other topic was possible adjustments to notes 14:57:09 Notes 3 & 4 became similar 14:57:10 2. Possible adjustments to the notes 14:57:10 Jon expressed concern about the notes, but we had made some adjustments so it's difficult to tell what might need changing. We currently have 2 notes that are similar to what he commented on - Notes 3 and 4 14:57:10 Note 3 (Added) (for non-web software) 14:57:10 The Intent section in Understanding 1.4.4 Resize Text refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the non-web software provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality, or that the 14:57:12 non-web software works with the platform features to satisfy this success criterion. 14:57:12 Note 4 (Added) (for non-web software) 14:57:12 For non-web software, sometimes the platform provides text scaling to 200% for most, but not all text (e.g. headings, which are naturally large, may not be increased in size to 200%, but other text does increase to 200%). In such cases, authors would only need to support text scaling to the extent provided by user settings in the platform, without 14:57:13 losing content or functionality, to satisfy this success criterion. 14:58:54 Gregg: references sufficient test for resize text - which says that zoom features pass 14:59:09 s/sufficient test/sufficient techniques 14:59:13 ... from understanding document 14:59:41 browsers allow you to zoom - analogous to mobile apps allow you to zoom 15:00:51 rrsagent, draft minutes 15:00:52 I have made the request to generate https://www.w3.org/2025/08/28-wcag2ict-minutes.html PhilDay 15:01:38 q+ 15:02:07 bye 15:04:08 if someone was to remove ability to zoom (pinch to zoom) then that would fail. I believe around 2017 iOS and Android changed user scalable restrictions 15:04:37 zakim, end meeting 15:04:37 As of this point the attendees have been PhilDay, bbailey 15:04:38 RRSAgent, please draft minutes v2 15:04:39 I have made the request to generate https://www.w3.org/2025/08/28-wcag2ict-minutes.html Zakim 15:04:45 I am happy to have been of service, maryjom; please remember to excuse RRSAgent. Goodbye 15:04:47 Zakim has left #wcag2ict 15:05:02 present+ maryjom, Chris_Loiselle, GreggVan 15:05:10 rrsagent, make minutes 15:05:11 I have made the request to generate https://www.w3.org/2025/08/28-wcag2ict-minutes.html maryjom 15:05:31 Here's a good article and reference point https://www.deque.com/blog/accessibility-mobile-web-pinch-zoom-tutorial/