– DRAFT –
MATF 29 April 2026

2.4.2 Page Titled updated proposal

presnet+

<Detlev> Agenda: Page titled, label in name usw. (see agenda)

<JJ> w3c/matf#9 (comment)

JJ: First item page titled - proposal from Tanya
… biggest difference: page instead of web page

JJ: A note clarifies how title can be supplied (in difference to web)

<pauljadam> +present

JJ: not updating this anymore
… before submission of new draft

JJ: Tanya commented

<JJ> Updated proposal by Tanya: w3c/matf#9 (comment)

JJ: She has removed "when phyiscal title is not feasible"
… heading requirement removed (would fall under 1.3.1)

JJ: (reads from issue on page titled)

JJ: note on should / must usage

<pauljadam> Should it say a "selected" tab instead of a "highlighted" tab? I get the meaning either way.

<pauljadam> or it's not that the tab is selected each page has a tab and you can see the tab title

JJ: agrees "selected" might be clearer

pauljadam: but you see the text of unselected tabs so it may not be clearer

JJ: will read "should be provided" - but "must be specific"

JJ: question if it can be invisible

<pauljadam> could say "a page title is provided through visible text"

shoobe01: shows position in the system - highlighted tab

<pauljadam> All of the page title examples we used are visible

<JJ> "active" tab instead of "highlighted" or "selected"

shoobe01: selected implies action, highlighted is better therefore

<pauljadam> But just having a tab that has a title on the tab button makes the tab have a visible title. The user could think the title of the tab is the title of the page unless you provide another page title on the page then it might be seen as a sub page of that tab.

<Sam-Estoesta> 1+ to active

JJ: most apps shoulf be able to comply b yhaving some visible text - so that could become a must?

<pauljadam> If you call it a dialog then it is not required to have a page title but if you call it a page then it needs a page title.

how to exempt views that are interim steps?

JJ: through page definition that might exclude those modal views or steps

JJ: ...if part of a flow that would probably be sufficiently exempted

<JJ> Poll: do we write "must" to require the page title text to be visible, or keep "should" meaning it is recommended to be visible?

Detlev: so now clear fail if it is invisible?

<pauljadam> must

should

<shoobe01> must

<pauljadam> if you cant see the title then there is no title :)

<Sam-Estoesta> must

<pauljadam> that's why having good and bad techniques / examples are important, like show us a good example where a page title is not visible ?

JJ: Web content could be difficult - like in webviews that have title but are invisible

<pauljadam> But there are probably not any browsers that don't show the page <title>

<pauljadam> That's a container title not a page title.

JJ: we don't have title attribute - it might not be visible

JJ: a web view title would nob (generally) be visible

<pauljadam> good example that would fail if you don't add a visible title to the web view inside a native app

<shoobe01> We're getting back to the problem of not being able to define what a Page is again. Webview, dialog, overlay, panel, drawer... which need a title? May not be solvable because of this limit to our scope

<pauljadam> Often the terms and conditions page is in a web view in the app so that page would need a visible title that usually would be the H1

JJ: it title is not visible, is it reasonable to mandate visible title of a webview?

<pauljadam> Luckily most pages need a H1 so that usually is the visible title too :)

JJ: Most voted for must - but there might be edge case that we have missed

2.5.3 Label in Name updated proposal

<shoobe01> Have had issues of embedded webviews, both two titles and screenreader not properly interpreting H1 in the webview as only title etc. It's fraught.

JJ: both should and must might work - need to look at survey results

<JJ> Label in name proposal moved to next week

JJ: HAd no time to look at 2.5.3 move to next week

<JJ> w3c/matf#14 (comment)

<pauljadam> screen reader in a web view will read the <title> as the title, the visible title or heading text would be read as a heading

JJ: We have draft from Tanya and feedback from shoobe01

<shoobe01> The end of my notes has proposed revision text.

JJ: repacing web page with page
… we need a note for auditors to check the default language of an app
… need the screen reader to check whioch speech engine is used

JJ: (reads from 3.1.1 draft)
… feedback from Steven

<JJ> w3c/matf#14 (comment)

shoobe01: need layers model to show how locale language is inherited

