13:00:46 RRSAgent has joined #wcag2ict 13:00:50 logging to https://www.w3.org/2024/05/09-wcag2ict-irc 13:00:50 RRSAgent, make logs Public 13:00:51 Meeting: WCAG2ICT Task Force Teleconference 13:00:51 Chuck has joined #wcag2ict 13:00:51 zakim, clear agenda 13:00:51 agenda cleared 13:00:54 present+ 13:00:55 chair: Mary Jo Mueller 13:00:56 olivia has joined #wcag2ict 13:01:03 Zakim, please time speakers at 2 minutes 13:01:03 ok, maryjom 13:01:37 present+ 13:02:40 Regrets: Loïc, Shawn Thompson, Devanshu, Bryan Trogdon 13:03:05 LauraMiller has joined #WCAG2ICT 13:03:12 present+ 13:03:16 present+ 13:03:16 scribe: bruce_bailey 13:04:03 maryjom: Welcome folks to first of our earlier meeting times. 13:04:12 Agenda+ Announcements 13:04:24 Agenda+ Survey results: Issue 4 13:04:58 Agenda+ Survey results: Follow-up survey addressing public comments, SOTD 13:05:49 Maryjo: We don't quite have agenda, so may run like a Friday call. 13:05:55 zakim, take up item 1 13:05:55 agendum 1 -- Announcements -- taken up [from maryjom] 13:06:06 q+ to mention HHS reg 13:06:12 present+ Daniel 13:06:16 scribe+ 13:06:18 bruce: see https://federalregister.gov/d/2024-09237 13:06:36 ... updates 504, references 2.1 not 2.2 13:06:38 mitch11 has joined #wcag2ict 13:07:17 Maryjo: Friday meetings will continue. Thanks to Phil for pointing out update on issues and with creating PRs.... 13:07:27 present+ 13:07:33 ... be on the lookout for survey. Bruce also has a PR in queue. 13:08:14 maryjom: We will continue plugging through content. Also look for 4.1.1 update soon... 13:08:19 q+ 13:08:31 ack bruce_bailey 13:08:31 bruce_bailey, you wanted to mention HHS reg 13:09:21 ... Any changes we make for 1.4.1 resize text next need a little more editing 13:09:45 LauraMiller: HHS rule also address kiosks, medical devices, and mobile. 13:10:02 ... of coures, WCAG does not work well for hardward. 13:10:13 Bruce: This is a rule. 13:10:42 ...was out for public comment months and months ago. 13:11:02 q? 13:11:16 LauraMiller: Was about when USAB SSTM ANPRM came out. 13:11:39 ack mitch 13:11:39 LauraMiller: There was an announment last week with PDF version. 13:11:50 https://public-inspection.federalregister.gov/2024-09237.pdf 13:12:44 mitch11: WRT surveys, we have gotten used to very granular. I know I would prefers fewer questions when most of survey is editorial. 13:13:12 q+ 13:13:13 ... to clarity, i would prefer reserving surveys for technical issues. 13:13:55 maryjom: Survey are better for multiple options. PR is not a good mechnism for offering choices. 13:14:37 q? 13:14:38 @Maryjom this is the link to the comments made: https://www.federalregister.gov/documents/2023/09/14/2023-19149/discrimination-on-the-basis-of-disability-in-health-and-human-service-programs-or-activities 13:14:44 ... PRs which are purely editiorial, editors will go forward with those. The surveys are better when editors needed to decide between two or more phrasings. 13:14:58 ack Ch 13:15:26 maryjom: We have enough people here early, thank you, that will proceed as usual. 13:15:33 zakim, next item 13:15:33 agendum 2 -- Survey results: Issue 4 -- taken up [from maryjom] 13:15:50 Link to survey: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-issue-4-resize-text/results 13:16:02 TOPIC: Question (1 of 4) Point 3: SC 1.4.4 should require scaling to the extent supported by user settings of the platform 13:16:07 maryjom: The Issure 4 survey, see link, and I will set topics. 13:16:24 Link to results for question 1: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-issue-4-resize-text/results#xq1 13:16:52 maryjom: A good bit to dig through here, we will work from Google doc. 13:16:59 Google doc: https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit#heading=h.igild5wl866t 13:17:29 ... I will provide links to correct heading in doc for each topic. 13:17:33 s/Issure/Issue/ 13:17:33 Point 3 in google doc: https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit#heading=h.870l3jrwy1r8 13:18:33 Survey result spit, 3 as-is and 3 with edit (and one comment in "something else" camp. 13:18:47 Phil, Chris, Bruce -- okay as is. 13:19:02 Sam's proposal 3 link: https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit#heading=h.1adymqnut094 13:20:10 Sam proposed an option 3, loic endsored Sam's proposal. 13:20:48 PhilDay has joined #wcag2ict 13:21:47 A bit longer note now, and Sam added not that, for multiple displays, only one needs to met. 13:23:25 q+ 13:23:31 ack Chuck 13:23:48 Fernanda noted (in survey) that edit seems like a significant departure from WCAG. 13:24:10 present+ 13:24:35 maryjom: It is not clear Fernanda saw Sam's proposal. 13:24:46 q+ 13:25:25 Chuck: Response critiques existing WCAG guidance, so I don't think we should go there. 13:25:53 s /we should go there/we should not go there/ 13:26:23 maryjom: Agree with not touching WCAG, 2013 wcag2ict had someing for 1.4.4 resize text and we have not revisited that previous guidence until now. 13:26:44 Text from SC problematic for 1.4.4 in current editor's draft is as follows: 13:26:44 q? 13:26:44 1.4.4 Resize Text—because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.4 in a closed environment may place a much heavier burden on the content author; 13:26:53 ... 2013 wcag2ict has stood the text of time, so we do not want to undermine anything. 13:26:56 ack mitch 13:27:25 ... but are trying to be responsive to questions and issues raised with our rewrite. 13:27:54 Mitch asks for clarification on which survey question we are working on? 13:28:46 maryjom: Previously, we had options and responses (was on option 4 and 5) and we will come back to those. 13:29:27 mitch11: That helps, links in survey are not quite aligned. 13:29:35 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-issue-4-resize-text/results#xq2 13:30:05 I think this is the correct link for the current TOPIC: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-issue-4-resize-text/results#xq2 13:30:43 maryjom: First item is survey is NOT a question but an introduction. For today, we are using numbered options as part of survey question titles. 13:31:31 mitch11t: The slipery slope I have concern for is that 1.4.4 is the only SC which include "without the use of AT" so that is an outlier. 13:32:06 POLL 1: For the original proposal, which proposed response do you prefer for Point 3: 1) Option 2, 2) Option 3, or 3) Something else 13:32:26 maryjom: Option 3 is sams edits. 13:32:39 q+ 13:32:44 ack mitch 13:32:52 3 13:32:56 3, then 2 13:33:19 2 (option 3), then 1 (option 2) 13:33:45 2 13:33:57 3 (something else): based on option 3 13:34:05 but with a further edit 13:34:11 maryjom: option 3 is choice 2 in the poll 13:34:35 mitch11: One more look please... 13:35:16 2 13:35:32 ... Can we phrase in a way that encourages resize even if does not meet 1.4.4? Meeting intent should be okay. 13:35:40 helping to meet the user need... 13:35:52 q+ 13:35:55 ack Chuck 13:36:04 .... want to says "its a good idea" even if not meeting SC literally 13:36:37 Chuck: I suggested phrasing in the possitive, to encourage people to do something -- even if still technially a failure 13:37:15 maryjom: There are already standards for non-web software which say to work with platform setting... 13:37:30 ... that might not go to %200, but nowadays mostly does. 13:38:14 Proposed: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to scale content to the extent supported by user settings in the platform. 13:39:47 q+ 13:40:16 BruceÑ Are we loosing "intent"? 13:40:19 q+ 13:40:28 ack bruce_bailey 13:40:36 ack mitch11 13:40:43 ack mitch 13:41:17 mitch: I purposefully removed "intent" so we could avoid a judgment on whether or not we meet the criterion. 13:41:24 bruce_bailey has joined #wcag2ict 13:41:30 present+ 13:41:41 mitch: It reminds me that we need to meet the user needs rather than the criteria. 13:42:02 +1 to mitch's proposal 13:42:47 User need edit: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to scale content to the extent supported by user settings in the platform in order to meet the user needs addressed by this success criterion. 13:42:56 Proposed: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to scale content to the extent supported by user settings in the platform. 13:43:36 Proposed and revised: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged meet user needs by scaling content to the extent supported by user settings in the platform. 13:43:54 +1 to newest typed proposal. 13:44:45 Tweak to Mitch's revised version: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to meet user needs by scaling content to the extent supported by user settings in the platform. 13:45:21 maryjom: Reminder: This is NOT change to document, just what we are putting in an issues response reply 13:46:27 Original version (intent): For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, scaling content to the extent supported by user settings in the platform is the best approach for meeting the intent of this success criterion. 13:46:46 Mitch original: For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to scale content to the extent supported by user settings in the platform. 13:46:52 Poll: Can you accept the proposed revisions (from Sam and Mitch) to the Issue 4 response? 1) Yes, as-is, 2) Yes, with edits, 3) No...make your suggestion. 13:47:01 Mitch revised (user needs): For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to meet user needs by scaling content to the extent supported by user settings in the platform. 13:47:13 2 13:47:29 Sorry, I meant 1 13:47:40 1 13:47:43 1 13:47:46 1 13:48:37 Maryjo: We will do any resolutions after survey. 13:48:53 https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit#heading=h.2tnvnhlrfncu 13:49:00 ... Moving on in survey, points 4 and 5 13:49:41 ... link is to google doc where these are, but most comments were about moving points 4 and 5 13:50:05 brb 13:50:06 Question 2 of 4 reviewing this content: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-issue-4-resize-text/results#xq3 13:51:16 ... 6 sufficient, sam voted something else as he had question about Point 5. We've addressed that. 13:51:59 back 13:53:06 maryjom: Fernanda asked if we should reference ADA or 20/70 or 20/80 referenced in CSS pixel equivalent discussion. 13:53:23 q+ 13:54:29 [screen share and accept minor edits in doc for clarity during call] 13:54:54 ack Chuck 13:55:09 ack Ch 13:55:31 Chuck: Reminder of context, this is comment / response. We are not drafting changes at this point. 13:55:39 +1 Phil's edits 13:56:02 maryjom: Correct, after we are happy with responses to commenters, we will have an opportunity to revisit text. 13:56:02 POLL: For the “Addition to proposals” content that was moved up from points 4 & 5, which version of that text should be included in the response to Point 3? 1) Option 1, 2) Option 2 – Phil’s edit, or 3) neither, or 4) something else. 13:56:18 2 13:56:37 2 13:56:43 4... 13:56:49 Addition to proposals: Option 1: Potential additional content for the response 13:56:49 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:56:49 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:56:49 Addition to proposals: Option 2: Phil edit 13:56:51 Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would address the user need behind this success criterion. (Examples are given of what this minimum text size could be in Section 508, clause 402.4 or ADA 2010 standard, clause 707.7.2.) 13:56:51 Where a non-web software program does not allow measurement of physical size, the non-web software should support scaling of 200%. 13:56:56 ack mitch 13:58:24 mitch11: I think for response we should be less specific, and just mention other standards to meet users needs... 13:59:01 ...Response sounds like testable criteria (size of letter h) but we are not planning to have that detail in WCAG2ICT. 13:59:07 q+ to ask for scribe change 13:59:21 ack Ch 13:59:21 Chuck, you wanted to ask for scribe change 13:59:54 Option 3: Mitch more generic 13:59:54 Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would address the user need behind this success criterion. 13:59:54 Where a non-web software program does not allow measurement of physical size, the non-web software should support scaling of 200%. 14:00:23 Phill: I've put a suggestion to Mitch's edit 14:00:25 Mike_Pluke has joined #wcag2ict 14:01:22 Mitch: I think the last option doesn't sound quite right. The question is what to do if it doesn't support 200 14:01:45 FernandaBonnin has joined #WCAG2ICT 14:01:47 present+ 14:01:55 present+ 14:02:37 ... We are responding to a situation where it does not reach 200 14:03:04 MJ: I think we are referring to a case where it's not possible to reach 200 14:03:19 Option 3: Mitch more generic 14:03:19 Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would also address the user need behind this success criterion. 14:04:34 q? 14:04:41 MJ: Any concerns with removing the sentence as Mitch describe? 14:04:59 Sam has joined #wcag2ict 14:05:07 Daniel: The proposal is in the google doc? 14:05:15 MaryJo: Yes 14:06:36 POLL: Which do you prefer for the "Addition to proposals” content? 1) Option 1 - original text, 2) Option 2-Phil's edit, 3) Option 3 - mitch's suggestion, or 4) something else? 14:06:49 2, then 3 14:07:24 (Meaning I would accept 3, but prefer 2, not that we should include both!) 14:07:24 2, happy with 3 as well 14:07:28 2, then 3 for me too 14:07:32 3, or 2 removing the last sentence 14:07:37 2 14:07:47 3, or 2 without last sentence 14:07:57 2 14:08:04 2 has the consensus 14:08:55 Option 2b: Phil edit (with last sentence removed) 14:08:55 Where a platform does not support text enlargement up to 200%, non-web software content that has sufficiently large text would address the user need behind this success criterion. (Examples are given of what this minimum text size could be in Section 508, clause 402.4 or ADA 2010 standard, clause 707.7.2.) 14:09:06 MJ: 2 has that last sentence. Question is having paragraph 1 with more details about these examples of other standards that provide these criteria 14:09:21 ... Is it agreeable? 14:09:41 POLL: Is it acceptable to include option 2, removing the last sentence? 1) Yes or 2) No 14:09:49 1 14:09:50 1 14:09:51 1 14:09:57 1 14:09:58 1 14:10:00 1 14:10:08 uno 14:10:20 MJ: I think we reached consensus 14:10:56 1 14:11:37 DRAFT RESOLUTION: Use option 3, as edited with the “Addition to proposals” option 2B as the response to Point 3 in Issue 4. 14:11:47 q+ 14:12:05 ack mitch 14:12:43 Mitch: We agreed on some changes to Option 3. I deleted the previous version. 14:13:59 2b to or not 2b that is the question :) 14:14:00 Option 3: (latest edited version from Google Doc) Take pertinent text from understanding and expand to non-web (Sam edits) 14:14:00 When known by the authors that a Where the user agent or platform does not provide a text enlargement function, authors would need to provide it. The normative requirement of 1.4.4 has no exemption for inadequate user agent support, and (Understanding SC 1.4.4) clarifies this. It says, "The scaling of content is primarily a user agent 14:14:00 responsibility," but also, "If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent." 14:14:00 To expand the understanding’s content to a non-web context: 14:14:02 "For non-web documents, the scaling of content is primarily a user agent responsibility [and for non-web software, scaling of content is primarily a platform responsibility]. If the author is using a technology whose user agents or platform software do not provide zoom support, the author is responsible to provide this type of functionality 14:14:02 directly or to provide content that works with the type of functionality provided by the user agent [or platform software]." 14:14:02 For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to meet user needs by scaling content to the extent supported by user settings in the platform. 14:14:03 Where the same information is conveyed on multiple displays only one display needs to meet this SC. 14:14:03 DRAFT RESOLUTION: Use option 3, as edited in the Google doc with the “Addition to proposals” option 2B (in IRC above) as the response to Point 3 in Issue 4. 14:14:09 +1 14:14:16 +1 14:14:18 +1 14:14:19 +1 14:14:20 +1 14:14:27 +1 14:14:29 +1 14:14:40 RESOLUTION: Use option 3, as edited in the Google doc with the “Addition to proposals” option 2B (in IRC above) as the response to Point 3 in Issue 4. 14:15:01 TOPIC: Question (2 of 4) Points 4 & 5: Parts or all of the text is a sufficient size 14:15:04 MJ: Thanks everybody. This is really good, and we are getting there 14:15:29 https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit#heading=h.93h4xc1b7t1s 14:16:39 Point 5: We should allow most or all text to enlarge to less than 200%, when the text is initially not particularly small\ 14:16:50 Point 4: We should allow large text to enlarge to less than 200%. 14:17:13 q+ 14:17:38 ack mitch 14:17:44 MJ: Mitch proposed two options. We haven't surveyed these yet. I think we should talk about them now. 14:18:49 Mitch: I would delete the obsolete ones at this point. Option 2.3 should be a separate option 14:19:33 ... I would concentrate on point 4, point 5 we already addressed 14:19:38 MJ: Agree. 14:19:44 q+ can we poll the 2 options? 14:20:05 ... For point 4 we have these two suggestions. Has everyone had a chance to read through these? 14:20:42 POLL: Which response to Point 4 do you prefer? 1) Option 1, 2) Option 2, or 3) Something else. 14:20:48 2, then 1 14:20:59 scribe- 14:21:07 Option 1: Mitch’s 1st try 14:21:07 We’ve heard from the community, including members of the Low Vision Task Force, that in some contexts it can be better for users to enlarge already-large text to less than 200% of its starting size. For example, current guidance from both Google and Apple for app designers advises that as user settings double the size of body text in apps, 14:21:07 heading text be increased to a size larger than body text but less than doubled. Such an approach would not meet SC 1.4.4, which is clear in its requirement that text can be resized to 200%. Policies outside of WCAG may allow meeting user needs in ways that do not meet the technical standards, e.g. through "equivalent facilitation". 14:21:07 Option 2: Mitch’s 2nd try 14:21:09 While use cases are common on iOS and Android, this same concern also arises in web content, so we defer to #1671 to address these aspects of the current issue. 14:21:31 1, but also happy with 2 14:21:41 2 also happy w 1 14:21:47 1 14:21:50 1 14:21:58 1 14:21:58 1 then 2 14:22:04 1 14:22:33 MJ: Seems the more explanatory is the preference. But since everyone is happy with the other as well, do we need any edits? 14:23:00 Phill: I'm not sure if the reference #1671. Is this a Google docs versioning error? 14:23:16 Chuck: I just pulled it up and it's correct. 14:23:23 Mitch: That's a WCAG issue number 14:23:40 MJ: Option one does not include a link to that issue 14:23:52 RESOLUTION: Use Option 1 as the response to points 4 & 5 in the issue, as-is. 14:24:24 TOPIC: Question (3 of 4 on 1.4.4 Text Resizing) Are built-in platform accessibility features considered AT? 14:24:45 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-issue-4-resize-text/results#xq4 14:24:58 Link to google doc Point 6 which has 2 responses in the review: https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit#heading=h.unzc04jrzs5c 14:25:42 Here’s the WCAG text for 1.4.4: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. 14:25:53 MJ: I do want to include the WCAG text for 1.4.4 so that we have it in front of us for reference 14:27:39 +1 we can't do that. 14:27:42 q+ 14:27:50 ack sam 14:28:10 Sam: Based on my comment, does that language need to be there when applied to the rest of IT? 14:28:13 Option 3: (latest edited version from Google Doc) Take pertinent text from understanding and expand to non-web (Sam edits) - this was originally Point 4 option 1. 14:28:13 When known by the authors that a user agent or platform does not provide a text enlargement function, authors would need to provide it. The normative requirement of 1.4.4 has no exemption for inadequate user agent support, and (Understanding SC 1.4.4) clarifies this. It says, "The scaling of content is primarily a user agent responsibility," but 14:28:13 also, "If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent." 14:28:13 To expand the understanding’s content to a non-web context: 14:28:15 "For non-web documents, the scaling of content is primarily a user agent responsibility [and for non-web software, scaling of content is primarily a platform responsibility]. If the author is using a technology whose user agents or platform software do not provide zoom support, the author is responsible to provide this type of functionality 14:28:15 directly or to provide content that works with the type of functionality provided by the user agent [or platform software]." 14:28:15 For non-web software, there may be cases where the platform does not scale all content up to 200%. In such cases, authors are encouraged to meet user needs by scaling content to the extent supported by user settings in the platform. 14:28:16 Where the same information is conveyed on multiple displays only one display needs to meet this SC. 14:29:10 ... By removing the part, it gives so much power for authors, platforms, and others to meet the requirement 14:29:24 ... Also, ICT is much broader than just the web domain 14:29:28 q? 14:29:29 q+ 14:29:33 q+ to offer perspective on why "without AT" is in SC 14:30:22 q+ 14:31:00 q+ 14:31:14 ack mitch 14:31:33 ack bruce_bailey 14:31:33 bruce_bailey, you wanted to offer perspective on why "without AT" is in SC 14:31:51 q+ 14:32:00 ack Chuck 14:32:05 Bruce: If we can drop the "without AT" that would be fine for WCAG2ICT. It won't be good for WCAG, as there may not be magnification software on the Web 14:32:28 Chuck: I don't think our remit allows us to define what is AT 14:33:39 ... I am supportive of point 1 as it is inferred from the supporting documents, in the form of a sufficient technique 14:33:52 +1 to Chuck. Is browser zoom an AT in of itself or built in accessibility feature of the browser. 14:33:57 https://www.w3.org/WAI/WCAG22/Techniques/general/G142 14:33:58 ... That's G142. It allows from non-author provided support from user agents 14:34:06 q+ 14:34:26 q+ 14:34:26 ack FernandaBonnin 14:34:44 ... In this case, by inference, we don't have to counter WCAG 14:34:53 ack sam 14:35:13 Fernanda: Some magnifiers just change viewport, not text rendering 14:35:19 q- 14:35:52 ack mitch 14:35:54 Sam: Sometimes accessibility settings are placed in different areas, causing more harm than benefit 14:36:01 q+ 14:36:31 Mitch: I tihnk there is a huge benefit for user not to use "traditional magnifiers" 14:36:51 s/It won't be good for WCAG, as there may not be magnification software on the Web/It would not have been good for WCAG as we might have gotten universal browser zoom/ 14:37:11 ... On software, I think it is hard to achieve 14:37:22 s/as we might have gotten universal browser zoom/as we might never have gotten universal browser zoom/ 14:37:27 ... If the community follows what we say, that could make a great different to users 14:38:05 ... To Chuck's point, the question is not whether features are part of the platform, but which part of the platform they belong to 14:38:13 q? 14:38:20 ack maryjom 14:38:25 https://www.w3.org/TR/WCAG22/#dfn-assistive-technologies 14:38:38 hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents 14:39:05 mitch11 has joined #wcag2ict 14:39:24 q+ 14:39:44 MJ: If built-in platform accessibility features are considered AT, that means you could not use some of the most well-known mobile OS accessibility features to meet this 14:40:15 ... Capturing the screen, and potentially causing things to be pixelated does not sound like the best option 14:40:16 q+ to say accessibility settings is not the same as "assistive technology" 14:41:02 ... For example, at the bottom of mobile apps there are panes, you could put your finger on each of them and they will expand 14:41:15 q+ to raise an issue with AGWG to expand definition of AT with applicable examples that include but are not limited to a list of OS and user agent accessibility settings? 14:41:19 ack Sam 14:41:19 ... You want for these to be able to pass 14:41:54 Sam: I think of devices like printers, where's text enlargement. If it's in general settings, that's a mainstream. IF it's in accessibility settings, then is it AT? 14:42:12 Definition from Tech Act: The term “assistive technology device” means any item, piece of equipment, or product system, whether acquired commercially off the shelf, modified, or customized, that is used to increase, maintain, or improve functional capabilities of a child with a disability. 14:42:24 ack bruce_bailey 14:42:24 bruce_bailey, you wanted to say accessibility settings is not the same as "assistive technology" 14:42:33 ... I find it difficult to ask people to put settings in the right place or call things the right way, in terms of readability 14:42:43 +1 to Bruce 14:42:47 Bruce: I think we don't need to decide when a feature becomes AT and when it does not 14:43:04 ack ChrisLoiselle 14:43:04 ChrisLoiselle, you wanted to raise an issue with AGWG to expand definition of AT with applicable examples that include but are not limited to a list of OS and user agent 14:43:07 ... accessibility settings? 14:43:51 Chris: For me whether it's a feature in the settings area or not it doesn't matter as much. This is more an issue with AG to somewhat expand or qualify that definition 14:44:12 q+ 14:44:33 For the purposes of the “without assistive technology” requirement in 1.4.4, built-in platform accessibility **settings** are not considered assistive technology. 14:44:45 q+ 14:44:53 ack PhilDay 14:45:15 Phill: What if wwe completely ignore the mention of assistive technologies and, instead, we pull out the key differences? 14:45:33 ... For example, magnifiers versus mechanisms to manipulate text size 14:45:34 "settings" is more specific than "features" but "settings" works fine in context 14:45:36 ack mitch 14:45:45 Mitch: I like that suggestion 14:46:29 q+ 14:46:38 ... I just wanted to acknowledge that by the time this was written, choices were significantly less 14:46:39 ack Sam 14:47:05 Sam: Could we take Phill's comment that when magnifiers are used that don't make things fuzzy you would be meeting the SC? 14:47:25 MJ: I think we are going to have to work on what the text would look like in tomorrow's meeting 14:48:36 MJ: Next survey question is whether there is need for changes in 1.4.4 or guidance is sufficient as-is. I think we are going to have to discuss tomorrow 14:49:13 Topic for tomorrow: Work on...https://docs.google.com/document/d/1p5EX9d5Q9L1CghcECjPMVqIBxg4UJUZ5U3A3EZhNxUQ/edit#heading=h.1eq8h983hm9z 14:50:16 zakim, take up next 14:50:16 agendum 3 -- Survey results: Follow-up survey addressing public comments, SOTD -- taken up [from maryjom] 14:50:20 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-public-comments-group4/results 14:50:37 MJ: Let's jump to #5 14:50:41 TOPIC: Review: Proposed updates to Status of this Document 14:50:54 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-public-comments-group4/results#xq8 14:51:09 PR: https://github.com/w3c/wcag2ict/pull/344/files 14:51:11 present+ 14:51:23 In context of the document: https://deploy-preview-344--wcag2ict.netlify.app/#sotd 14:51:27 MJ: Everybody says they are OK with the text as-is 14:52:04 DRAFT RESOLUTION: Accept the proposed edits to the SOTD in PR 344, as-is. 14:52:05 +1 14:52:07 +1 14:52:07 +1 14:52:13 +1 14:52:15 +1 14:52:19 +1 14:52:25 RESOLUTION: Accept the proposed edits to the SOTD in PR 344, as-is. 14:52:25 +1 14:52:38 I had a plus 6 14:52:42 RRSagent, draft minutes 14:52:43 I have made the request to generate https://www.w3.org/2024/05/09-wcag2ict-minutes.html bruce_bailey 14:53:04 MJ: Let's go to issue 226. These are answers to the issue, not meant to go into the document 14:53:06 TOPIC: Proposed answer to Issue 226 14:53:09 https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-public-comments-group4/results#xq4 14:53:26 Content we were reviewing: https://docs.google.com/document/d/1TbtNcNjrpog8-6OYloMcPILh2UsqUOXBjPwVwv7dPsw/edit#heading=h.ht1jaga8biwd 14:54:10 MJ: Let's go to the Google doc to see proposed edits 14:54:34 q+ 14:54:51 ack mitch 14:55:06 +1 14:55:48 +1 14:55:49 DRAFT RESOLUTION: Respond to Issue 226 using the proposed Option 2, with Bruce's and Olivia's edits shown in the Google doc. 14:55:54 +1 14:55:56 +1 14:55:58 +1 14:56:00