Meeting minutes
<Illai> +present
<Mick> +present
<Karla> > present+
scribe julianmka
Success Criteria breakdown
JJ: Concern with several SCs marked as greater variations is about how to test - e.g. images of text
<JJ> Move 1.4.5 to Minimum Variantions
<Mick> +1
<AlainVagner> +1
<julianmka> +1
<RacheleD> +1
<Karla> +1
<GleidsonRamos> +1
<quintinb> +1
<Illai> +1
<Joe_Humbert> +1
<JJ> Move 2.4.4 to Minimum Variations?
<AlainVagner> +1
<julianmka> +1
<RacheleD> +1
<Karla> +1
<Mick> +1
<GleidsonRamos> +1
<quintinb> +1
<Joe_Humbert> -1
<JJ> Success Criteria breakdown doc: https://
Joe_Humbert: Cites WCAG2ICT noting that "link" does not mean literal link in native mobile. Several SCs we're considering need explanatory notes.
<quintinb> Is this providing a distinction between a link and some other system action?
Joe_Humbert: E.g. for link purpose - in native mobile, there are links, buttons, and also "double tap to activate" elements
<julianmka> +1 to Joe's point about what "link" means in native mobile context
<Aashutosh> In mobile apps, everything is interactive. So like Link purposes, the meaningful labels would be necessary for everything?
<quintinb> Just a note: we should also consider touch target sizes re:links or "text as innteract-able element"
<Aashutosh> +1 quintinb
<Aashutosh> off-topic, can we enforce the minimum size requirements to the ads that are playing inside the apps?
<Aashutosh> close buttons*
<quintinb> +1 Illai
Illai: Link purpose has the same issue as headings and labels - using them properly might need a note.
JJ: How so for headings?
Illai: Intent and Understanding docs refer to semantic headings and labels, but those don't have parity in native mobile compared to HTML.
Joe_Humbert: Are we coming up with our own definitions of headings & labels?
Illai & Joe_Humbert: Clarify Illai's comment was about how labels & headings relate to other content, not _what_ they are.
JJ: Need to be careful about modifying definitions and such. If SCs are very close to applying directly, let's not over-complicate.
<Jamie> We are looking at 2.2 now too?
<JJ> Move 2.4.11 to Minimum Variations? Large, Medium or Minimum?
JJ: 2.4.11 Focus Not Obscured - is this a medium variation? It could use more about techniques, but seems to apply fairly directly.
<Mick> The floating button exception will be tricky in mobile to adhere to
<Mick> Large
<Aashutosh> This should be large considering horizontal scrolling requirements as well
<Joe_Humbert> minimum
<quintinb> I would argue this needs to be as important as keyboard
<Joe_Humbert> i changed my mind medium
<AlainVagner> medium
medium
<GleidsonRamos> medium
<Karla> medium
<Jamie> thank you. I am having microphone issues.
<Carolina> medium
<Illai> medium
JJ: Keep 2.4.11 in medium variation category.
JJ: Summarizes Joe_Humbert's comment about need for advisory techniques on how to apply 1.2.3.
<quintinb> minimum
<Jamie> minimum
<JJ> Keep 1.2.3 at Minimum Variations?
<julianmka> +1
<RacheleD> minimum
<AlainVagner> minimum
<Jamie> minimum
<quintinb> minimum
<Illai> minimum
minimum
<Mick> minimum
<GleidsonRamos> minimum
<Karla> minimum
<JJ> quintinb+jamie first minimum comment are part of 1.2.3
<Joe_Humbert> minimum
<quintinb> It's more important that it happens than how it happens
Joe_Humbert: Do we need to give an enhanced definition for "alternative for time-based media" given differences between web and native mobile contexts?
<Jamie> Joe_Humbert at this time I would be ok with the time based description
Joe_Humbert: In original definition, does "document" need to be clarified for mobile context?
<Jamie> we could review in a 2.0 version of the document
<julianmka> +1 to Jamie
<quintinb> +1 Joe_Humbert
<Jamie> we need a 1.0 version for AD since this is not being done in most places anyway
<AlainVagner> +1 to Jamie
<quintinb> They aren't doing something else
Joe_Humbert: Most apps aren't supporting audio descriptions/alternatives -- are they doing something else or nothing at all?
<Jamie> no, I meant we need a first version that outlines the basics
<Jamie> JJ
@JJ: We'll add AD definition to backlog for future work.
<quintinb> I think orientation is far more important on mobile
JJ: Orientation applies directly but there are lots of implementation considerations.
<JJ> Keep 1.3.4 at Minimum Variations?
<Jamie> minimum
Joe_Humbert: Are we saying that apps need to rotate and content needs to be there, or does it have to work _well_?
<Jamie> implementation is more important than web but the SC as written applies
<Jamie> +1 to julianmka
<quintinb> +1 julianmka
JJ: Basic support I look for is "is the content there and does it work"
julianmka: Because orientation is such a difficult thing to get people to accept, I only look for bare content and functionality.
<quintinb> There isn't great recent research on orientation - I found some stuff from 2012 that was like "yeah people do it"
<Aashutosh> most of the elderly have their phones mounted in horizontal orientation on their carts
Joe_Humbert: It doesn't need to look nice - I'm thinking about scrolling, is it much harder to get to elements because they are distributed differently? Is users' ability to reach things compromised? Users who need landscape orientation usually have other barriers to access already, are more severely affected.
<julianmka> +1 to Joe's comment
<AlainVagner> low vision is also another reason to use landscape, in combination with a bigger font size
<quintinb> +1 Jamie
Jamie: In my experience, size of sticky footer and navigation bars was a factor. Perhaps a note to consider content dominance -- what takes up the most space when in landscape? Could also be part of a note in reflow.
<quintinb> I can't read most websites because of sticky ... looks for a nice word ...
<Joe_Humbert> very good point Jamie some of my concerns and what you brought up may fall under a different SC
<Aashutosh> quintinb in design world we call it frozen
Jamie: Could include a note for small screens in particular, in both portrait and landscape.
Jamie: Probably good to stick with minimum language now, but enhance it later.
<quintinb> ty Aashutosh!
julianmka: Points out new feature for iOS this year to collapse navbars into side menu
<Aashutosh> julianmka is there a resource we can refer to?
JJ: Another issue for landscape users -- keyboard often blocks the input
<JJ> Keep 1.3.4 at Minimum Variations?
Aashutosh I'll find it after the meeting and put in Slack
<Jamie> minimum
minimum
<Joe_Humbert> Minimum
<AlainVagner> minimum
<Mick> minumum
<Illai> +1
<Carolina> minimum
<Karla> minimum
<Devanshu> minimum
<quintinb> minimum
JJ: 2.5.7 probably needs more guidance for mobile.
JJ: We can add some examples of gestures that fall into this SC. WCAG definition is pretty clear.
JJ: We can document implementation techniques for mobile like accessibility actions.
<Illai> Maybe it worth referring multipoint touch gestures which are unique to touch devices
Aashutosh: I've encountered issues where swipe gestures to complete payment is required for security reasons (does the user really want to pay?). This is common in India/SE Asia.
<quintinb> Surely you can add a dialog for a non-swipe action
Aashutosh: Clarifies that the interaction requires dragging across the full width of a bar, not a single swipe gesture.
<quintinb> +1 JJ
JJ: This could be handled in app settings - let users choose an alternative method.
<Aashutosh> +1 JJ
That's why this SC exists, "swipe to pay" as the only way to confirm would be a violation of this SC.
Jamie: This SC is newer, could also be why this pattern is proliferating.
JJ: We can document alternatives to dragging actions like swipe to pay.
<JJ> Keep 2.5.7 at Minimum Variations?
<julianmka> +1
<Jamie> minimum
<Mick> minimum
<Illai> +1
<Karla> minimum
<Joe_Humbert> https://
Joe_Humbert: WCAG definition of "dragging" covers almost any gesture on mobile because it refers to "down" (i.e. touching screen) and "up" (i.e. lifting finger) events.
Joe_Humbert: This seems to apply to anything you do on mobile, this could be too broad to be usable.
JJ: Intent for 2.5.7 is clearer
Joe_Humbert: But Understanding documents are non-normative, only WCAG language is binding.
ACTION: bring up "dragging movements" definition to AG WG
Good catch, Joe!
JJ: Whether 2.5.7 has minimum variations might depend on outcome of the "dragging movement" discussion.
<AlainVagner> +1
<Mick> +1
<Jamie> minimum
<Illai> +1
<quintinb> minimum
<Karla> +1
<julianmka> +1
<Joe_Humbert> +1
JJ: 3.2.6 Consistent Help may have large variations because of "sets of software".
<quintinb> Is no help considered consistent?
Jamie: SC says that for screens that have help, put it in the same place. It does not mandate that every screen should have help.
<quintinb> +1 (and ty) Jamie
<JJ> Move 3.2.6 to Large, Medium or Minimum?
Jamie: "Set of software" language makes this and other "consistent" SCs tricky.
<Jamie> medium
medium
<AlainVagner> medium
<quintinb> minimum
<Illai> medium
<Mick> Large for constancy with others
<Devanshu> medium
Joe_Humbert: Seldom see help available across multiple screens in apps.
<Joe_Humbert> medium
JJ: Help can be context-dependent. Easier to solve on the web, handling in apps can be more complicated.
JJ: Definition of "sets of software" and "screens" vs "pages" may affect whether this is a larger variation.
<JJ> Thanks for scribing julianmka !