– DRAFT –
MATF 12 February 2025

<JJ> Any volunteers to scribe?

WCAG2Mobile update

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

JJ: asks for folks to check if their name and affiliation is correct in the WCAG2Mobile document

<JJ> PR for key terms: https://github.com/w3c/matf/pull/96/files#diff-55b5bad7ce674a1ccf6bf170c295dd26f0e8693288f424cbd939ae7ee81f4e99

JJ: is going over the new changes and differences with Guidance on Applying WCAG 2.2 to Mobile document vs past document

JJ: can folks take a look at the pull request, add draft key terms section

https://github.com/w3c/matf/pulls

JJ: asking if anyone has questions or comments on this process

<JJ> Poll: publish WCAG2Mobile as First Public Working Draft?

<jeroen> +1

<Karla> +1

<Illai> +1

<Tanya> +1

<Tori> +1

<jeroen> +1 for Jamie

<AlainVagner> +1

<Joe_Humbert> +1

<Aash> +1

<RobW> +1

JJ: poll closed, moving on

ash: is it ok to share with other folks?

JJ: prefer to wait a bit to share because it looks official now

RobW: what is the reason this group is separate from WCAG-2ICT?

JJ: WCAG 2 ICT is not enough related to mobile apps but we need to align to WCAG 2 ICT but MATF applies only to iOS and Android native apps

<JJ> https://matf.to/slack channel #matf

2.1.1 Keyboard

JJ: WCAG 2 ICT includes desktop software, kiosks, e-reader, etc.

JJ: need to discuss how we deal with keyboard interface, switch control, voice control etc.

JJ: note from Tanya saying sometimes we test apps that are operable with a keyboard but not with a screen reader, what SC would this fail

JJ: note from Tanya, if a user is trapped with the screen reader would that fail a WCAG SC?

<Tori> I definitely have thoughts, but I feel like it requires further research. I think it's a reason to put it out there and get public feedback.

Paul: if screen reader focus is trapped you could fail reading order if keyboard focus is not trapped, if keyboard focus is trapped you can fail keyboard

JJ: if something is not activated with double tap with screen reader what does that fail

<Tanya> related issue: w3c/matf#81

Illai: on web it's referred to as keyboard because of HTML how it works

JJ: folks using a keyboard are often using screen reader to navigate

JJ: are we using only one AT at a time for testing or multiple? like screen reader and keyboard

JJ: could be screen reader, voice control, keyboard, what are the exceptions for testing

Joe: can't use screen reader without keyboard on desktop without difficulty

Joe: issue with screen reader would show up on mobile device and desktop, is this specifically a VoiceOver issue

Joe: when you see screen reader issue under keyboard it also affects desktop version as well

JJ: compare testing with screen reader without a keyboard to find difference

JJ: on flutter if you want to use external keyboard you have to switch off full keyboard access but if full keyboard access is on then flutter app does not work

<Joe_Humbert> that seems like a problem for that Flutter issue

Illai: could be difficult to determine all combinations of AT to use for testing

<JJ> Non-inteference section: https://www.w3.org/TR/WCAG22/#cc5

Tori: wondering if there are notes that could be added about supporting other assistive technologies referencing 5.2.5 Non-interference

JJ: if someone is using WCAG EM to audit they would need to write down all the AT used

JJ: when keyboard interface is mentioned then could say accessibility interface

JJ: when keyboard is mentioned that means hardware keyboard

<Tori> +1 to maybe updating just the keyboard interface definition, but it would need to be tight

pauljadam: usually if an element is VoiceOver operable then it will be keyboard accessible

<Joe_Humbert> one sec, phone call

JJ: limitations of cross platform frameworks

Tanya: cross-platform flutter apps has lots of keyboard a11y problems, on flutter you have to turn off full keyboard access, if they have a native camera then you do need full keyboard access on, can we reject this because it's not modified by the author, it's native, but for end user it's not usable at al

Tanya: look at intent of SC for web to see what users this is meant for on the web to apply to mobile apps

Tanya: when we test we use 1 AT rather than combinations

pauljadam: some combinations used together could be VoiceOver and Screen Magnification for Low Vision users who want to see and hear the UI

<Joe_Humbert> ready

JJ: flutter issues with full keyboard access needing to be off

Joe_Humbert: on desktop screen reader and keyboard are tied together because most use keyboard and screen reader. should we propose keyboard and touch because touch is the main input for touch devices

JJ: would expansion of keyboard definition lead to problems or not

JJ: hoping folks will read broader than just keyboard and screen reader

ACTION: Look into Conformance section adaptions for Mobile Applications

Tori: great we care to solve problem but most places have laws where disability discrimination is less about WCAG and more an person access this yes or no so we may not need to solve for this because there may be other mechanisms to get other AT supported

<JJ> Poll: Replace "keyboard interface" with "accessibility interface"?

JJ: poll to replace keyboard interface with accessibility interface

<Illai> +1

<Joe_Humbert> +1

<Tanya> +1

<Karla> +1

<AlainVagner> +1 for Jamie

<AlainVagner> +!

<Joe_Humbert> +1 FOR jAMIE

<AlainVagner> +1

<Tori> +1 BUT only if we have a tight definition of accessibility interface

<Carol> +1

<pauljadam> -1, don't want to change WCAG Keyboard to something else

<Illai> +1 to Tori's comment

<jeroen> +1

Jamie: should have a definition ready for accessibility interface

<Zakim> Tori, you wanted to discuss Jamie (can't access IRC)

ACTION: Create "accessibility interface" definition

2.1.2 No Keyboard Trap

JJ: moving to no keyboard trap SC discussion

<Tori> I'd prefer something like "All functionality of the content is operable through a keyboard interface //or the standard mobile input// without requiring specific timings for individual keystrokes..."

<Tori> It needs a lot more iterations to get it right, but we need something way tighter if we do this. It needs to focus on the operable part of an accessibilty interface and not be generic

JJ: flutter issues could be flagged under 2.1.2

JJ: keyboard focus using a keyboard interface, keyboard interface could be replaced with accessibility interface and could replace keyboard focus with accessibility focus

Jamie: WCAG2ICT definition different

ACTION: Check why WCAG2ICT does not have Non-Interference section

JJ: WCAG2ICT removed conformance requirement 5 and replaced the word page with non-web document or software

<Tori> +1 to add back in Section 5 of WCAG

JJ: note 1, note 2 exit methods escape key, note 3 focus/keyboard traps

JJ: how well known to standard exit methods need to be known, e.g., android back gesture, iOS Z gesture

JJ: should this group address these exit gestures

JJ: long press not keyboard shortcut

<Joe_Humbert> switch access has a go back command

JJ: does there need to be visible exit button or do standard exit gestures work

ACTION: Add examples of accessibility interface exit functionality (Escape, "Go Back", Z-gesture, etc.)

pauljadam: want to build good bad examples of these

<JJ> w3c/matf#30

JJ: see if there are any comments on github

JJ: or move on to other SCs until we made a decision on keyboard and keyboard trap

Jamie: should be list keyboard interface definition issue

Jamie: need to different between SC that use just keyboard or keyboard interface

ACTION: Add SC's affected by "keyboard interface" to the issue for the definition - Jamie

JJ: double check open PR in GitHub

<JJ> Thx for scribing pauljadam.

<JJ> PR: https://github.com/w3c/matf/pull/96/files#diff-55b5bad7ce674a1ccf6bf170c295dd26f0e8693288f424cbd939ae7ee81f4e99