Meeting minutes
Joe_Humbert: welcome everyone
2.4.7 Focus Visible
<Joe_Humbert> w3c/
Joe_Humbert: this was discussed over a year ago
Joe_Humbert: one of the big things was to define keyboard interface… we also talked about different techniques, covered that last time
Joe_Humbert: most of the hang up on this issue was the discussion of keyboard focus indicator, researching that and possibly changing or expanding the definition / normative text
Joe_Humbert: some research was done on different types of focus indications
Joe_Humbert: it seems like people were ok with the current definition
github: w3c/
Joe_Humbert: we talked about adding a second note
Joe_Humbert: is there any other discussion on this?
Joe_Humbert: if there's no other discussion, I'll ask for +1s to see if we're ok keeping this SC as written, with the potential changes to a new definition for keyboard interface and adding that note
<Jamie> +1
<hdv> +1
<pauljadam> +1
<julianmka> +1
<rachaely> +1
<Tim> +1
<Tanya> +1
Tanya: I created a bunch of sub issues this morning; we're currently discussing with @@@ and JJ, who is still on vacation. Still need to determine next steps in the process. For now I'd add a sub action, can do that
Joe_Humbert: ok
rachaely: maybe left over from last meeting
Keyboard interface definition
<Joe_Humbert> w3c/
github-bot, topic w3c/
Definition of "keyboard interface" in mobile application context
<github-bot> OK, I'll post this discussion to https://
Joe_Humbert: this started out from the original meeting last year in August
Joe_Humbert: this is about defining keyboard interface, would want to include assistive tech like voice control
Joe_Humbert: there was discussion re keyboard focus and cursor, technically they are different concepts
Joe_Humbert: in WCAG virtual keyboards are examples of keyboard interfaces
Joe_Humbert: Jamie commented on it too (see GH issue)
<Joe_Humbert> https://
Joe_Humbert: let's check the WCAG2ICT definition
Joe_Humbert: that has 2 notes
Joe_Humbert: *reads notes*
Joe_Humbert: I don't see a lot of difference between WCAG 2 and WCAG2ICT
Joe_Humbert: so I'd like to open it up for discussion
Joe_Humbert: do we need to expand it?
julianmka: in a lot of other conversations on keyboard accessibility, we have not extended the definition to virtual keyboards… given that, this definition seems sufficient to me. I appreciate the mouse keys shoutout, knowing that pointer emulation is not the same as being keyboard operable. This might give us what we need
Jon_Gibbins: something else that might need clarification… whether or not @@@ on Android counts as a keyboard interface… it's not like mouse keys, but it sits somewhere between mouse keys and keyboard, virtual or otherwise
Jon_Gibbins: on some Android devices there's a joystick like interface
Jon_Gibbins: my gut feeling is is that this doesn't really sit in the keyboard interface definition, you wouldn't call a joystick a keyboard, but would be able to use it to navigate
Jon_Gibbins: not sure if it is clear that that therefore doesn't count… wonder if we need to clarify
Tanya: looking into the issues that I was creating this morning… currently we have a sub issue for 2.1.2, it's about that we need a clear distinction between keyboard interface and accessibility interface
Tanya: should definitely be taken into consideration in 2.1.1
Tanya: when something that is focusable with keyboard interface is not focusable with accessibility interface, that would be a gap, that we could fix in this definition or in a separate note. Or maybe with accesssibility interface as a new definition
Joe_Humbert: not sure if we have a definition for a11y interface
Tanya: don't think we have a separate definition for that
Joe_Humbert: WCAG2ICT doesn't either
Joe_Humbert: thanks for creating those sub tasks
rachaely: agree with Tanya. To me this makes sense in context of focus visible, but not in terms of keyboard accessibility.
Joe_Humbert: do people on the call feel we should separate the definition?
Joe_Humbert: seems like rachaely and Tanya 's comments lean towards adding notes, as opposed to changing the definition, is that accurate?
rachaely: yes to me it makes sense to leave the definition and add a note to 2.1.1
pauljadam: I wonder; on iOS if you make something operable to VoiceOver, it works with all of the other AT, basically, so you don't have to do extra work for each one
<pauljadam> I've seen that happen when a developer makes something focusable only when swiping with VoiceOver but you could not directly touch the element and then it was also not keyboard or voice control operable.
julianmka: in a lot of cases peoople have built components without the understanding of the accessibility APIs. Have seen cases where like VoiceOver is accessible, but keyboard is not… with Swift UI out of the box usually would work fine but when people role their eyes we need to have extra eyes on
Joe_Humbert: a much larger discussion… let's vote on that, do we need a separate definition for accessibility interface?
<pauljadam> Note: Most of the work that goes into making your app accessible to VoiceOver users will also make it more accessible for Voice Control users. For this reason, we recommend you start with the VoiceOver Accessibility Evaluation Criteria before evaluating Voice Control.
0 (not sure)
<rachaely> +1
<Carol> +1
<Tanya> +1
<Tim> +1
<Jamie> 0
<julianmka> *when people build their own custom components, they need to have their eyes open
<Jon_Gibbins> -1
<pauljadam> I'd need to know what the definition is
<julianmka> 0 also not sure
Joe_Humbert: based on this I think I should create an issue, wecan bring it up for discussion in another meeting…
<Jon_Gibbins> I’m not sure we do. Unless I misunderstand the intent, I feel that an accessibility interface consistutes working to the platform’s native accessibility API, so that software works with whatever assistive technology we’re referring to (voice access, switch access, screen reader, etc.)
<Jamie> +1 to Jon_Gibbons definition lol
<julianmka> +1 to Jon_Gibbins
<pauljadam> Sort of strange that Apple has no guidance on supporting Switch Control or Full Keyboard Access https://
<Jon_Gibbins> That’s essentially 4.1.2 mainly
ACTION: create github issue for "accessibility interface" definition
Page definition
<Jamie> agreed pauljadam maybe it will be added later
<Joe_Humbert> w3c/
github-bot, topic: w3c/
<github-bot> hdv, Sorry, I don't understand that command. Try 'help'.
github-bot, topic w3c/
Definition of "web page" in mobile application context
<github-bot> OK, I'll post this discussion to https://
Joe_Humbert: this is to try and figure out how we replace the word web page in the context of all success criteria, for WCAG 2.2
Joe_Humbert: to bring up the context in the larger group… a lot of work happened, but seems to have stalled
<Jon_Gibbins> There is also the associated Issue w3c/
Joe_Humbert: *reads comment in #110 *
(this comment w3c/
<pauljadam> Do we just need to remove the word "web" and call it page? Or swap "web" with "app" and call it an "app page" :)
hdv: +1 to 'seems to have stalled in the larger WCAG group'
Jon_Gibbins: I've also stalled my thinking on this
Jon_Gibbins: re using just the word 'page', would be a simple switch that would just work
Jon_Gibbins: as we're making a work in progress, we can use a working title, such as page
<pauljadam> I think simplest solution is just call it "page" but if it needs to be "app page" or "mobile page" seems fine, but it should remain a page so that Page Titled fits well.
Jon_Gibbins: I'd call them a screen… but then that's also a physical hardware term… view is problematic for similar reasons
Jon_Gibbins: the reason we're defining this for work in the standard… so that we can say this is what we mean by this phrase, you can call it something else, but this is what we call it. Whatever we end up with has to work for iOS / Android
Jon_Gibbins: another word was 'activity', but is a bit vague, sounds even like it coul be about multple screens
<pauljadam> mobile apps are the web :)
Jon_Gibbins: the W3C is about web, which is perhaps why we struggle with this view definition as it has to capture what is not web
Jon_Gibbins: we might get some pushback with what we're trying to define here
Jon_Gibbins: so it;s not en easy challenge
<pauljadam> View and Screen does not work in my opinion.
Joe_Humbert: in WCAG 2.2 it is set of web pages… in WCAG2ICT it is set of software programs and set of documents etc
Jamie5: some people are still using the old mobile document from 2015
Jamie5: the sooner we can move on from this topic and use a working definition… we can have somerthing to move forward from
Jamie5: whatever we can agree on… and then we can get in the granular discussion later
Jamie5: but at the very least we can say we're not talking about a set of apps, move on from there
<Jon_Gibbins> +1 re Jamie5 on there being essentially no use for a “set of apps” definition
<pauljadam> Set of pages or set of mobile pages or set of app pages
Joe_Humbert: i like the overall term Jon proposed
<pauljadam> no
Joe_Humbert: we need to decide on an overall term we can agree on
<pauljadam> you need something that can be generically applied to both android and iOS and fits into WCAG, "page" is that :)
Joe_Humbert: what problems do people have with this definition…
rachaely: I do like the term view as it is described in this definition
rachaely: it's a pretty standard term used
rachaely: we also have the definition of a native mobile app
rachaely: whats the value of that being in the definition?
Jon_Gibbins: the issues are linked… I was considering originally set of web pages and set of software programs. There was a requirement to define them in that context
Joe_Humbert: these are separate definitions we can deal with each one separately, eg accept one or multiple of them
<pauljadam> WCAG has the SC's Page Titled and Language of Page
<Jon_Gibbins> The text was originally quoted in a related issue for “set of web pages” / “set of software programs”: w3c/
<pauljadam> look how many times the word "page" is in this checklist https://
hdv: I like view, screen, page (in that order), I don't agree with the problems the larger group sees in them. I don't beleive teams working on accessibility issues will actually, in reality, misunderstand what we're talking about when we use any of those phrases. Yes, theoretically people can poke holes in them, but people can to that with any term and also with a lot of existing WCAG, I know, I work at a government dept, that sees these all the
time. I hope we won't be held back for much longer as I
Joe_Humbert: yes we're looking for common ground, developers will undestand but also iuntermix these terms… we should define something and than we can move ahead
<pauljadam> hybrid apps can contain web pages right
<pauljadam> .html files are called web pages?
<pauljadam> :)
Tanya: my understnaing is what we decide, should be applicable to native mobile apps, mobile web apps, hybrid apps and web components too… whatever we choose, should be applicable to all of those things
Joe_Humbert: what we sent out was drafted January of last year, it's old, and an early thing. Think we kind of moved away from talking about mobile web apps and hybrid apps
pauljadam: native mobile apps could be hybrid
pauljadam: I don't think users see a lot of difference between native apps and the web
Jon_Gibbins: I felt the same when we considered publishing the draft
Jon_Gibbins: we talked about including hybrid apps or any kind of web content. I think the feeling was that we already have the web content accessibility guidelines to apply to those situations… so our work is focused on native. But that is not reflected by the wording in the abstract
<Joe_Humbert> +1 to Jon's comment about WCAG already applying to web content
Jon_Gibbins: we'll need some clarity on that, are we talking about the web at all?
<pauljadam> if a user downloads an app in the App Store they don't know if it's a hybrid app or a pure native app
Jon_Gibbins: I lean towards 'page', but not sure if I consider native mobile to be the web, it works on the internet but is not HTML, CSS, JavaScript, but that's a whole different discussion
<pauljadam> an app you download from the app store can be made of HTML web views and wrapped into a native downloadable app
Jon_Gibbins: from my POV I consider this a translation of WCAG to native
Jon_Gibbins: to help people who are working on mobile to make their apps accessible
Jon_Gibbins: to answer the kind of questions that devs and designers have
Jon_Gibbins: that's how I see this group's work
Joe_Humbert: I'll put an action out for the group to think about between now and the next meeting: get feedback on 'are we ok with just focusing on native mobile?'
<Jamie5> Joe_Humbert do we need to be discussing the larger topic of native vs mobile web app now?
<pauljadam> if we were writing techniques then you would know what platforms you are targeting
<pauljadam> because the web views techniques would be different than SwiftUI or Android Compose native techniques
ACTION: Consider for next meeting, Should the group only be focusing on Native mobile?
hdv: we need to carefully thread this needle, as traditionally W3C members are most interested in making standards for the web and explicitly not in non-web standards
Jamie5: we should probably wait until JJ is back to discuss this
<Joe_Humbert> close the queue
<julianmka> +1 Jamie5
<Tanya> +1 Jamie5
<Jon_Gibbins> +1 to Jamie5’s comment - wait for JJ as chair to return, short discussion and push for a vote on a working title
Joe_Humbert: larger discussion definitely needs to wait until JJ is back
<Jon_Gibbins> …a working definition