Meeting minutes
<JJ> Joe: mostly sticked to the facilitator script when facilitating the last 4 meetings. Made progress, mostly with group agreement on SC's that apply directly from WCAG2ICT.
<JJ> Joe: WCAG2ICT has a lot of extra stuff added, not all is relevant to mobile, want to keep it as straightfoward as possible
julianmka: `Action` command in IRC was very useful to track action items following decisions
Joe_Humbert: Agendum items with an incorrect name cannot be updated
TPAC update
<JJ> TPAC presentation: https://
<JJ> Add TPAC minutes
JJ: Reviewed deck from TPAC about Views and what that can mean in different W3C docs and in Native apps.
JJ: We came fairly close to defining views, but accounting for exceptions can create challenges. Also, there was agreement that WCAG2ICT's "set of software" definition doesn't really make sense.
JJ: Outcome: New sub-group of the AGWG to define "views" - for both MATF work but also potentially WCAG3 or WCAG-EM.
Joe_Humbert: Do you have sense of how much the WCAG3 definition might change?
JJ: Could change a lot. There are other related terms/definitions in WCAG3 that could be affected, too.
Jamie: What should this group do for a first draft of documentation?
JJ: We can still use our own definition for now, probably "screen." But if there's a unified definition of "view," it could make sense of adopt that in the future.
JJ: WCAG2ICT's original charter prevented them from certain changes, but in the re-charter process for taking up AAA SCs, they might be able to update "sets of software" to "sets of views."
<Mick> If WCAG3 are using 'view' as their terminology should we use 'view' as well instead of 'screen'?
JJ: Seems likely WCAG3 will use "view" so it might make sense for us to use that. But if our goal is to give straightforward guidance, "screen" might be easier for others to use.
Mick: If WCAG3 is going in a certain direction, I think it makes sense to align early rather than have to change.
JJ: They'll probably use "view" because it's broader. We can make this decision later.
JJ: There's conversation in the EN working group about Page Titled. In an upcoming version, Page Titled no longer be marked as void, but it will apply at the software, not screen, level. They'll include the WCAG2ICT note about screen titles as a best practice.
JJ: EN group has also updated Consistent Identification to remove "set of software programs" to "software program."
JJ: EN group also looking at Consistent Navigation and Consistent Help which are a bit more complex.
<JJ> Page Title in EN 301 549: https://
Detlev: About Title requirement, if that applies to software; In an app context, it doesn't seem to make sense to announce the software/app name on every screen load.
JJ: When the app or software is launched, the Title would be announced.
JJ: They want to add a note or change wording to clarify the intent.
<AlainVagner> JJ could it be this issue about Page title? https://
Jamie: Could you show the topics you're discussing onscreen?
<JJ> Reconsidering WCAG-based software requirements omitted from EN 301 549 v.3.2.1: https://
<JJ> Consistent Identification will no longer be Void: https://
JJ: I'm sharing all of these links and discussions from ETSI/EN 301 549 because they're also working through "sets of software programs"
2.4.11 - Focus Not Obscured (Minimum)
<Mick> Is this criteria not very specific to keyboard focus?
JJ: Recaps discussion from the Github issue and recent meeting, found at w3c/
Joe_Humbert: Reason I said this might need more discussion is because I wondered if we needed to replace the word "keyboard" because there are other ATs where this SC is important. Do we want to replace "keyboard" or keep it focused on keyboard only?
JJ: It wouldn't be too hard to conform to this SC if it applied to other ATs
<Mick> I agree we should look at other AT with keyboard. Probably should look at it in mind with SC 2.1.1, SC 2.1.2 and SC 2.4.3
Jamie: If we do decide that it's about keyboard focus only, I think it would be helpful to add a note explaining that.
julianmka: I'm wary of only considering hardware keyboards for this SC. The intent as written in Understanding acknowledges switch and speech recognition.
Detlev: I think the reason for focusing on keyboard is because this SC was intended to address fixed-position content on webpages like cookie banners. While that can occur in apps and web view content, it might not be the exact same. If elements are not visible on the screen, do mobile switch and speech input allow focus on them?
Detlev: When you bring up a menu or dialog, it's a user-initiated change, but that would be covered under focus order.
JJ: So how would it work in an app where a pop-up comes up on launch with update information? Would be interesting to look at some cases where apps might fail this SC.
Joe_Humbert: Scrolling is possible with switch and voice access on iOS and Android.
JJ: Also possible to scroll with hardware keyboard.
<JJ> close the queue
julianmka: Would a native element in focus is partially cut off (like with a very tight focus indicator), would that be a fail?
JJ: Probably not since the control would still be at least partially focusable. That would be under a different SC.