Meeting minutes
<Mick> +present
<quintinb> Thanks @Aashutosh
<quintinb> I have a hard stop on the hour, apologies if I have to drop
JJ shared the 9 SC that are potentially not applicable
<quintinb> Jetpack compose has lost the ability to do a "labelFor" with the loss of id's :(
Aashutosh shared views about the first 3 being applicable
Discuss remaining Success Criteria of breakdown
Mick says need more discussion for 'potentially not applicable'. There is a lot of debate
<quintinb> As long as we come back to this one
<quintinb> I think the goal of this SC is that forms are clear, and that relevant information is not lost when elements are focused - e.g. using a hint as a label
<Joe_Humbert> +1 to julian's comments about text spacing
julianmka shared that the Text spacing will not be applicable since the apps are designed to respect user settings
julianmka agreed to have more discussion on 1.3.5
<JJ> Move 1.3.5 to Large Variations?
<julianmka> +1
<Aashutosh> +1
<Joe_Humbert> +1
<Karla> +1
<Mick> Leave in Potentially not applicable
<Illai> +1
<Devanshu> +1
<quintinb> +1
@JJ moved the 1.3.5 to large variations category based on the Votes
ACTION: Move 1.3.5 to Large
<quintinb> This is scrolling in 2 dimensions at the same time, correct?
JJ we need to define clear ways on how to test 1.4.10
<julianmka> +1 to Joe's point
<Mick> +1 Joe
<quintinb> +1 to not specifying a specific resolution
<Illai> +1 Joe
<quintinb> the resolution shouldn't matter
Joe_Humbert we can't do much about the resolution. how can we define the generally applicable resolutions with variable sizes in Android
<quintinb> Perhaps we can just make the scrolling style more clear - because scrolling in 2 mutually exclusive directions does work fine - e.g. streaming services
<julianmka> +1 to quintin's comment ^^
<quintinb> +1 to medium
<Carolina> medium
<Mick> I'd say at least medium.
<Joe_Humbert> +1 medium
<Illai> large
<Karla> large
<julianmka> +1 medium
<Mick> large
ACTION: Move 1.4.10 to Medium
<Illai> Maybe we should aim for a minimum spacing that is legible?
<quintinb> Is it feasible that OEM's could add this?
<quintinb> +1 Illai
<quintinb> Samsung is known for being sneaky about this kind of thing
<quintinb> "Sneaky" accessibility
<quintinb> Yeah you could compile your own Android OS....
<AAK> Joe_Humbert This is achievable on Samsung since they allow custom font to be used as system.
<AAK> Joe_Humbert users can use the font with larger line height
<quintinb> I would advocate for respecting the system setting as a bare minimum
<julianmka> +1 to quintin
<Joe_Humbert> +1
<Illai> > +1 to quintin
<quintinb> What are the tools for testing mobile line height? Grab a ruler?
<AAK> julianmka : what do we think about Google's non linear scaling?
<quintinb> +1 julianmka
<quintinb> I think we need to define a minimum font size
<AAK> julianmka could variable font sizes affect the line heights?
<quintinb> (joke) It's only 20% of the population julianmka...
<julianmka> +100 Joe re: honoring system settings
<AAK> Joe_Humbert Apple has non linear scaling too. Google seems to following apple.
<AAK> Joe_Humbert suggests that we add "respect the user settings" as a global guidelines.
<quintinb> what if we specified a minimum size (in pixels) and used that as a baseline - then all the dynamic stuff doesn't matter
<julianmka> Google Developers blog post about font scaling and default use of non-linear scaling in Android 14: https://
<Joe_Humbert> thankx julianmka
<AAK> quintinb what if we specify minimum font sizes in Pixels?
<julianmka> Are we diverging too far from the intent on the text spacing SC?
<AAK> JJ the guidance needs to be futureproof
<Jamie> +1 julianmka
<JJ> 1.4.12 Text Spacing: Small, Medium or Large variation? Or Not Applicable?
<Mick> Not Applicable
<quintinb> Large
<Jamie> large or not applicable
<Joe_Humbert> not applicable (currently)
<julianmka> Not applicable
<Illai> Large
<Carolina> not applicable
<Karla> Not applicable
<AAK> Large
<Jamie> not applicable in our first version
ACTION: Keep 1.4.12 at Not Applicable, but consider future system settings
<quintinb> I think you can use a mouse on Android
<Jamie> you can use a mouse on both OS
<Joe_Humbert> +1 to quintin
<AAK> +1 to quintinb
<quintinb> Absolutely
<AAK> I use that!
<Jamie> i know, that was a statement
<Jamie> ;)
<Jamie> +1 to AAK
<Carolina> I think it needs to be consider too
<quintinb> Yeah and hover-based context changes are definitely possible - so we need the SC
<Joe_Humbert> small
<quintinb> +1 Joe_Humbert small
<Carolina> yup quintinb
<Carolina> small
<AAK> Jamie how would we address the mirroring feature? where the phone can be used on a mac
<AAK> Jamie how would we test for that?
<quintinb> Apple's mirroring has limited keyboard
<JJ> 1.4.13 Content on Hover of Focus: Small, Medium or Large variation? Or Not Applicable?
<Joe_Humbert> using keyboard and mouse with mirroring has been somewhat possible for a while with both OS and third party software
<AAK> JJ we need to investigate if the mirroring uses touch events or click events
<Joe_Humbert> Small
<quintinb> Small
<AAK> Small
<GleidsonRamos> small
<julianmka> small
<Karla> small
<Jamie> small
<Illai> Small
ACTION: Move 1.4.13 to Small
<Jamie> also add to the User Agent issue
<quintinb> `GUI + /` on Android lists the shortcuts, and developers have access to this menu
<quintinb> (they can add to it, and should)
<julianmka> +1 keyboard shortcuts must be listed in OS helpers
<julianmka> (or some other easy to find place in UI)
<quintinb> +1 keyboard shortcuts must be listed in OS helpers (thanks julianmka)
JJ the goal should be avoid unintended actions
Jamie follow up to Joe_Humbert . People can add shortcuts to keyboard.
Jamie how do we communicate we are testing the conflict of keyboard shortcuts?
<quintinb> If there are key shortcuts (which developers can and should add) they can also get them registered for discover on the help menu (a separate element of code)
<julianmka> Would be nice if the OSes automatically included any assigned shortcuts in the helper menus instead of devs having to do that manually.
<JJ> 2.1.4 Character Key Shortcuts: Small, Medium or Large variation? Or Not Applicable?
<quintinb> Medium
<Mick> Large
<Jamie> small
large
<Joe_Humbert> small
<Illai> Small
<julianmka> small/medium
<Karla> medium
<Carolina> small
<Jamie> can we create a new category of "come back to this later"?
<GleidsonRamos> medium
<quintinb> julianmka the registration allows developers to describe the action with a label, which may also help voice control users (not sure on that though)
ACTION: Move 2.1.4 to Small
<JJ> 2.4.2 Page Titled: Large variation?
<Jamie> large from WCAG2ICT
<julianmka> +1
<Mick> +1
<Illai> +1
<Joe_Humbert> +1
<Karla> +1
<quintinb> +1
<Aashutosh> +1
ACTION: Move 2.4.2 to Large (compared to WCAG2ICT)
<Jamie> 3.1.1 see Note 1
Should fall under the large bucket "respect user settings" imo
<julianmka> +1 Aashutosh
JJ we still need to test if it is supported
<JJ> 3.1.1 Language of Page: Small, Medium or Large variation? Or Not Applicable?
<Carolina> medium
<Illai> Small
<Jamie> small in relation to WCAG2ict
<Karla> small
<quintinb> Small
<Mick> Medium
Small
<Joe_Humbert> small
<julianmka> small
ACTION: Move 3.1.1 to Small
Joe_Humbert that was my exact question! :D
<Jamie> 3.1.2 also use Note 1
<JJ> 3.1.2 Language of Page: Small, Medium or Large variation? Or Not Applicable?
<Joe_Humbert> small
<Jamie> in my company we use a scree reader foe the technique
<Jamie> small
<julianmka> small
<Karla> small
<quintinb> small
<Illai> small
ACTION: Move 3.1.2 to Small
<quintinb> Android views was xml, lol
<Jamie> not applicable
<Mick> Not appliable
<julianmka> not applicable
<Illai> N/A
<JJ> Keep 4.1.1 at N/A?
<Joe_Humbert> not applicable
<Carolina> not applicable
<Karla> +1
<quintinb> +1 but it should be actually not applicable, not even potentially