– DRAFT –
MATF 26 March 2025

Outcome: WCAG2Mobile Call For Consensus (CFC) in AG WG

<JJ> w3c/matf#104

<JJ> https://github.com/w3c/matf/discussions/103

JJ: CFC passed with some comments as discussed last week. One further comment came in after CFC which has been added to the issue queue.

<JJ> w3c/matf#100

JJ: will work with Kevin to finalize light editorial changes and publish our First Public Working Draft

ACTION: Add comment in index.html that it is auto-generated

JJ: Publication will be accompanied by a news item on the W3C's news page

<hdv> just excited!

<hdv> well done all!

No questions, just congrats all around!

2.5.1 Pointer Gestures

<JJ> https://w3c.github.io/matf/#success-criterion-2-5-3-label-in-name

JJ: Continuing from last week's discussion. Summarizing notes added in WCAG2ICT. Note 4 in particular seems to cover some of the conversations we've had before, like pull to refresh or more complicated screen reader gestures.
… Seems like WCAG2ICT covers most situations, but we might need a note to clarify some of those platform-level gestures (pull to refresh for example)

<JJ> Poll: Apply 2.5.1 as written, emphasizing Note 4: "This requirement also applies to platform software, such as user agents, assistive technology software, and operating systems. Each layer is responsible for its own pointer actions only, not for those in an underlying layer."?

<julianmka> +1

<GleidsonRamos> +1

<AlainVagner> +1

<pauljadam> +1

<RacheleD> +1

<Tanya> +1

<Karla> +1

<quintinb> +1 - do we have a definition of "underlying layer"?

<Joe_Humbert> -1

<Illai> +1

<Jamie> +1 with possible note for custom actions

JJ: "Underlaying layer" means "software or operating system"

<pauljadam> You can add a button to refresh

@Joe_Humbert: Worried about requiring devs to deal with shortcomings of the OS.

<quintinb> +1 pauljadam - any programmatic action can be invoked on their own layer

<pauljadam> it's not required to use pull to refresh and you can easily add a button to do the same thing

JJ: Maybe we need some kind of exception similar to the component discussion for elements that are not changed by the author.
… Are there some instances where native components as-is are accessible by default?

ACTION: Draft 2.5.1, apply mostly as written, consider notes for: "Underlaying layer", "Custom actions", "Native Controls (e.g. Pull to Refresh)"

pauljadam: I have seen this as a challenging SC because people don't tend to like adding a simple tap alternative.

<quintinb> Ask a mobile designer / dev to put buttons on a carousel...

<quintinb> All the space in the world for adverts, but ask for obvious navigation...

<pauljadam> I often have to copy / paste this statement from the understanding doc: Examples of path-based gestures include swiping, sliders and carousels dependent on the direction of interaction

<pauljadam> I've built an example of Carousels in my iOS app that work with swipe gestures only as the bad example and then have single tap alternatives to the swipes in the good example.

<pauljadam> You to Everyone (Mar 26, 2025, 8:19 AM)

<pauljadam> In web pages and native apps you can swipe to go backwards with a gesture but then there is also a back button as the single tap alternative.

<pauljadam> In email apps you can swipe left to mark as read or mark as unread etc but you can also tap buttons to do this without swipes.

<julianmka> +1 to quitinb

2.5.2 Pointer Cancellation

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

<pauljadam> The native Toggle switch controls on iOS fail Pointer Cancellation success criterion. There's no way to cancel the down event.

JJ: Summarized SC - focus on down- and up-events (originally mice, but also now apply to touch events). Similar to 2.5.1, authors are only responsible for actions within their own content, not OS-level actions.
… WCAG2ICT does the same wording replacements as 2.5.1, including "underlying sofware"

<pauljadam> If you make a custom toggle it will pass but that's because it works more like a Button

<pauljadam> Apple needs to fix it

JJ: To Paul's point, that raises the issue again that devs are responsible but not always able to adjust native control behavior (e.g. toggle switch in iOS)

pauljadam: I woudln't give an exception, I would fail an app on this SC but as a platform defect that Apple needs to fix.

<Joe_Humbert> I think we might need a wider exception for native un-modified control

JJ: We've talked about this a few times where controls don't work right but devs can fix. If we keep giving exceptions, platforms will never improve.

<Jamie> wouldn't this apply to web as well, whether native html or other?

Illai: I wonder if this fell between the cracks or was ignored intentionally because checkboxes in the web also use the down-event

<pauljadam> The way I apply WCAG to mobile is that everything that can be applied is applied like heading levels, if a developer uses a native toggle control they may still be failing WCAG, it's just that Apple is the developer causing the fail. I would not give blanket exceptions for native controls.

JJ: This SC only requires one of the listed things to be true, or it can be argued that functionality is essential.

Jamie: Was thinking about whether custom actions might also be covered in 2.5.2? Would we need to include a note in this SC if we add one to 2.5.1?

