Meeting minutes
POLL: Do you agree the focus of this group should be about applying WCAG to native mobile apps?
<Joe_Humbert> POLL: Do you agree the focus of this group should be about applying WCAG to native mobile apps? +1, 0, -1
<Tanya> -1
<Megan_Pletzer> +1
<Jon_Gibbins> +1
<rachaely> +1
Joe_Humbert this is not a binding poll, just taking a pulse
Tanya given discussion from last meeting, it doesn't sound possible to focus on native mobile apps only. we should focus on creating notes that will apply to native mobile app, cross-platform apps, etc
Joe_Humbert our decsions shouldn't be swayed by expection from W3C. same problem exists for WCAG2ICT more broadly for software. we have a cause to say our work is more about native mobile than web
from Jamie not in chat: our time here in the meeting should focus on content related to non-web environments like iOS and Android. at some point we should review how conversation apply in a web app context
<Jon_Gibbins> rachaely: Just noting that the above comment quotes me (Jon_Gibbins) rather than Joe_Humbert :-)
Page definition (Continued discussion)
<Joe_Humbert> w3c/
Joe_Humbert Jon remove comment with definitions we discussed at last meeting
Jon_Gibbins comment is likely hidden in history because there are so many comments, so it collapses them, but i can't see that now.
<Joe_Humbert> https://
Jon_Gibbins didn't intend to delete the comment, will look into what happen
<Jon_Gibbins> Somehow the link URL us garbled in the meeting notes – it should be w3c/
<Jon_Gibbins> The meeting notes from last week’s meeting has a stray close paren, i.e. w3c/
Joe_Humbert detlev added comments based on last meeting's minutes with concerns about definitions in broader group
<Jon_Gibbins> The comment itself is still there.
Joe_Humbert Jon provided additional comments on the definitions
<Joe_Humbert> Proposed definition from Jon_Gibbins: an embedded resource in a native mobile app plus any other resources that are used in the rendering or intended to be rendered together with it by a platform (or user agent)
Jon_Gibbins not much to add beyond what's added in github. i posted pros and cons for us to consider not just now, but also later. we can have a working definition now and come back to the pros and cons to make sure everything makes sense in context. i think we need to make a decision to move forward with
Joe_Humbert you changed from non-embeded to embed, can you explain?
Jon_Gibbins web pages are displayed in a browser, whereas mobile is part of the software itself
Jon_Gibbins we are talking about screens that are embedded as part of the software of a mobile app
Joe_Humbert i think we need to settle on something for the time being. i wonder if we can put it in brackets for now and decide later we can replace if we want
from Jamie not in the chat: we feel kind of stuck in the details, but maybe we can move forward in some actions. we need to be specific to make a definition that work, but for the time being, i think Joe's suggestion is good for now. we can refer back to discussions on this later. how can we keep moving forward?
Joe_Humbert let's see which SC use the term "web page"
Jamie not in chat: maybe we should look at a few of them and see how the proposed definitions fit for the normative text. bybass blocks is one that may be affected by the different definition. just something, so we can move forward
<Jon_Gibbins> +1
Joe_Humbert proposing temporary term of dropping "web" so we would just have "page" and "pages". can we use this as a placeholder?
<rachaely> +1
<Tim> +1
<Tanya> +1
<Joe_Humbert> SC that include term web page:
<Joe_Humbert> 1.4.2
<Joe_Humbert> 2.3.1
<Joe_Humbert> 2.3.2
<Joe_Humbert> 2.4.1
<Joe_Humbert> 2.4.2
<Joe_Humbert> 2.4.3
<Joe_Humbert> 2.4.5
<Joe_Humbert> 2.4.8
<Joe_Humbert> 3.1.1
<Joe_Humbert> 3.2.3
<Joe_Humbert> 3.2.4
<Joe_Humbert> 3.2.6
<Joe_Humbert> 3.3.4
<Joe_Humbert> 3.3.6
Jamie verbally agreed
ACTION: use temporary term of [Page]
<Jon_Gibbins> I feel that the appropriateness of whatever definition we choose to go with for now will “come out in the wash”. We will see if something works well enough, and if it does not, we vote to change it again before we publish our next draft.
Joe_Humbert if you are good with definitions proposed by Jon, please thumbs up in GitHub, so we can move forward with these
ACTION: Joe to add definition from Jon_Gibbins for a thumbs up in GitHub
Tanya question to check if i'm following. let's say what is stated in the absrtract stays as is, that our guidance applies to native mobile apps and web apps. how will the new definition apply? will it be added as a note in the draft?
Joe_Humbert like WCAG, we will have a list of definitions. the definition for web page will remain as is. there will be a new definition for the new term, temp name page. then there will be a higher level section describing where the new definition applies.
Tanya so the new definition would apply to mobile web apps if the abstract remains as is?
Joe_Humbert yes, but the abstract may change. we could say mobile web apps are not governed by this doc. not proposed yet, but a future discussion
4.1.2 Name, Role, Value
<Joe_Humbert> w3c/
Joe_Humbert this has been discussed and has tasks for adding notes on roles and states, custom actions, and standard user interface
Joe_Humbert discussed in March 202
2025
Joe_Humbert read out 4.1.2 SC and for WCAG2ICT there are some notes. first one basically modified it to be less web specific and more software specific. not sure if we need to change that note.
how do we consider on Android the "double tap to activate" in relation to the role?
Joe_Humbert this hint content may pertain to the role, but if the user can turn it off, maybe we need to acknowledge that some of the role may be missing
rachaely my understanding is the hint can be turned off for iOS which is additional descriptive content. my understanding in Android hint is the "double tap to __" announcement not controlled by the user
Jamie when it comes to standard user interface components because for example, a native button may not announce button, but instead "double-tap to activate"
Joe_Humbert verfied that user can turn off the usage hint. Android has both the ability to add a role for some things, but also uses this usage hint for more general active controls
Joe_Humbert what i've seen is that people are meeting the spirit of the success criteria
<Jon_Gibbins> The way I’ve understood Android’s behaviour for buttons is that if the context is clearly navigation, e.g. selecting from a list of actions, the role of ‘button’ is not announced (and I guess is assumed by users). Where buttons exist in a context with mixed roles, “button” roles are announced.
Joe_Humbert problematic parts in the normative text that may need to change is "including but not limited to: form elements, links and components generated by scripts". the different definitions can change how this SC is viewed even if we don't change normative tesxt
Joe_Humbert does anyone have things they'd like to see change with the normative text other than the definitions?
Jamie what catches me off guard with a note referring primarily to how authors create, it's not just the author, it's calling out issues with standard interfaces. the note in WCAG2ICT is a topic we need to firm up our decision that standard user interface are accessibile as is in a native app context. we've discussed this and that it's not the same
as web, and is inconsistent in some spaces. looking at the scope of the SC, this could change that. since we have actions in the queue, if they are unassigned, i am open to taking them but maybe others on the call are too, so we can move forward on this
<Jon_Gibbins> As Jamie says, the role announcement behaviour could be considered expected platform behaviour for users, and out of the control of content authors.
Joe_Humbert WCAG applies to the people building apps, so if they have limited control of what they can change with standard controls. if it is an issues with the base component and the developer hasn't changed it, that is a bug to be filed with the platform Apple or Google
Tanya we have a new setup to discuss with Jan Jaap and probably will propose to group in 2 weeks
Joe_Humbert don't wait for the new process to voluntarily pick up a task
Tanya in audits, we don't always know what was used to build the app. we have one tester who does both iOS and Android who doesn't have a development background. so we should provide methodology that should apply to both regardless of native or cross-platform
<Tim> +1 to what Tanya said
Joe_Humbert i'd love feedback from the group, in later versions of iOS 17 and 18, usage hint is no longer provided for role button
<Joe_Humbert> close the queue
i've noticed this, i couldnt narrow down when the change happened, but i also remember iOS announcing "double-tap to active" more than it does now