Meeting minutes
<JJ> Jamie: providing update about the WCAG2Mobile document, mentioning the almost-complete status for most sections in the background / introduction categories
WCAG2Mobile update
<JJ> Jamie: providing update about the WCAG2Mobile document, mentioning the almost-complete status for most sections in the background / introduction categories
2.5.8 Touch Target Size (Minimum)
JJ: Summarizes previous discussion, including previous conversation about pixel conversion between platforms, exceptions outlined in 2.5.8, and the conflict between this SC and guidelines from Google and Apple.
Illai: How do we deal with user agents and even platforms, given that there are cross-platform mobile app technologies?
<JJ> https://
<JJ> platform software -> operating system? How to deal with cross-platform frameworks that have their own 'software' runtimes on top of native runtimes
JJ: We have an open issue for defining user agent in Github, but nothing for platform yet. Shared platform definition in WCAG2ICT
ACTION: Provide key term for Platform Software / Cross-platform Frameworks
Jon_Gibbins: We also don't have a definition of cross-platform frameworks. We should provide a key term for this.
<Illai> +1
JJ: How are we dealing with the "equivalent" exception in 2.5.8? Should the equivalent option be on the same page or screen?
<JJ> Poll: for 2.5.8, substitute "on the same page" with "on the same view/screen" instead of "in the same software"?
<JJ> julianmka: An app with a deeplink to account settings, the account setting screen has a sufficient sized button; would it be acceptable if the deeplink would be too small?
<Tim> +1
<Megan_Pletzer> +1
<Karla> +1
<Illai> +1
<RacheleD> +1
<Jon_Gibbins> +1
0
<Detlev> +1
<Jamie> +1
<Jon_Gibbins> Note: the nearest equivalent term in WCAG2ICT is “viewport”. I’ve noted that we need a definition for “view” or “screen”. I will try to develop some rationale for our next call.
ACTION: Substitute "on the same page" with "on the same view/screen" instead of "in the same software" - double check if apps would be unable to pass this SC by limiting to screen instead of app level
<JJ> +1 (from Joe_Humbert)
Detlev: Do we have a clear stance on just aligning with WCAG2ICT versus going above and beyond?
JJ: In this case, WCAG2ICT replaced "same page" with "software" -- switching to "screen" is consistent with the original SC language/intent
<JJ> w3c/
JJ: The AGWG has a new subgroup since November that is working to define "view" as a common definition for guidance.
JJ: The new version of the European standard is also looking to deviate from WCAG2ICT "set of pages/software programs"
ACTION: Double check substituting webpage with software, write down which SC's would be affected
<Jon_Gibbins> I’ll put comments in that GH issue
3.2.6 Consistent Help
<JJ> This SC has already moved into the drafting status
JJ: Noted that 3.2.6 is already in drafting status.
1.3.1 Info and Relationships
JJ: Summarized previous discussion and ideas for guidance captured in the Github issue (#1)
<JJ> w3c/
Illai: On web there is standardization for custom elements and how their constituent parts work together. On mobile, we have multiple platforms/frameworks that implement these relationships differently. How do we convey guidance on this at a high level?
JJ: Reviewing original SC language and definitions. Emphasis that this SC is part of the perceivable principle.
Joe_Humbert: I agree with Illai that it would be great to have such guidance but I'm not sure if it's possible. The web standards are at least somewhat open, whereas iOS and Android are more closed.
Illai: How would we test? Different platforms or frameworks will produce different output from assistive technology.
… there might be a barrier in testing for this SC.
<Joe_Humbert> Illai I think we might be able to address your concerns (in the future) with techniques documents that include how to test on iOS/Android/React/others
<JJ> How do we deal with paragraph navigation?
JJ: How much should developers code to mirror the visual layout? E.g. multiple paragraph elements
… The difficulty in this SC is how to test and how to fix it.
JJ: What other kind of definitions might we need to help clarify this SC? Add a note about information, structure, relationships?
<JJ> julianmka: in mobile apps, you can usually overcome 1.3.1 by following mobile best practices
<Jon_Gibbins> I feel those terms (information, structure, relationships) may be a little too generic to pin down here in definitions of key terms. It’s something we may need to address on an SC by SC basis?
<Jamie> +1 @Julian
<Jamie> +1 julianmka
<Joe_Humbert> +1
ACTION: Add note about following mobile best practices (and write down what these would be)
julianmka: A lot of pain in testing 1.3.1 can be mitigated by following good mobile design practices. It's much harder to build apps accessibly when you're shoving web conventions into a mobile app context.