ACTION: Make sure notes between 2.5.1 and 2.5.2 are consistent

<pauljadam> Accessibility Actions can't be activated by single pointer taps though. They only work with VoiceOver, Switch Control, Keyboard, Voice Control.

JJ: Only offering custom actions would still fail one of the pointer SCs.

Tanya: Re checkbox or toggle -- for the Abort or Undo requirement -- Does the abort/undo requirement mean that the SC would be passed if the action can be undone, as with a checkbox that the user checks and then unchecks?

<pauljadam> ok so because the toggle is done on the down event then abort or undo would not apply

<pauljadam> yes

JJ: Depends on how you interpret the "Or" in the Abort/undo statement. Do both clauses need to be true?

<pauljadam> So native SwiftUI Toggle still fails

<pauljadam> "and" is pretty clear

julianmka: Perhaps we should ask the AGWG about the correct interpretation of the abort/undo clause

Illai: I think we're being a little too puristic here -- I think the SC is referring to actions that really can't be reversed, like submitting a form.
… checkbox behavior could also be governed under on-input

ACTION: Get clarification from AG WG on 2.5.2, "Abort or Undo": 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; --> How does this work for checkboxes and radio buttons that get activated on down event?

<pauljadam> no exception, apple needs to fix their bug

JJ: Seems like this SC mostly applies as-is. We need to keep consistent notes between this SC and 2.5.1. There could be some exception for native controls but we need to think more about that.

ACTION: Create draft for 2.5.2 after receiving clarification on the "Undo" functionality

2.5.3 Label in Name

<JJ> https://w3c.github.io/matf/#success-criterion-2-5-3-label-in-name

JJ: Reviewed the SC language and defined terms. Key idea -- element has a visual label made up of text or images of text, so the accessible label must contain the same text programmatically. Important for voice users and screen reader users who have some sight.
… Original SC note recommends using the visible label text at the beginning of the accessible label.

<pauljadam> I've seen testers trying to use Voice Control to test for label in name but you can only test for this SC using VoiceOver or Xcode Accessibility Inspector. For one, now Voice Control only shows the first string of a .accessibilityLabel OR a .accessibilityInputLabels and if there are .accessibilityInputLabels then the .accessibilityLabel will NOT

<pauljadam> display to VoiceOver.

<pauljadam> *sorry I meant not display to Voice Control

<JJ> w3c/matf#39 (comment)

<pauljadam> I can't edit my messages like Slack :(

JJ: In Github, Detlev points out the challenge of grouped content which has an accessibility label applied the whole group -- e.g. cards.
… Detlev also brought up use of custom actions where the visual label isn't included in the accessible name.

<pauljadam> If you for example make a card a single focus point using Accessibility Actions then all that visible label text in the card needs to be the .accessibilityLabel or it would be a fail.

<quintinb> So do we need to add a note for grouping?

<quintinb> +1 pauljadam all visible text should be spoken

pauljadam: Describes an example in his iOS techniques app with a card where all content is grouped and all content is included in the accessibility label.
… You also can't use VoiceControl to test for this SC

<pauljadam> Well you can use Xcode Accessibility Inspector without needing source code access

<pauljadam> There is no accessible description property in native apps LOL unless you consider the Hint :)

Illai: We need to make a distinction between the name shown and content that describes it. In web, we have aria-described by which allows supplementary content to be included but not made part of the name semantically

JJ: No similar technique in iOS. For Voice Control, you could also set accessibilityInputLabels to something shorter

<JJ> https://www.w3.org/TR/accname-1.2/

Illai: This is taking it too literally. All of the text cannot be considered the single name.

<pauljadam> if you don't want to speak the entire card as the .accessibilityLabel then don't combine its focus into a single element.

JJ: Key idea in Detlev's question -- nested content where multiple controls are available and exposed through custom actions.

JJ: I shared a link to the label/ description computation rules for web. This is a big difference between web and mobile.

pauljadam: Combining focus is not required, you can keep card content separate from its actions.

<pauljadam> Voice Control will never show the full accessibility label

Jamie: 2 thoughts -- 1: About focus on an entire card, there are many scenarios where a card has a lot of text and that's the actionable thing. It's not ideal to have that all announced as the label, but it happens a lot in apps today. There's no way to separate the actionable part of the card from the descriptive content. I get questions about

this in my work a lot.

2: Also wanted not to dismiss Voice Control scenarios from this discussion since the wording of the SC doesn't exclusively discuss screen readers as the only impacted assistive technology. We haven't covered use cases for including voice commands.

ACTION: Add note to clarify the requirements for Name for grouped content (and nested controls with 1 touch target)

JJ: Closing idea -- how do we want to handle SCs which we have closed/completed for the first draft that get reopened or need further work?
… will think about it with the editor group.

<quintinb> Thanks julianmka for scribing!