<pauljadam> I updated the Language.md docs explaining how to use locale on iOS and added a language of page good bad demo https://github.com/cvs-health/ios-swiftui-accessibility-techniques/blob/main/iOSswiftUIa11yTechniques/Documentation/Language.md

shoobe01: you could shange language on a page even though it generally applies to whole app

JJ: language is set at the platform level, apps inherit that
… if OS language is not used by app, it needs to be overwritten to use its own language

<pauljadam> Could mention that you set the language of page using the correct Locale during your localization process or something like that.

shoobe01: You can change language for one page but you should better do it the right way

<shoobe01> pauljadam I tried to say this in the proposal "In mobile applications, the language is typically set at the platform (OS) level as part of the localization service" unless I am missing some nuance

<pauljadam> You could make a bad app example by creating it with the wrong locale that is different than the language text the screen reader is focused on. Like if I say the app Locale is Spanish but the text is English then it will speak with a Spanish accent.

JJ: not all screen reader (Android) use the right language - case: content in Dutch, role set to button, translated term (Knopf) pronounced in English

<pauljadam> That's one thing the Locale also does it makes an element's trait like "Heading" say whatever that word means in the set language. So it won't say Heading.

<shoobe01> Was gonna go queue plus to say what pauljadam just typed. It isn't gonna read in english, but try to read what is on screen from the english reader. It is BAD.

JJ: one way to set a female voice for the local language and a male one would render things not localized

<shoobe01> +1 on "it's not hard!"

JJ: Normally the language is set just once at the app level

shoobe01: The app will not support any language - do we care about that problem - say, if local is not supported and the app falls back to english

<pauljadam> If the app shows English text then that text needs the language set right for the screen reader.

<pauljadam> programmatically setting the language

2.5.3 Label in Name updated proposal

JJ: na check WCAG to be consistent with usage

JJ: dragging movements is the next one

<shoobe01> Transcription has looked good to me. I have been following and not found anything needing correction Detlev. Thanks for interpreting my firehose of talking :)

JJ: Detlev question why should we change it

2.5.3 Label in Name updated proposal

shoobe01: Did not like the term "single pointer"

<JJ> https://www.w3.org/TR/2024/REC-WCAG22-20241212/#dfn-single-pointer

Detlev: ..single pointer does not apply to the action

JJ: looks at WCAG single pointer definition

shoobe01: pointer sounded as if it was inherited from desktop / mouse

<shoobe01> (and I am talking super fast again....)

shoobe01: not good case to deviate

JJ: move back to single pointer

JJ: exception for "deteriming by the user agent - describe natively supported dragging movements in mobile context

shoobe01: JJ had a comment - should we have a note?

JJ: the WCAG note is already there
… may not be necessary

<Sam-Estoesta> Best practice for policy writing is to use references, so link would suffice here.

ACTION: Consider adding note to 2.5.8 to clarify single pointer for mobile app developers

<shoobe01> afk

ACTION: Include examples for 2.5.8 with dragging movements taken care of by the platform

<shoobe01> rtk

<JJ> Detlev: explains the needs auditors like himself would need for this SC

<pauljadam> Native iOS List view that is recordable is not accessible to single pointer taps

Check OS supported methods for dragging, reordering etc - where it uses native drag-n-drop

JJ: provide examples of native patterns that would be exempt

<JJ> w3c/matf#52 (comment)

JJ: Feedback in last week's meeting was that SC is ready for draft - wemay add a third note but last week indicated we can leave out note 3 so we can keep it the way it is

<JJ> https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum#intent

JJ: has exceptions for repositioned content, and for things explictly brought up by user

JJ: can be applied as is

Joe_Humbert: SC already in first draft - was brought back because people had questions about it

JJ: Based on last week, we should close this one.

ACTION: Close issue 52 for SC 2.4.11 - it is already in the draft using the same text as discussed in recent meetings

JJ: no comments... will close issue.

JJ. Will work on SCs in the agenda, then move on to software layers and possible deviation for target size

larger target size may just remain a note pointing to OS recomms

<shoobe01> Agree, I read the transcript and minutes to assure I didn't miss anything and it looked good today!