W3C

– DRAFT –
MATF 4 June 2025

04 June 2025

Attendees

Present
Aash, Carol, GleidsonRamos, Illai, Jamie, Joe_Humbert, julianmka, Megan_Pletzer, pauljadam, quintinb, Tanya, Tim
Regrets
Jon_Gibbins, JonGibbins
Chair
JJ
Scribe
quintinb

Meeting minutes

present

I'll scribe

User Agent definition proposal

<JJ> w3c/matf#63

JJ reading the note on issue 63: w3c/matf#63 (comment)

<JJ> A User Agent on a mobile device is currently limited to only software that meets the original WCAG 2.2 definition of User Agent (e.g., a web browser) either used as a separate application (e.g., Chrome or Safari) or used in native mobile application to display web content (e.g., a webview, which uses all or part of a web browser). All other

<JJ> programs or applications(?) would either be defined as Software [linked] or as Platform Software [Linked].

<JJ> "Example: Examples of platforms are: desktop operating systems; embedded operating systems, including mobile systems; Web browsers; plug-ins to Web browsers that render a particular media or format; and sets of components that allow other applications to execute, such as applications which support macros or scripting."

<JJ> The term platform software, as used in WCAG2ICT, has the meaning below:

<JJ> platform software

<JJ> software that runs on an underlying software or hardware layer and that provides a set of software services to other software components

JJ What is software / platform software?

I would have said browsers are user agents

For example: Jetpack compose does control certain elements of focus, i.e. where focus goes after a dialog dismisses. Does that make it a user agent

JJ agrees (yay!)

JJ we could see a user agent (UA) as something that renders something on the screen

Joe_Humbert I think we have to blame Google for the introduction of web browsers of both. For example Chrome OS is Chrome as an operating system. Part of the reason for the definition is that "documents" and "user agent" are ambiguous and make it hard for us to make changes and recommendations to the definitions

<pauljadam> Toggle controls on iOS have below 3:1 contrast in the off state as their default appearance controlled by iOS (or the user agent)

<pauljadam> If the user modifies the appearance of the native control then they are now on the hook to make sure it has 3:1 contrast ratio for non-text content

Jamie How many different success criteria use user agent? Not normally a strategy, but perhaps using this could help us define context for all the scenarios. This would give us more direction. Just thinking about strategy.

<pauljadam> Links on iOS have insufficient text contrast as their default appearance but that is text so there is no exception and you have to correct the default appearance and make it 4.5:1

JJ there are a few, especially the new SC's that make exceptions for user agents

<pauljadam> a page is a document :)

<JJ> https://www.w3.org/TR/wcag2ict-22/#document

Joe_Humbert along with this, the definition of UA in WCAG2ICT they return the definition with reference to "documents" - basically they say it's an "assembly of content"

quintinb goes bald-er

JJ software is not defined in WCAG

<JJ> https://www.w3.org/TR/wcag2ict-22/#software

<JJ> Continue discussion at: w3c/matf#63 (comment)

<pauljadam> Only for non-text content

<pauljadam> text has no exception

<pauljadam> It's not where they don't have control it's where they leave it as the default appearance.

Jamie we need to be clear in the definition, we need to get into the weeds. In the context of normative text, it seems that it's trying to define where control exists relative to authors, and does it need to be more complex than that

<pauljadam> iOS user agent = iOS itself

<Tanya> is this something we can use - https://www.w3.org/WAI/fundamentals/components/

<JJ> user agent: "any *software* that retrieves and presents *content* for users" where software can be a framework like jetpack compose, a web browser, or a webview and content can be web content, a document, or native UI

We do need to be careful around User Agent in mobile because creators do need to take responsibility for their choices. If react native doesn't support keyboard accessibility, they must fix it

(the creators, not React Native)

<pauljadam> software = the iOS app, user agent = the iOS operating system itself

<JJ> https://developer.android.com/guide/platform

2.4.2 Page Titled

<JJ> https://w3c.github.io/matf/#success-criterion-2-4-2-page-titled

<pauljadam> Page Titled is a good reason to all things pages and not screens or views ;)

<pauljadam> *call

<JJ> Related WCAG2ICT issue: w3c/wcag2ict#627

Yeah I don't see that flying on mobile. The definition is going to be hard. e.g. Android + Fragments

And apps are announced by the OS

Oh my super met JJ

*meta

<pauljadam> on iOS the page title is visible at the top of the page and spoken with a "heading" trait

I think dialogs should have a heading

<pauljadam> https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/Documentation/PageTitles.md

<pauljadam> Use .navigationTitle to create a title for each page.

Illai A few thoughts: The intent behind this is to provide context to user. From web, you might land up there "randomly" - does mobile have the same necessity. Is it enough to have text (invisble or not) to provide the same experience. Would that be a solution?

<Zakim> julianmka, you wanted to say that if a screen or view can support a semantic title, it should have one

julianmka it can definitely get fuzzy

ACTION: Take components into account that do not have the capability/API to display title

ACTION: Think about semantic requirements for identifying titles?

<pauljadam> I would have no if statements, simply require a page title and if they don't have one then it fails the SC

<quintinb> +1 pauljadam

<pauljadam> dialogs are not pages

<pauljadam> dialogs need headings

"Pages need to have a title" - ship it!

Joe_Humbert By title - do we mean visual title?

<JJ> "Pages have titles that describe topic or purpose. "

<pauljadam> .navigationTitle property

Visual and sematic, right?

*semantic

<pauljadam> I'm not sure if we should address fake titles or not, I'd leave it without discussing that

<pauljadam> Maybe a tester wont know if the page title is a fake title or a .navigationTitle and maybe that's fine

<Joe_Humbert> +1 to visual title fore all "views" or whatever term we settle on

<julianmka> +1

<pauljadam> yes I see fake traits in the wrong places 🤦🏻‍♂️

ACTION: Differentiate between "visual" title and "semantic" title, perhaps require visual title and suggest semantics as best-practice

<Joe_Humbert> at least on iOS you can check traits if you have both and iPhone and Xcode

<Jamie> +1 Joe_Humbert

2.4.5 Multiple Ways

mmm views..

<pauljadam> on iOS a11y inspector won't tell you if it's a .navigationTitle, it would only say if it's a Header which could be a normal heading.

Oooh congrats Jan Jaap!

<Joe_Humbert> congrats!!

<Aash> congratulations! JJ

Summary of action items

  1. Take components into account that do not have the capability/API to display title
  2. Think about semantic requirements for identifying titles?
  3. Differentiate between "visual" title and "semantic" title, perhaps require visual title and suggest semantics as best-practice
Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Active on IRC: Aash, Carol, GleidsonRamos, Illai, Jamie, JJ, Joe_Humbert, Jon_Gibbins, julianmka, Megan_Pletzer, pauljadam, quintinb, Tanya, Tim