Meeting minutes
Guidance steps
We now have all success criteria on Github available for async feedback
@JJ would like to chat about the SC breakdown
In the drive there is a breakdown file where we can sort issues by complexity of adjustment for mobile.
<JJ> Link to SC breakdown: https://
JJ please don't move things, rather leave a comment
1.4.5 Images of Text - Level AA
quintinb: Does this mean that logo's do not need alt text?
Or should it just be the name of company?
@JC to @quintinb 1.1.1 would still apply
@JJ we need to put guidance on for testing purposes
julianmka - does text scaling apply? Are we creating a standard that is not necessarily seen on web
JJ feels it applies as is
<quintinb> +1
What if the text is part of a background? It's decorative
JJ then it does not apply
Jamie - We should use WCAG as a base reference - we shouldn't discuss issues that are already on here
Jamie we should consider system settings as well
Jamie we should add techniques for testing for people who don't have access to code
<Mick> + 1 to what Jamie said. A lot of my thinking around this is very much a testing perspective and providing techniques for native. Totally agree with keeping things simple and not complicated things.
Joe_Humbert: Thinks that a future goal should be for us to ask for manufacturers to give us guidance for testing with no source access
1.4.11 Non-text Contrast - Level AA
<Mick> +1 to the inactive component exception being problematic.
<Jamie> did we skip 1.4.10 REflow?
<Joe_Humbert> +1 to the inactive component exception being problematic
<JJ> 1.4.10 discussion @Jamie: w3c/
Joe_Humbert: About not modified by the author. This doesn't seem to be defined - what does that mean? For example, if the background colour is changed but not the component, does that not impact the contrast?
<julianmka> Agree with that - thinking about iOS default palette and text styles that don't have sufficient contrast
<quintinb> +1 we should not rely on manufacturers being accessible. We need to hold them accountable too
@JJ we should create a separate ticket about user agent
ACTION: Github issue for User-Agent discussion
2.2.1 Timing Adjustable - Level A
<Jamie> 1.4.10 is pretty much as written anyway
I have this somewhere, but should we mention examples where system settings allow for this, and should we give guidance on doing it in app or surfacing from settings?
<Jamie> +1 to @JJ to clarify how this timing adjustable applies to toast/ snackbar or future other components/ alerts as a general concept
<quintinb> +1 for guidance on "system" level things like snackbars
ACTION: Github issue for dealing with system settings when testing (toast length, high contrast mode, etc.)
julianmka app makers should meet requirements without system settings being required
<Joe_Humbert> +1 to developer responsibility without system settings
adding more settings doesn't solve that either
<Joe_Humbert> Quintin can you provide a link to the timing developer technique you mentioned?
But I do agree that we should not rely on OS manufacturers
Sure Joe, after scribing :)
I found it quickly Joe_Humbert: https://
Jamie: Users do expect system settings to be applied throughout apps
<Joe_Humbert> thank you Quintin
Joe_Humbert I can send you adb commands and where it exists in the ecosystem as well - if you like, but after :)
<quintinb> +1 Jamie
<julianmka> Agree - developers should respect system settings, and if those settings are not set, then provide an accessible experience out of the box
Jamie system settings should form a baseline expectation, but developers maintain responsibility for their app
2.2.2 Pause, Stop, Hide - Level A
So many failures
<julianmka> I have to drop for a work meeting. Thanks, y'all!
adb control for ttr Joe_Humbert: settings put secure accessibility_interactive_ui_timeout_ms [MILLIS] % millis are additive - they add extra time
<Joe_Humbert> thankx Quintin
I think there should be guidance given the dominance of video on mobile - it should stay paused if the same element type is paused
<Mick> +1 quintinb
Either every element should be pause-able or at least respect settings
Joe_Humbert: Just to raise: Android and iOS treat it differently when they refer to the setting - I wonder if iOS (reduce animations) is actually satisfactory
<quintinb> +1 Joe - is that actually stop animations?
I hate that terminaology - so vague
GleidsonRamos should we save the user preference in app?
<quintinb> +1 GleidsonRamos yes I think there should be guidance on that
<Joe_Humbert> great question
GleidsonRamos should we sync app setting with OS setting?
<quintinb> +1 yes I think that is the way
JJ there is probably some guidance on this type of situation
Jamie: Just to clarify: there is a feature for reduce motion and auto play animated images - seems like apple has 2 settings
<Joe_Humbert> +1 jamie. maybe I was confused
We should probably be clear about what we want and let the OS sort themselves out
JJ any new agenda items?
JJ how do we deal with OS vs / system settings
quintinb: maybe we should just focus on the desired behaviour
Joe_Humbert: We should honour users system settings
<JJ> +1
<quintinb> +1 Joe_Humbert
JJ looking for someone to lead the meetings in Sep.
Joe_Humbert volunteers as tribute
<JJ> If anyone else wants to volunteer, please let me know
<JJ> (we could have different people lead meetings in September)