MATF 23 July 2025 – 23 July 2025

Meeting minutes

Page definition proposal

<JJ> Only note 1 has been updated based on feedback:

<JJ> Interface elements that rely on the underlying page for context (such as dialogs, modals, navigation menus, and similar components) are typically considered part of that page rather than standalone pages. However, interface elements that significantly change the majority of screen content or function as independent navigational destinations may be

<JJ> considered separate pages.

JJ: mosty the action was to tweake note 1. Conditions ho0w to deal with bottoms sheets etc.

<Joe_Humbert> +1 to latest version

<RobW> This is a nice improvement

Accessibility interface proposal

<JJ> move to previous agendum

ACTION: Vote on page definition proposal on GitHub at w3c/matf#110 (comment)

<JJ> github.com/w3c/matf/issues/220

<JJ> Actions were: w3c/matf#220 (comment)

<JJ> Interface used by assistive technology to obtain semantic information about content and interact with mobile applications.

<JJ> Note 1

<JJ> An accessibility interface allows assistive technology to access and interpret content even when the mobile application does not contain accessibility support.

<JJ> Example

<JJ> 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

<JJ> navigate and interact with the application through their preferred assistive technology.

<JJ> Note 2

<JJ> 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.

<JJ> Change is: "assistive technology software" modified to "assistive technology" (plus included link to WCAG's definition)

<RobW> Q: Why did we decide we needed a definition of an accessibility interface?

<RobW> I agree with that reasoning, thank you. I thought it might help us decide where it goes

<JJ> A: Mostly to address with potential gaps with 'keyboard interface' where certain types of assistive technologies are not covered in 2.1.1 and may not be covered in other success criteria

ACTION: Vote on accessibility interface definition proposal on GitHub at: w3c/matf#220 (comment)

<JJ> move to previous agendum

2.5.1 Pointer Gestures proposal

<JJ> github.com/w3c/matf/issues/37

<JJ> Proposal: w3c/matf#37 (comment)

<JJ> All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

<JJ> Note 1

<JJ> This requirement applies to mobile applications that interpret pointer actions (i.e., this does not apply to actions that are required to operate the platform software, operating system, or assistive technology). Each layer is responsible for its own pointer actions only, not for those in an underlying layer.

<JJ> Note 2

<JJ> Examples of multipoint gestures include pinch-to-zoom, two-finger scrolling, split-tap (where one finger rests on screen while another taps), and multi-finger swipes.

<JJ> Examples of path-based gestures include swiping through carousels where direction matters, sliders requiring specific directional movement, custom drawing gestures, and pull-to-refresh actions.

<JJ> Multipoint and path-based gestures handled by underlying layers (platform software, operating system, or assistive technology) are exempt under Note 1.

<JJ> Note 3

<JJ> Platform accessibility features that allow gesture remapping (AssistiveTouch on iOS or Switch Access on Android) can satisfy this requirement by providing alternative input methods for complex gestures, eliminating the need for separate hardware solutions.

<JJ> https://w3c.github.io/matf/#success-criterion-2-5-1-pointer-gestures

<JJ> JJ: Summarizes feedback from the group and feedback on GitHub

<JJ> RobW: Asking if its intended that platform vendors are exempt

<JJ> JJ: Yes (at this point)

<JJ> RobW: It sounds like the intention is to differentiate between specific gestures?

ACTION: Merge "gestures include swiping through carousels where direction matters, sliders requiring specific directional movement" into something that emphasizes "specific directional movement"

<JJ> RobW: Agrees pull to refresh should be included as path-based gestures - but in both platforms it's built into a scroll view so it would be exempt

<RobW> I can't think of any

<JJ> JJ: Asking about more examples of multipoint gestures to include?

ACTION: Vote on 2.5.1 proposal at: w3c/matf#37 (comment)

2.5.2 Pointer Cancellation proposal

<JJ> w3c/matf#38

<JJ> Proposed definition: w3c/matf#38 (comment)

<JJ> For functionality that can be operated using a single pointer, at least one of the following is true:

<JJ> No Down-Event

<JJ> The down-event of the pointer is not used to execute any part of the function;

<JJ> Abort or Undo

<JJ> Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;

<JJ> Up Reversal

<JJ> The up-event reverses any outcome of the preceding down-event;

<JJ> Essential

<JJ> Completing the function on the down-event is essential.

<JJ> Note 1

<JJ> Note 2

<JJ> Functions that emulate a keyboard or numeric keypad key press are considered essential.

<JJ> Note 3

<JJ> Examples of essential functionality include features required for meeting system requirements (such as waking a device from sleep, power management controls, and emergency functions).

<JJ> https://w3c.github.io/matf/#success-criterion-2-5-2-pointer-cancellation

ACTION: How are we dealing with custom keyboards, are those exempt under note 2?

<JJ> RobW: pointing out custom keyboards and potential caveats