12:57:51 RRSAgent has joined #matf 12:57:56 logging to https://www.w3.org/2025/07/16-matf-irc 12:57:56 RRSAgent, make logs Public 12:57:57 please title this meeting ("meeting: ..."), JJ 12:57:59 Zakim, this is MATF 16 July 2025 12:57:59 got it, JJ 12:58:07 Meeting: MATF 16 July 2025 12:58:12 chair+ 12:58:20 agenda+ Page definition proposal 12:58:25 agenda+ Accessibility interface proposal 12:58:31 agenda+ 1.3.3 Sensory Characteristics 12:58:42 agenda+ 1.3.4 Orientation 12:58:42 agenda+ 2.5.1 Pointer Gestures 12:58:46 agenda+ 2.5.2 Pointer Cancellation 12:58:46 present+ 12:58:50 agenda+ 2.5.3 Label in Name 13:02:41 regrets+ qbalsdon 13:02:47 regrets+ TimGravemaker 13:02:53 regrets+ Julian 13:03:21 GleidsonRamos has joined #matf 13:03:27 present+ 13:03:33 RacheleD has joined #matf 13:03:44 present+ 13:05:51 Proposal during Summer season: 13:05:51 23 July - meeting 13:05:51 30 July - no meeting 13:05:51 6 August - no meeting 13:05:52 13 August - meeting 13:06:17 rachaely has joined #matf 13:06:38 q+ 13:06:44 +1 13:06:44 +1 13:06:49 +1 13:08:25 ACTION: Cancel meetings on 30 July / 6 August 13:08:33 Carol has joined #MATF 13:08:53 present + 13:09:24 Zakim, propose a scribe 13:09:24 Not knowing who is chairing or who scribed recently, I propose RacheleD 13:09:51 https://github.com/w3c/matf/wiki/IRC-Cheatsheet 13:10:19 q+ 13:10:29 ack Joe_Humbert 13:11:38 ACTION: Look into adding css working group bot to #matf for automatically adding notes to GitHub 13:11:46 move to next agendum 13:11:46 agendum 1 -- Page definition proposal -- taken up [from JJ] 13:13:24 Two actions from last time to review 13:13:33 https://github.com/w3c/matf/issues/110#issuecomment-3052876390 13:13:51 New proposal: https://github.com/w3c/matf/issues/110#issuecomment-3078323840 13:14:36 Page 13:14:36 A page is a distinct part of a mobile application that presents specific content or functionality and is rendered together with its associated resources. Users navigate between pages to complete actions or access different features. 13:14:36 NOTE 1 13:14:36 Dialogs, modals, bottom sheets, navigation menus, and other similar user interface elements are components of a page but are not considered pages themselves. These elements depend on the underlying page for context and are part of the page's functionality rather than standalone navigational destinations. 13:14:38 EXAMPLE 1 13:14:38 A native banking app's account overview screen that displays account balances, recent transactions and interactive charts. The screen includes native components for all interface elements, all rendered together as a single interface. 13:14:38 EXAMPLE 2 13:14:39 A mobile web banking app's account overview page that displays account balances, recent transactions and interactive charts. The page includes web components for all interface elements, all rendered together in the mobile browser. 13:14:39 EXAMPLE 3 13:14:39 A hybrid banking app's account overview screen that displays account balances, recent transactions and interactive charts. The screen includes native components for account balances and recent transactions, plus web components for interactive charts, all rendered together as a unified interface. 13:15:26 q+ 13:15:39 Ack joe_humbert 13:17:46 Slightly modified Example 2 to "web components" 13:18:16 Updated Example 3 to "native components" 13:18:35 ack Joe_Humbert 13:19:32 Joe_Humbert: Should we include bottomsheets as a page? In our company's app, a bottomsheet is like a modal and really is its own page. I'm concerned about how broad Note 1 is. 13:21:00 Joe_Humbert: Maybe it needs to be tweaked to include partial views 13:23:02 Joe_Humbert: suggests: "Interface elements that rely on the underlaying page context" ? 13:23:22 q+ 13:23:27 ack rachaely 13:24:02 rachaely: I mostly agree. The value of the page title is that the majority of the screen has changed 13:24:38 JJ: Maybe add a Note that it's a best practice to add title to modals 13:25:16 rachaely: Would it be more clear to say something about the amount of content on the screen changing 13:25:57 q+ 13:26:04 JJ: Might be a win for accessibility if they think they should add a title 13:26:10 ack Joe_Humbert 13:26:52 Joe_Humbert: In Android and iOS "title" is part of the structure that should be provided 13:26:59 for dialogs 13:28:52 move to next agendum 13:28:54 agendum 2 -- Accessibility interface proposal -- taken up [from JJ] 13:28:54 JJ: Please add thoughts on page to github. It's close to having a first definition that could work for the majority of mobile application cases. 13:29:08 https://github.com/w3c/matf/issues/220 13:29:18 sub issue of: https://github.com/w3c/matf/issues/66 13:30:06 JJ: Still some discussion whether "keyboard interface" is replaced with "accessibility interface" 13:30:13 Proposed definition: 13:30:13 accessibility interface 13:30:13 interface used by assistive technology software to obtain semantic information about content and interact with mobile applications 13:30:13 Note 1 13:30:14 An accessibility interface allows assistive technology to access and interpret content even when the mobile application does not contain accessibility support 13:30:14 Example 13:30:14 A mobile application exposes its content through the platform's accessibility API (such as UIAccessibility on iOS or AccessibilityService on Android). Screen readers, voice control systems, and switch access software can all use this interface to obtain information about the application's content, structure, and state, enabling users to 13:30:15 navigate and interact with the application through their preferred assistive technology. 13:30:15 Note 2 13:30:15 Operation of an application through a keyboard interface does not automatically qualify as operation through an accessibility interface, as keyboard interfaces focus on keystroke input while accessibility interfaces provide broader capabilities for assistive technology software. 13:31:24 JJ: "accessibility interface" can be used more broadly 13:35:02 q+ 13:35:12 ack Joe_Humbert 13:36:07 Joe_Humbert: Do we need to broaden the first definition to "assistive technology software and settings"? There are settings in Android and iOS that aren't considered software. 13:37:07 JJ: Do we focus only on the interaction part or do we also want to emphasis the semantic information that can be obtained? 13:37:34 Joe_Humbert: I do think we should keep the semantic information in there. 13:37:39 q+ 13:37:57 ACTION: Attempt to make "assistive technology software" broader to make sure all types of assistive tech are included 13:38:01 ack rachaely 13:38:24 rachaely: Is there a definition of assistive technology in WCAG? 13:38:39 https://www.w3.org/TR/wcag2ict-22/#dfn-assistive-technologies 13:39:47 https://www.w3.org/TR/WCAG22/#dfn-assistive-technologies 13:40:30 Joe_Humbert: Maybe we change it from "assistive technology software" to "assistive technology" 13:40:43 Jamie has joined #matf 13:40:50 prsent+ 13:40:51 ACTION: Change 'assistive technology software' (2x) to 'assistive technology' with link to definition 13:41:19 ACTION: Figure out where the accessibility interface definition should be used 13:42:02 JJ: We might need to change the definition of mobile context 13:42:25 move to next agendum 13:42:25 agendum 3 -- 1.3.3 Sensory Characteristics -- taken up [from JJ] 13:42:26 https://github.com/w3c/matf/issues/24 13:42:52 JJ: Mostly came down to the addition of haptics 13:43:52 Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, sound or haptics. 13:44:01 +1 to propsed change 13:44:16 +1 13:44:34 Poll: do we accept the definition proposal? 13:44:36 +1 13:44:39 +1 13:44:40 +1 13:44:44 +1 13:44:44 +1 13:45:24 +1 13:46:19 ACTION: Accept proposal, add decision to group e-mail with option to block the decision 13:46:26 move to next agendum 13:46:26 agendum 4 -- 1.3.4 Orientation -- taken up [from JJ] 13:46:38 https://github.com/w3c/matf/issues/25 13:47:24 JJ: Orientation was added to Draft in February then reopened 13:48:55 Success Criterion 1.4.4 Orientation 13:48:55 This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4. 13:48:55 Note 1 13:48:55 Content that supports orientation changes must continue to meet all applicable success criteria in each supported orientation. 13:48:57 Note 2 13:48:57 It is considered a best practice to support all available orientations, such as as portrait, portrait (reversed), landscape, and landscape (reversed). Platform restrictions may limit available orientations for specific content types (such as video playback) or system-level functions. 13:51:46 JJ: There might be some platform restrictions with native components that would prevent supporting all orientations 13:52:18 Poll: do we accept the definition proposal? 13:52:25 +1 13:52:31 +1 13:52:36 +1 13:52:44 q+ 13:52:50 ack rachaely 13:53:15 rachaely: I wanted to understand what our stance on reflow for mobile apps? 13:53:36 1.4.10: https://github.com/w3c/matf/issues/4 13:55:16 0 - i'm concerned that companies might take advantage of the last sentence in the second note, but I guess there is always the essential execption that they could try and use 13:55:46 +1 13:55:53 +1 13:56:59 q+ 13:57:02 Poll: Remove "Platform restrictions may limit available orientations for specific content types (such as video playback) or system-level functions." 13:57:08 +1 13:57:15 q+ 13:57:18 ack Joe_Humbert 13:57:56 essential 13:57:57 if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform 13:58:00 Joe_Humbert: WCAG 2.2 says "unless a specific display orientation is essential" do we need the second sentence? 13:58:03 ack rachaely 13:58:14 Zakim, close the queue 13:58:14 ok, JJ, the speaker queue is closed 13:58:56 rachaely: Some things like a video player may only support landscape, not portrait. Should that be a standalone note on its own? But that may be covered 13:59:46 +1 13:59:51 +1 13:59:58 ACTION: Remove "Platform restrictions may limit available orientations for specific content types (such as video playback) or system-level functions." from note 14:00:04 +1 14:00:08 (potentially as separate note) 14:00:16 Joe_Humbert: I see some validity to keeping it but it should probably be a separate note 14:01:24 Zakim, list participants 14:01:24 As of this point the attendees have been Joe_Humbert, GleidsonRamos, RacheleD 14:01:31 + Jamie 14:01:42 rrsagent, make minutes 14:01:43 I have made the request to generate https://www.w3.org/2025/07/16-matf-minutes.html RacheleD 14:01:50 Zakim 14:01:50 Thanks for scribing RacheleD 14:01:56 present+ Jamie 14:02:01 present+ rachaely 14:02:10 Zakim, list participants 14:02:10 As of this point the attendees have been Joe_Humbert, GleidsonRamos, RacheleD, Jamie, rachaely 14:02:14 rrsagent, make minutes 14:02:15 I have made the request to generate https://www.w3.org/2025/07/16-matf-minutes.html RacheleD 14:02:21 present+ Carol 14:02:21 oops looks like I misspelled present :P 14:02:29 rrsagent, make minutes 14:02:30 I have made the request to generate https://www.w3.org/2025/07/16-matf-minutes.html JJ 14:03:21 regrets+ Aash 14:03:23 rrsagent, make minutes 14:03:24 I have made the request to generate https://www.w3.org/2025/07/16-matf-minutes.html JJ 14:04:19 scribe: RacheleD 14:04:22 rrsagent, make minutes 14:04:23 I have made the request to generate https://www.w3.org/2025/07/16-matf-minutes.html JJ