Meeting minutes
<Detlev> An issue for the agenda (future) would the contrast exception for OS-driven keyboard focus
ACTION: Add agenda item for contrast exception for OS-driven keyboard focus
Weee
2.4.4 Link Purpose (In Context)
Detlev In my exp links are expected to leave an app and open a browser. Is this the general expectation, and it's not made clear by WCAG2ICT
<dotjay> We are perhaps delving into a general accessibility consideration here. Links versus buttons is an issue for all platforms.
<dotjay> For mobile, perhaps it’s more about clarifying hybrid situations?
If a business wants to throw away money developing links where buttons should be, that's really their perogative
<Tim> Does it help to make notion of 'internal link' vs 'external links'?
Joe_Humbert I agree with Detlev - Google and Apple have muddied the water by allowing developers to make anything a link, and doing it themselves
I think we can - Google and Apple need to be accessible too - just because they allow devs to be bad doesn't mean they have the right to
Detlev Determinable context can be made more clear and while controls can be made better. Are there established ways of getting to the context in mobile apps?
dotjay Differences between desktop/mobile - navigating by link is possible on mobile, so getting context is possible. We don't see the "f7" display all links on mobile. What does context mean in the sens of mobile and is it different from desktop?
I think in TalkBack you can show all links
<Detlev> I don't think "Link context" means being able to bring up a list of links an the view.
<dotjay> Devlev: I meant to highlight situations where out of context versus in-context for mobile environments.
<dotjay> “Show all links” is simply an example of that. So much of the time on mobile, we are navigating into context and can discover context as the virtual cursor is moving.
<Detlev> So would that mean checking for link context would only apply to like that 1. stand lone 2. are no clear in itself?
Joe_Humbert Google can allow to show all links. iOS does tell users there is a link. That's because that's how links are created. Because we can assign the role ad hoc, it's hard. A link in an attributed string can't take you somewhere in the app because it doesn't know the context of the app
Jamie If it's about navigation, then in an app setting, buttons do this job. So perhaps the context is a little different
<Joe_Humbert> +1 to Jamie about "Button" Purpose as a consideration
<julianmka> +1 to Jamie
Detlev in most audits cases, the links are looked at as part of the context
Joe_Humbert there are limitations - in desktop the SR has a lot of flexibility. in iOS there is no in app link navigation rotor option
<dotjay> Interesting – I’d not noticed before that Link roles aren’t reachable outside of web content. How weird.
I'd need to find an app with links to check
I managed to convince my former company that links in apps where bad for business... perhaps too well
<dotjay> I believe that button purpose perhaps falls under 2.4.6 Headings and Labels as a button’s text label, and 1.1.1 for text alternative to an image button
ACTION: Research link behavior on Android and iOS -> 1. Native link in text, 2. Native link on its own, 3. Web link in WebView
ACTION: Research impact of broadening "link" to "links and buttons" or "interactive components"
<Jamie> keep in mind this is about clarity of text, for navigation purposes. If we feel that 2.4.6 covers buttons then we can leave this as links only
<Joe_Humbert> that was my problem QuintinB I would need to spin up my test app on my test Android device
ACTION: Consider linking to 2.4.6 as best-practice
<JJ> s/ 2.4.6 2.4.9
<dotjay> Re 2.4.6 – For example, https://
<dotjay> “The objective of this technique is to ensure that the label for any interactive component within Web content makes the component's purpose clear.“
Jamie we need to be clear that we means specifcally links or buttons
<dotjay> But I agree that it’s somewhat ambiguous and 2.4.6 does not specifically call out buttons
<Detlev> +1 to Jamie
<Joe_Humbert> on Android, you can use navigation link mod in a native app on Android, I just tested
<Joe_Humbert> link mode*
2.4.6 Headings and Labels
<julianmka> WCAG2ICT seems to interpret 2.4.6 as relating more to content grouping, fwiw
Nice thanks Joe_Humbert - I see my last comapny made them custom actions (facepalm)
Joe_Humbert this might be higher level - the "nebulous" word for descriptive is normative but does not have a definition
Is it a problem that descriptive is not descriptive enough?
<dotjay> +1 Joe_Humbert
<dotjay> +1 JJ
Joe_Humbert 2.4.6 des not talk about context. Labels need to be descriptive, but in links it mentions context
Detlev does programmatic text matter over visible text? e.g. and 'X' that has a label
julianmka in terms of aligning to WCAG2ICT buttons and labels are things that set context. Wcag2ICT isn't really sufficient at the moment buttons and labels also require context
dotjay nothing to add
Illai We need to have a place where button names and form labels are made clear
Jamie forgot for now
<Zakim> JJ, you wanted to Your topic here
oooh
QuintinB likes this
ACTION: Dive deeper into what we would consider a label (button label, link label, etc.)
<Jamie> oh, I remember... Label in name should address programmatic text, right Detlev?
<Jamie> +1 to Illai
2.5.1 Pointer Gestures
<Detlev> @Jamie 2.5.3 Label in name just checks that the visible string is in the accname
<Detlev> Jamie the gap is things like icon buttons with bad name...
<dotjay> Yeah, we should remove anything that references non-web documents in the mobile guidance
<Detlev> @JJ Gestures used to operate the AT or UA are exempt
Joe_Humbert There is an alternative of doing gesture with voice control
<Jamie> +1
<JJ> Pointer Gestures explanation: https://
Detlev This is referring custom gestures by the app developer - voice actions would cut it as it needs single pointer input. e.g. sliders should have arrow buttons
<dotjay> Currently reading the seemingly related issue on WCAG2ICT: w3c/
Detlev devs are responsible for what they build JJ that might not always be the case e.g. pull to refresh
ACTION: Think about if we want to include alternatives for gestures introduced by native mobile components like "Pull to Refresh", or add exception for platform provided technologies
<Detlev> @Joe good poinnt
Sorry Joe_Humbert I missed that
<Joe_Humbert> We should be cautious about requiring developers to fix OS based items that they are not making them inaccessible (they cannot customize the element or control) because this would add extra requiremwnts for the dev by adding custom content