W3C

– DRAFT –
MATF August 20, 2025

20 August 2025

Attendees

Present
Jamie, Joe_Humbert, pauljadam, rachaely, Tim
Regrets
Quintin Balsdon, Steven Hoober
Chair
Joe_Humbert
Scribe
Jamie

Meeting minutes

Project planning update

<Tim> presernt+

Joe_Humbert project planning: asked JJ for a burn-down list of things to get done by end of the year

Joe_Humbert suggesting a prioritty list of what should get done by the end iof the year.

Joe_Humbert shows a list of tasks in GitHub that are assigned and then there are items for discussion. In progress there are currently 9 but 172 to-do

Joe_Humbert

2.5.1 Pointer Gestures

Joe_Humbert plugging help from others to help out more with these ideas

<Joe_Humbert> w3c/matf#37

Joe_Humbert JJ has planned to update the directional movement phrasing which is a task for next time based on previous meeting and remove Note 3. JJ in progress but anyone can help

2.5.2 Pointer Cancellation

Joe_Humbert next date for 2.5.1 TBD

Joe_Humbert summarized 2.5.2 Pointer Cancellation discussion including comments from Detlev and Steven discussing OS behaviors

Joe_Humbert In WCAG there are a lot of exceptions for OS level or browser level things that developers cannot change, /If the OS is doing something and the developers can;t change because it I s part of the technology the expectation would not be that the developers and would not be a violation of WCAG

Joe_Humbert Steven brought up that OS changes, in essence not wanting to exempt OS level items

pauljadam does not see any exception in the wording of the SC itself, do we need this?

Joe_Humbert JJ was thinking about the essential behavior of the OS

pauljadam toggles are examples in iOS that may not be acting as expected such as undoing, but not sure if that fails if you can untoggle?

rachaely Can we discuss the examples of things that would be considered exempt ?

pauljadam not sure we really need to add language about this

Joe_Humbert Looking at Note 2 specifically of WCAG2ICT

pauljadam maybe like a piano app where you need to play on the down event?

rachaely or maybe the pull-down menu or Home Screen app behavior

pauljadam devs don't have control over those items

Tim the essential part seems more about the function, like the piano example, and not necessarily the essential behavior of the OS, that;s code not necessarily a function, so I'm hesitant to think of "essential" as "operating system"

Joe_Humbert if we can't think of things this may be moot

Jamie we might want to consider a phrasing at a higher level like "limitations of the technology" that is more general as that can address the concerns in the Github issue from Steven while not chasing every version of an OS

Joe_Humbert This SC has a lot of Notes, any comments from folks about them? We are ignoring Closed Functionality notes

rachaely points out that Note 6 explicitly added applicability of the OS so that's the exact opposite of what we just discussed.

Joe_Humbert no other notes discussed

2.5.3 Label in Name

@jamie reviewed Accessible Name and Description 1.1 document in WCAG

Joe_Humbert this is tangentially related to the label

Jamie posted some initial notes in Github issue #39

<pauljadam> I would say that the label text is what is shown inside the control with the focus outline shown around that control and text. So if a card does not want all of the text to be the label for the card then it should be separate focused elements and the entire card should not be focused as one element. If the full card is focused as one element then

<pauljadam> all the visible text shown is the label text.

Jamie explained that we needed notes for custom actions and cards with large amounts of text

pauljadam cards could be separated into the interactive area and non-interactive

Joe_Humbert "contains" could be include the text but not all text

pauljadam definition of contained actually means all the visual text is contained in the accessible name

rachaely agreed

pauljadam should ew acknowledge that Voice Control needs to match?

Joe_Humbert iOS specifically adds the ability to provide alternative ways for Voice Control users to access content

rachaely would it be a good note to acknowledge that the best practice is best specifically for Voice Control?

Joe_Humbert we could emphasize the best practice as elevated for voice users

rachaely editing that note it adding an additional note could be good. Android API 36 for "supplemental descriptions" is coming out

Joe_Humbert Getting close to Android alternative for aria_describedby

@Jamie will update the notes as posted in the Github issue #39 and further review edits to the current WCAG2ICt Notes

Joe_Humbert looking ahead to next week's discussion and summarizing comments on Voice Control testing I missed

<Joe_Humbert> In my own testing iOS Voice Control for "Show Labels" now only shows the first word of the accessible name and only requires users to say that first "word". In addition iOS has a feature to allow alternative phrases to be used by Voice recognition users, but as Paul points out this is a separate attribute apart from the accessible name

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Active on IRC: Jamie, Joe_Humbert, pauljadam, rachaely, Tim