Meeting minutes
<JJ> move to the next agendum
WCAG2Mobile Call For Consensus (CFC) in AG WG
JJ waiting for an email
@JJ pre cfc started 25 summary, next week actual CFC - 1 week delay
JJ Focus visble - JJ confused about keyboard operable user interface. This seems to focus on keyboard as opposed to keyboard interface
This SC seems to be written for keyboard and not keyboard interface
@JJ reading comments on GitHub
<pauljadam> Visible does not mean it has a certain contrast, that's not defined.
@JJ but customisable - then when developers have the capacity to change the focus indicator, it should be visible. But JJ means the system indicator
pauljadam iOS won't let you chnage the indicator
@JJ it's not possible to modify the system
<Jamie> qw
Joe_Humbert - we have said this only applies to keyboard, but switch access also uses the keyboard interface. This might not be the same on iOS and Android
by the way, Switch Control / Access is using the KB interface
I've been doing this with Ally Keys
Joe_Humbert then why did FKA preceed them?
pauljadam probably due to numbers (sorry for paraphrasing)
@JJ we need to be careful about wording
pauljadam on switch control - if it's keyboard accessible, switches work fine. I wouldn't change the definition. All you need to test is keyboard. @JJ confirms
Jamie have we confirmed that?
Switches allow for actions, which Keyboard does not, but other than that I haven't noticed much
Focus and selection are the same
pauljadam are we extending the scope of wcag if we explicitly require switch access?
Jamieyes
JJ mobile is changing a lot of the landscape
pauljadam WCAG doesn't say to test for focus color in switch control
@JJ I wonder how we should be reading this sc
<JJ> "Any" keyboard operable user interface has "a mode" of operation where the keyboard focus indicator is visible.
Detlev since switch is next / activate but keyboard allows for more granular control. Does that map equivalently?
@JJ are we just assuming switch access works - it's confused me in the past. 2.1.1 doesn't mean that switch and touch has to work the same. If the keyboard has equivalent control
pauljadam you could even use the enter key instead of a submit button
ACTION: Research on Android + iOS the behavior of Switch Control and External Keyboard focus indicators
quintinb the Switch interface allows for "build your own keyboard" as well as auto select etc.
<Joe_Humbert> 1+ to quintinb about switch access is very customizable
<pauljadam> That's why you keep it to Keyboard
<pauljadam> If you add accessibility Actions on iOS it works for VoiceOver, Keyboard, Switch all the same
I learned what I know from pauljadam's stuff, lol
<pauljadam> :)
<pauljadam> keep as is will be my response mostly :)
<quintinb> +1 pauljadam
JJ we could add a note about best practice regarding accessibility interface
<pauljadam> we going to start talking about Eye Tracking too? probably too hard to discuss every possible AT on Mobile
<JJ> Keep the text as is, but add note about best-practices for focus visible for assistive technologies?
<pauljadam> So regular WCAG does not say "Make sure you do switch controls too" But Mobile WCAG needs to say that?
julianmka we should keep to a similar approach that we've been taking regarding mobile being different. We should be aware of what the system supports and keep with intent rather than being explicit on every possible AT
julianmka windows doesn't support switch control
<JJ> Poll: Keep text as is, add note about supporting focus indicators for other types of assistive technologies?
<Tim> +1
<GleidsonRamos> +1
<pauljadam> Keep as is, no note needed
<Jamie> +1 plus note
<Tanya> +1
<Detlev> +1
<quintinb> +1
<Illai> +1
<julianmka> +1
<Carol> +1
<pauljadam> What if Apple or Android changes later?
<pauljadam> Are we going to define everything possible for a developer?
Joe_Humbert do we need to acknowledge that devs can change the original focus indication
JJ we could use a similar note to 1.1.1 where not every platform does something
<pauljadam> I'm not sure it's worth the effort of if we'd have full accuracy if we start defining what is possible and what is not possible for each platform.
ACTION: Add second note: Not all mobile platforms provide a way to programmatically change the keyboard focus indicator.
2.4.7 Focus Visible
(actually 3.2.1)
JJ what do we see as a component, and what do we consider as a change of context
JJ is element different from component?
<pauljadam> UI component, UI control, UI element all the same thing
<quintinb> +1 pauljadam
<pauljadam> if you want to update Change of Context definition then just remove the word "Web" from "Web page"
3.2.1 On Focus
@JJ do we need to redfine / modify the definition of UIC (User Interface Component)
<pauljadam> definitions of UI components seems fine and does not need a change since it's written generically and does not say "Web" specifically
JJ sometimes a component can be a combination of controls
Joe_Humbert re:definitions, would those be impacted by the views discussion last week. Like more for subview and component
@JJ I am confused about what is being perceived by users - is it what you can control
JJ if it can receive focus it's generally interact-able
What concerns me: "page" and "viewport"
<JJ> quintinb: change of context, might need to replace "page" and "viewport"
<pauljadam> I would replace "Web page" with "page"
<pauljadam> clear
JJ is UIC clear?
<Carol> Yes
<quintinb> +1 (it is clear)
<GleidsonRamos> yes
<Tim> +1
Jamie I think we documented in the ticket about UIC that we have open to make that consistent pattern when to use component and UIC. Or is it in the note 3? Is that a note from WCAG?
JJ yes it's a part of WCAG
Jamie because that tripped me up
Jamie there is some wording here that may not only apply to this SC only
JJ it seems that UIC refers to interactive features
JJ for example 3.2.4 just says "component" - as opposed to UIC
Joe_Humbert I think that's addressed in Note 3 under UIC
pauljadam an element could be an image. Page element vs UIC does have some confusion associated
<pauljadam> component and control seems more specific than element which could be more generic
Joe_Humbert is component defined?
JJ no
ACTION: Create issue in WCAG for user interface component (control) vs component (element?)
<pauljadam> If you say "Design System Elements" that could mean ever possible element that is not operable as well, "Design System Components" or "Controls" means only the operable UI controls the user would be tapping and clicking on
4.1.2 Name, Role, Value
Oh so a small one
<pauljadam> Yeah it think everyone fails something if it has the wrong role or the wrong state.
<pauljadam> You can't put aria-expanded=false if it's visually expanded.
<pauljadam> I'd remove "Web" and "HTML" from that definition
Illai: 1. Regarding role - it is being implicitly referred to in 1.3.1. But there is some confusion in mobile in 4.1.2 in the note. If you are using native elements you should be "good" - we don't have a real definition of what a native element means
<pauljadam> same deal for native apps
JJ there has been a change in WCAG addressing the web part about something custom or not. XML vs Compose: is that native?
<JJ> close the queue
<pauljadam> if it's not in a web view then it's native
<JJ> pauljadam - yes it is "native", but is it provided by the OS or custom built by a developer
<JJ> it relates to the "unmodified" exception
quintinb role can be strictly defined, but it has changed even in Android views to compose. It's a careful definition
<JJ> GleidsonRamos - please comment in the chat or on Github
<GleidsonRamos> ok
Detlev from a practical perspective there are elements that are compound, some elements have actions. There are many different types of roles (e.g. action descriptions) - is that a fail?
<pauljadam> on iOS if you combine the focus of a card and give it accessibility actions then the button role is still spoken if there is a button inside the card
<Joe_Humbert> For previous agenda item 3.2.1 w3c/
<Detlev> pauljadam intersting...
<pauljadam> I have a Cards demo in my a11y techniques iOS app