Meeting minutes
<JatinV> Regrets, I need to miss today's meeting due to axe-con 2026 commitments!
<JJ> Thanks for letting me know!
<JJ> And good luck at axe-con
<JatinV> Thanks!
Software Layers
<JJ> Miro board: https://
<JJ> https://
@Tanya: I think it's clear - But what needs to be made clear is where we put responsibility. In WCAG2ICT, they make User Agent more broad. Where does framework software fits is not clear to me. Are we adding excemptions for react / flutter? I don't think that was the initial idea. We need to either introduce a different definition or what will be
included
This is your semi-automated reminder to double check the scribe
2.4.2 Page Titled
<JJ> w3c/
<pauljadam> Heading as the page title is the common accepted method for mobile a11y if they're not using a .navigationTitle
shoobe01 I thought we had a descussion that there was a page header.
<JJ> (some of the recent minutes [1-2 weeks] are not yet added to the related GitHub issues)
shoobe01 Pleanty apps don't have this - shoobe01 I'll try find the minutes
Are we requiring that every "Page" have a title?
<pauljadam> I think we define how you make a page title in the techniques but the requirement is the same as WCAG.
<pauljadam> there's no reason why an app can't have a page title for every page
I just opened "ABC Bank" - do I really need a title called "ABC Bank?"
<pauljadam> The page is probably the Login page when you open the bank app
Joe_Humbert: Is on mute
Joe_Humbert: Looking at the definiteion, has the note been added in WCAG2ICT? I'm not seeing it. I agree with what's been said. We're just adding more definitions that aren't commonly defined and that's ambigiuos
<pauljadam> All we need too say is "Pages have titles that describe topic or purpose."
Tanya: Just a comment: What do you mean it's not required by EN? It is required by EN? Is this the application?
Tanya EN also says that if you open the text ... <quotes en>
<pauljadam> window or screen seems different than a page 🤔
<pauljadam> like does window mean a modal dialog or a dialog needs a title?
<pauljadam> isn't the ways to provide a page title part of a WCAG technique and not the SC text?
<JJ> Maybe: NOTE: Examples of **titles** in mobile applications are: ...
Tanya: On the draft note I added: The purpose of the note is to give a general understanding. It's not clear if you should do it the same way on all screens. You cannot identify clearly all the ways. The SC remains a little vauge. The goal of the note is to indicate the broad application of the SC. We can probably make it shorter. I hear that it's
not clear, but the idea was to name some examples, not prescibe them specifically.
<JJ> Good point pauljadam, yes thats https://
<JJ> https://
Joe_HumbertI'll ask for clarity in the note
<pauljadam> well the SC does not say it must be unique
tayef Would it be worth adding in 2.... pages have unique titles? Does a title have to be unique and this would be an important distinction
<pauljadam> just has to describe topic or purpose
tayef as we're discussing potentional revisions, how important is the emphasis on the title being unique
<pauljadam> typically yes unique is needed just not said specifically in the WC SC
<pauljadam> I wonder if something like a TabBar Selected Tab text can serve as a "page title" in a native app?
shoobe01 - it does seem that we need that we should have a note on globally unique name in the best case
<shoobe01> +1 for pauljadam comment. Already noted as something to explicily mention. I do this a lot in day to day work
<pauljadam> Some apps like the Clock have both the Tab and a page title but then on the Stopwatch tab they don't have another page title at the top.
2.4.11 Focus Not Obscured (Minimum)
<JJ> w3c/
<pauljadam> Focus not "Fully" Obscured
If "wiggle room" needed a success criterion
<pauljadam> since the SC wording says "keyboard focus" I would say to keep it to only keyboard unless WCAG goes beyond that in the future maybe
<JJ> Poll: For 2.4.11 Focus Not Obscured, do we only consider Keyboard focus as part of "keyboard focus" and not other assistive tech?
<Joe_Humbert> -1
Can you clarify what -1, 0 and 1 mean in this context?
<quintinb> -1
<pauljadam> 1
<Tanya> -1
<pauljadam> I would wonder why did WCAG itself not say other ATs than keyboard?
In my understanding, Keyboard has been defined as "the interface" in WCAG, not the hardware
<tayef> Are we going to add anything about other assistive tech, if that's the case?
2.1.1
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
So we don't need to trap focus for screen readers in a dialog? That's going to make some developers happy
<pauljadam> It's probably up to the platform os ATs to sort of behave the same way with e.g. a switch control and a keyboard so that when they put keyboard focus on something it works the same when they put switch focus on the element
<Tanya> https://
<pauljadam> I think WCAG expects that if it works with keyboard then it works with the other AT like switch?
<pauljadam> I don't think WCAG requires that you test with every single AT like switch control.
shoobe01: You'[ve lost me - keyboards are not the main inputs for assistive technology. I've alwaysd assumed this was the software keyboard.
shoobe01 I tend to say that for our task force we need to flip hardware vs software input. The primary method is software, and the hardware keyboard is the assistive option
Joe_Humbert I think for mobile apps, we should add to it, not use it as is. We need to add accessibilty interface, the other assisitve services were created with a visible focus indicator. On mobile these are things that was always there. I don't want to change the definitions but I want to add other assisitve techs to the requirement
pauljadam I feel like wcag is written in such a way that it's up to the platform to behave well with the AT. WCAG doesn't require you test with every AT - It's hard enough to do accessibility testing as it is, we should just leave it to the platform
<JJ> https://
2.5.7 Dragging Movements
<JJ> w3c/
<pauljadam> I fell like WCAG saying keyboard focus includes switch focus or other AT focus might be a level AAA or part of a new version of WCAG because that seems like an extra requirement.
<pauljadam> Zooming is under Pointer Gestures and does require the single pointer taps
<pauljadam> Panning the map would be under Dragging Movements and have the same need for controls.
Doesn't this just apply to custom gestures that are added by developers?
shoobe01 Just want to clarify - I differentiate between scrolling, dragging and gesturing - what are we talking about here?
<pauljadam> an exception I found is the iOS Slider Control where you have to drag it and that seems to be allowed because it's a pure native control under the exception
<JJ> https://
<pauljadam> scrolling is not dragging because you're not dragging an element
shoobe01 is scrolling something we need to discuss in the future?
<pauljadam> I always failed dragging under Pointer Gestures until Dragging Movements was released.
<pauljadam> single tap or many single taps
<shoobe01> +100. Anything driven by click OR clicks should suffice
<pauljadam> yes it can be many taps
<Joe_Humbert> need to drop, sorry
<shoobe01> We're never gonna get back to touch target sizes!
<JJ> close the queue
<JJ> shoobe: next week, I promise ;)
pauljadam This has the exception for the user agent. The iOS slider has exception. You can't just single tap. However you could have buttons on either side as required by the wording
shoobe01I wish we didn't give OS's a pass in this case
<quintinb> +1 to not giving OS's a pass
lol @shoobe01
bye