19:04:07 RRSAgent has joined #matf 19:04:12 logging to https://www.w3.org/2024/04/15-matf-irc 19:04:12 RRSAgent, make logs Public 19:04:13 please title this meeting ("meeting: ..."), hdv 19:04:26 present+ 19:04:29 Bram has joined #matf 19:04:32 meeting: MATF, 15 April 2024 19:04:35 present+ 19:04:36 Karla7 has joined #matf 19:04:41 scribe: hdv 19:04:50 present+ 19:04:50 present+ 19:05:01 Joe_Humbert has joined #matf 19:05:14 Present+ 19:05:16 Carolina has joined #MATF 19:05:29 present+ 19:05:38 present+ 19:05:49 [JJ shares agenda] 19:05:56 present+ 19:06:18 Agenda: https://www.w3.org/events/meetings/6f983b29-7191-4707-acd5-170c249ebedf/20240415T150000/ 19:06:47 JJ: are there topics someone wants to add? 19:07:08 doubleA has joined #matf 19:07:20 topic: Time picker 19:07:42 JJ: last week I shared the results of the meeting matrix: Wednesday best for Europe / Asia / US 19:08:20 JJ: times weren't clear in the surveys as daylight saving time happened between when we first started and today 19:08:35 present+ 19:08:45 JJ: so I opened a Calendly, which adjusts to your timezone taking daylight savings etc into account 19:09:04 JJ: we'll likely end up with one meeting for Europe/Asia and one for Europe/SU 19:09:07 s/SU/US 19:10:00 hdv: do the options include US / West coast? seems like most are earlier in the day? 19:10:26 JJ: there should be at least one suitable time for west coast in there 19:10:37 Topic: How WCAG 2.2 relates to mobile 19:10:52 [JJ shares screen] 19:11:33 JJ: some of the remarks in this doc are from 2022 19:11:42 QuintinB has joined #matf 19:11:46 present+ 19:12:17 JJ: we added the SCs and then in columns A to G it's WCAG, then in column H we tried to determine whether it's applicable, and in J to mobile native, and in J how to fix or apply the work 19:12:42 I would like to spend some time going through this - I'll probably do it in notes 19:13:14 Ah right comments - yeah comments are nice 19:13:15 JJ: I'm trying to work out how we could work together in this doc…with more people may get trickier 19:13:17 Joe_Humbert has joined #matf 19:13:39 Who are the “we” that worked on the spreadsheet? 19:13:39 Aastutosh: seems like a viable option to go 19:13:57 s/seems/the comment feature seems 19:14:26 If something gets out of hand, maybe then make a new sheet? 19:14:27 JJ: seems comments works best let's go with that 19:15:11 JJ: there's a lot filled in already in the doc, would be good to look at columns H and I in the spreadsheet and comment if you disagree / have thoughts 19:15:45 Jamie: is this something we'd go through at once or go through them one by one? 19:16:00 JJ: depends on the criteria, some have more comments than others 19:16:39 hdv: repeats Joe's question 19:16:54 Carolina has joined #MATF 19:17:04 present+ 19:17:14 JJ: me, and Mick and Neema 19:17:30 Jeanne: it was having issues for me in the COGA meeting as well 19:17:41 Jamers has joined #matf 19:17:54 Joe_Humbert: was having issues with IRC 19:17:57 Jeanne: it was having issues for me in the COGA meeting as well 19:18:14 JJ: and Kim Patch as well 19:18:51 JJ: would be nice if folks take a look in the next couple of days 19:19:06 JJ: please let me know if you don't have access yet 19:19:37 JJ: then… there's also a second tab, which is about what's missing in WCAG… would probably be input for WCAG 3 19:20:13 JJ: any questions so far? 19:20:33 Carolina: should we only comment when we agree? so not commenting means we agree? 19:20:49 JJ: yes would probably works best to only comment when you disagree 19:20:59 s/when we agree/when we disagree 19:21:08 RRSAgent, please draft minutes 19:21:09 I have made the request to generate https://www.w3.org/2024/04/15-matf-minutes.html hdv 19:21:17 Zakim, please draft minutes 19:21:17 I don't understand 'please draft minutes', hdv 19:21:36 [yay replace works] 19:21:46 Mick: should we get rid of the guidelines? 19:21:54 JJ: probably be good to keep them for now 19:22:25 Joe_Humbert: with WCAG2ICT, are they providing some language changes? 19:22:42 Joe_Humbert: to fit non web content? wonder if we could do something similar? 19:23:08 JJ: they do things like replace sets of “web pages” with “set of software” 19:23:23 WCAG2ICT did not consider "set of native apps" to be a thing 19:23:23 s/sets of “web pages”/“sets of web pages” 19:23:35 JJ: maybe mobile web views and apps 19:24:12 Topic: Facilitators group 19:24:56 JJ: had a meeting with TF facilitators earlier… they mentioned about the US DOJ, confirming to WCAG 2.1… multiple remarks from other facilitators, for mobile apps they refer to WCAG2ICT and don't include any exceptions to success criteria, which is currently done in Section 508 and in Europe 19:25:47 JJ: they are saying WCAG 2.1 has been around for long enough. We had some discussion about this earlier today. ADA, as I understand, would apply for government apps and apps the government bought 19:26:08 Joe_Humbert: title II is for government, but title III is also for companies 19:26:28 It would be nice to understand what applies to public bodies vs private companies 19:26:43 JJ: so would they remove exceptions? 19:26:56 Joe_Humbert: government like to have less standards, so it seems likely they would try and align 19:27:30 Topic: 1.4.4 Resize text 19:27:44 JJ: question: does resize text apply? 19:28:07 JJ: what's interesting is that OS settings can be used for this… with websites, this works differently 19:28:29 JJ: with apps it is trickier to determine the percentage…and in iOS there is dynamic font sizing now 19:28:50 JJ: that makes it even harder to determine how much text even has scaled. And we cannot inspect tex 19:28:54 s/tex/text 19:29:31 Joe_Humbert has joined #matf 19:29:35 QuintinB: what's completely missing… not sure how it works in iPhone but in Android, because we have scale independent sizes, we could set a minimum font size. This has been missing from WCAG since forver 19:29:35 On io 19:29:40 s/forver/forever 19:29:56 QuintinB: so you could say this is the smallest we allow and then go to scaling 19:30:29 on iOS they have typography in the human interface guidelines that give the pt size for all font styles and font sizes 19:30:32 JJ: wonder if we can add some kind of recommendation in guidelines 19:31:23 Carolina: if we're able to scale / zoom in and out, would only one be required or both of them? 19:31:33 Carolina: on iOS I use large, on Android I use the maximum 19:32:00 julianmka has joined #matf 19:32:51 julianmka has left #matf 19:33:08 julianmka0 has joined #MATF 19:33:15 julianmka0 has left #matf 19:33:15 Carolina: do we need to allow for both? 19:33:22 julianmka has joined #MATF 19:33:22 joe_humbert: do you mean in hybrid situations? 19:33:35 Carolina: I mean if you have the web view should you be able to pinch zoom and out? 19:34:20 The Evinced MCAG reduces everything to pixel sizes, maybe that is a logical way to go 19:35:14 I do think we need to have a "standard minimum" font size 19:35:17 JJ: another issue is that WCAG uses CSS pixels wjhich for apps you'd ned to convert 19:35:34 I would strongly suggest to drop the "200%" spec from a mobile interpretation; 200% or 2x is very web-based thinking particularly for larger heading font styles 19:36:18 Karen: in the passed we said we should not disable scaling 19:36:40 Karen: but others say now that as long as magnification works that suffices, have you discussed that here? 19:36:44 I don't think relying on magnification because that may be seriously inconvenient for many people 19:36:54 JJ: don't think we have discussed that here 19:37:18 JJ: is it sufficient if an app has its own resizing mechanism? 19:37:37 If the device supports actual text scaling through setting, apps should support that capability. 19:37:59 agree with julianmka 19:38:27 But at what point does it need to support the font size without loss of content or functionality? 19:38:49 JJ: the bold font setting is also interesting, lots of users (10%) use it we found in research 19:39:06 woah - can we get references for that? 19:39:34 Bold text stats: https://appt.org/en/stats/bold-text 19:39:36 I love me some sweet sweet data 19:39:38 thanks 19:40:00 "But at what point does it need to support the font size without loss of content or functionality?" -- show it all, let users determine whether it's functional/meets their needs 19:40:04 Also agree with julianmka 19:40:16 +1 julianmka 19:40:31 making it a part of the SC 19:40:42 JJ: in iOS / Android there is a limit too 19:40:43 It would be interesting to know how the web folks arrived at 200% 19:40:48 JJ: not sure if there is a limit on websites 19:40:52 +! QuintinB 19:41:13 Android can be done via ADB, it's just a multiplier as a float value 19:41:14 JJ: there are all users who decrease font sizes 19:42:13 Julian: could we include some kind of statement that when an OS supports a specific AT or accessibility setting, that app developers should support it? 19:42:55 Mobile Device Features sheet: https://docs.google.com/spreadsheets/d/1j1-C7t4sHtJqLT4YKJqLfJIl28DET6gYBQPczDFDWpY/edit#gid=0 19:43:02 Julian: we often hear about users with edge cases… 19:43:39 Joe_Humbert: should be careful about 'should' vs 'must'… eg there could be features that are newly released and developers might not have time to explore new features before they are released, could take months 19:44:03 Julian: valid point 19:44:37 On the other hand, you get settings that don’t get respected for months, to the point where the documentation actually says that it’s not usually respected because developers don’t know about it (e.g. android time to react) 19:44:44 JJ: maybe we can fort certain features, like text scaling, but not others 19:44:54 Sorry, years, not months 19:45:17 Joe_Humbert has joined #matf 19:45:19 Could state support must be given for a certain OS version, so not to put pressure around new releases 19:45:34 Jamie: are you sharing the doc because you feel it should be updated? 19:45:44 JJ: would be good to keep an eye on new features and discuss in these meetings how we deal with the new features 19:46:31 JJ: in the European rules there are a lot of requirements around user preferences, like color preferences 19:46:55 I think with Assistive technology/settings we could recommend a support timeline. Like support new AT within 1-2 years, but not sure that follows other specs/notes 19:47:24 hdv: is it EN 301 549? 19:47:33 I don't see Full Keyboard Access on the linked document, which is available since 1OS 14. Did I miss it? 19:47:33 JJ: yes, 3.2.1 of that 19:48:09 JJ: feel free to add any features that are missing 19:49:00 Topic: How to test single key shortcuts? 19:49:46 JJ: this is specifically how do we test this in apps? and how do people do it in websites? I also don't know how you would do it on websites? 19:50:00 JJ: there are some default ways in iOS to find out 19:50:07 q+ 19:50:21 q- 19:50:41 Rachele: for web there are bookmarklets that press all the keys for you, that seems not possible for apps 19:51:20 QuintinB: I'm working on figuring out how to test this 19:51:59 QuintinB: it is hard to find out discover shortcuts 19:52:14 Joe: there are tools to emulate keyboard, that may theoretically be possible, not sure if realistic 19:52:31 JJ: this is the Accessibility Scanner app by Google. which runs an accessibility service 19:53:12 Karen has joined #MATF 19:53:56 Some other options in web - look for shortcut instructions in the content, check the code for keydown, keyup and keypress listeners, and of course press all the keys 19:54:31 hdv: Rachele's strategy of using bookmarketls is smarter, would recommend that, but if all fails you could manually press all the keys, that should work for apps too 19:54:44 JJ: could be cumbersome 19:55:33 JJ: we probably want to write an understanding-doc for testing success criteria for apps with one or more ways to test a criterion 19:57:15 JJ: on web auditors can look at the source code for answers, with apps you can't unless you are given access to the source code 19:57:24 JJ: maybe something to discuss in the next meeting 19:58:13 Mick Keane: my experience is that I don't have access to the source code usually, and this is the most challenging part 19:58:22 JJ: when I audit I don't use the source code 19:59:27 JJ: equivalent to bookmarklets for websites would be automated testing, eg generic code to send key commands etc and apply this to any app… maybe interesting to build some kind of repository with some automated options 20:00:45 Joe_Humbert has joined #matf 20:01:07 Create a decision tree to guide testing methods? 20:01:28 hdv: maybe solution to source code vs not would be: you can never audit based on source code, because what you're testing is the UI that exists when the source code result is executed 20:01:51 I think we need to be careful will only end result testing. For things like roles in accessible names. End user result can be almost the same 20:01:58 hdv: you'd always need to test what the user sees, not what the source code in theory would do 20:02:16 If you want to check out some of what I am doing for keyboard testing: https://www.ally-keys.com 20:02:35 thank Quintin 20:02:53 Joe_Humbert right, but if there's a difference, wouldn't you need to test the result instead of the source code? 20:03:16 RRSagent meeting, please 20:03:19 RRSagent end meeting, please 20:03:22 RRSagent, end meeting, please 20:03:22 I'm logging. I don't understand 'end meeting', hdv. Try /msg RRSAgent help 20:03:26 Zakim, end meeting please 20:03:26 As of this point the attendees have been julianmka, RacheleDiTullio, Mick, hdv, Joe_Humbert, Carolina, Bram, Karla, doubleA, QuintinB 20:03:28 RRSAgent, please draft minutes 20:03:29 I have made the request to generate https://www.w3.org/2024/04/15-matf-minutes.html Zakim 20:03:35 I am happy to have been of service, hdv; please remember to excuse RRSAgent. Goodbye 20:03:37 Zakim has left #matf 20:04:04 yes. Just need to be careful. Not disagreeing with you 20:04:23 present+ 20:10:26 rrsagent, make minutes 20:10:27 I have made the request to generate https://www.w3.org/2024/04/15-matf-minutes.html JJ 20:12:05 Joe_Humbert has joined #matf