– DRAFT –
MATF 28 May 2025

<JJ> https://github.com/w3c/matf/wiki/IRC-Cheatsheet

<JJ> Jon_Gibbins: <Summary of what you said>

<Detlev> colon

<JJ> What's needed:

<JJ> - We need to create (sub) issues for each recorded action, to ensure they are tracked and can be assigned to someone

<JJ> - All (sub) issues need to be added to the MATF Project board, reflecting their status, e.g. To-Do, In Progress, In Review, Done

<JJ> - We need to identify which (sub) issues are blocking the progress on other issues, e.g. missing a certain definition can block the drafting of a certain success criterion

<JJ> - The blocking issues need to be put "In Progress" and we need to find candidates that are able to work on them

<JJ> - We need to change the way the agenda is created, instead of going through issues chronologically by their variation type, we should focus on blocking issues, and focus on completing "unblocked" issues

<JJ> https://github.com/orgs/w3c/projects/147

JJ: Summarises what he and Tanya discussed about project planning using Github issues and project tools.

<JJ> https://github.com/orgs/w3c/projects/56

<JJ> ^ Link is to WCAG project planning

<Jon_Gibbins> +1

<JJ> Do you agree with what's needed?

<GleidsonRamos> +1

<Karla> +1

<Megan_Pletzer> +1

<Carol> +1

<Tanya> +1

I think this is a good move.

<Joe_Humbert> +1 we need something to move things forward

JJ: The group should take some time to think about these suggestions and feedback via the group Slack to directly to JJ

<JJ> w3c/matf#12

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

JJ: Previous discussions have been around definition of “keyboard interface” versus “accessibility interface” in mobile environments. Need a definition to move forward.

Jon_Gibbins: I fear that “accessibility interface” is too vague or open to misinterpretation.

<JJ> Jon_Gibbins: Keyboard focus in apps is different compared to the web. Focus order (assistive technologies) vs Tab order (keyboard)

<JJ> Jon_Gibbins: My interpretation with anything keyboard interface related is some kind of device with keys

Jon_Gibbins: Just to clarify, I mean assistve technology (like a screen reader) is about reading order / virtual cursor, whereas keyboard is about Tab / focus order.

<Carol> I would think of 1.3.2 for reading order

Tanya: When auditing, sometimes issues do not cleanly fit into 2.1.1 Keyboard, e.g. interface elements are focusable by assistive technology and not by keyboard or vice versa.

<JJ> w3c/matf#51 (comment)

<Detlev> The checkpoint in EN 301 549 is 11.5.2.12 Execution of available actions

Detlev: EN 301 549 has a success criterion that captures when an interactive element that works with keyboard is not accessible to assistive technology (11.3.212. “Execution of available actions”)

Detlev: Correction 11.3.2.12

<Detlev> 11.5.2.12

Detlev: Correction 11.5.2.12

JJ: Accessibility Actions available on iOS and Android also need to be considered as an option for providing actions to mobile assistive technology software.

2.1.2 No Keyboard Trap

<JJ> w3c/matf#30

<JJ> https://w3c.github.io/matf/#success-criterion-2-1-2-no-keyboard-trap

JJ: Some issues around “exit methods” may include the common use of on-screen back buttons for navigation, hardware back buttons, Esc key being standard keyboard command.

JJ: Previous discussions of SC 2.1.2, has been around these exit methods, including relation to assistive technology features, such as VoiceOver’s Z gesture (“scrub”, or “escape” gesture)

<JJ> Do the actions listed for 2.1.2 capture everything needed to draft the content?

<Tanya> +1

<Detlev> +1

<Karla> +1

<Joe_Humbert> +1

<pauljadam> There's no WCAG requirement to maintain focus after orientation change

<Detlev> what about 1.3.2?

Detlev: 1.3.2 is certainly the nearest

pauljadam: The orientation change is simply an example scenario explaining the behaviour, not a failure

<pauljadam> On Input or On Focus can be used if focus is lost during those events

pauljadam: True.

2.4.1 Bypass Blocks

<JJ> w3c/matf#8

<JJ> https://w3c.github.io/matf/#success-criterion-2-1-2-no-keyboard-trap

<JJ> Definition of "set of Web pages / set of software programs" in mobile application context

<JJ> Discussion on defining "view"

<JJ> https://github.com/w3c/wcag3/discussions/286

<Detlev> @JJ are you watching the queue?

JJ: https://w3c.github.io/matf/#success-criterion-2-4-1-bypass-blocks

JJ: 2.4.1 requires a definition for “screens” or “views” in mobile applications to replace the term “web pages”. “Set of software programs” does not seem to apply well in a mobile environment, so “set of web pages” is perhaps a closer fit.

<JJ> Poll: Are we in agreement to replace "set of software" with "set of views"?

<pauljadam> on iOS you can create Containers for VoiceOver which can have accessible names, basically simulating how ARIA Landmarks work

Detlev: Perhaps 2.4.1 is not applicable to mobile apps. Depends on what we consider to constitute repeated blocks of content.

<pauljadam> A collapsable navigation menu is another method to meet bypass blocks

<Joe_Humbert> -1

<pauljadam> I still vote for "Page"

Jamie Herrera votes +1 in Zoom chat

<Jon_Gibbins> +1

<JJ> clarification: replacing software with "view" or "screen" or "page"

<Tanya> +1

<Karla> +1

<Carol> +1

<pauljadam> +1 to Page

<Detlev> +1

<GleidsonRamos> +1

<JJ> Jon_Gibbins: we need a working version for the 'sets of XXX' definition and enhance that as we move forward

<JJ> Jon_Gibbins: Figure out what type of landmarks / semantics we have in Android and iOS to mark containers

<Joe_Humbert> are we going to align with what the larger group decides on the new term?

<JJ> ideally yes, I think it would help if we have our internal version, align that when the definition is finalized in the larger group

pauljadam: We can define named regions of a screen in a mobnile app, providing semantics like ARIA landmarks.

exit