Meeting minutes
<dotjay> Sorry - poor sleep so think I’d make a hash of it
Draft Group Note
JJ: Summarizes progress with the draft. Met with AGWG on Nov 26. Received feedback about adding a link to each issue in GH where we don't have other info.
JJ: Showing markdown he added to automatically fetch content from WCAG and WCAG2ICT when we need direct quotes.
julianmka: Suggested that we follow a similar heading name convention as WCAG and WCAG2ICT to facilitate others who may need to quote our guidance.
3.1.1 Language of Page
JJ: Summarizes SC and discussion to date. Identifies "programmatically determined" as an area for us to clarify.
JJ: Seems like this applies as-is with some clarification in notes.
quintinb: Does this mean an app must support every language supported by the device?
<quintinb> Does this mean that every language on the device needs to be supported by every app?
JJ: If an app only renders in English on a device set to German, would that be a fail? I tend to think the screen reader would use the appropriate voice.
<quintinb> My concern is putting a lot of weight on AT to determine language programmatically
quintinb: Wonder about putting undue burden on app developers, but we also put a lot of weight on the AT experience.
dotjay: As this applies to web pages, it's a way to programmatically communicate the language of the page. We don't expect every page to be available in every language.
dotjay: From this SC, it's about the AT having a way to understand that the app is in German or English, which can be accomplished on an app level. I don't think there's a burden on developers to do more than that.
<quintinb> We also shouldn't be afraid to put on a requirement that current OS's / apps fail - if it's needed it's needed and we just need to defend it
JJ: In Note 1 for this SC in WCAG2ICT, it seems like there are 3 options for how an app could pass
GleidsonRamos: In Android, how do we test this when the language is only available at the device level? It's harder to test with confidence on Android.
JJ: iOS lets you set the language at the application level which would be a pass immediately. To quintinb's point, maybe we would fail an Android app. Or perhaps the 3rd part of Note 1 applies...."Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform “locale
/ language” setting may not be able to meet this success criterion in that locale / language."
julianmka: I'm reluctant to fail a whole platform's worth of apps based on limitation imposed by the OS (and ultimately Google)
quintinb: I agree, but the same thing happens with other SCs, like with focus order.
<quintinb> +1 julianmka - but this is happening with dialog focus with regards to 2.4.3 (https://
<dotjay> For situations like this, where there are OS-level differences, we could perhaps start noting use cases that could go into supporting documentation, a bit like WCAG Techniques documents.
JJ: Does "May not be able to meet" mean "fail" or something else?
<julianmka> +1 dotjay
ACTION: Get clarification on "Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform “locale / language” setting >may not be able to meet< this success criterion in that locale / language."
<dotjay> This way, we don’t end up “forking” the SCs, and rather applying them more generally across OSes.
JJ: Do we need a note to clarify how this applies/doesn't to iOS and Android?
<JJ> Poll: do we add Note to clarify how to meet this SC on iOS, and that there is not equivalent on Android?
<Aashutosh> if we say on Android it is not possible, wouldn't it be our responsibility to write it such that some of the app suceed?
Jamie: Did we talk about individual screen language vs. app language?
Jamie: Are we saying that the human language of the _app_ or _each screen_ must be programmatically determined? In my current company we warn users if they are going to a screen that is not in their chosen language.
<quintinb> I also think we need to consider having something that's a "soft fail" - and appropriately define "soft fail" - or is that just AAA?
<dotjay> Yeah, I don’t think we can change the WCAG Level for an SC.
Illai: It's frustrating to have an SC that people can't meet ever.
JJ: We could say that Android is exempt from this SC, while holding iOS to using the language attribute.
<quintinb> Native apps should be able to meet these criteria. I think apps should fail this and raise an issue on the issue tracker for android
<quintinb> While we call it an OS issue, it's a "system" issue that may not actually be on the OS, and there needs to be an API made available that app devs can use
Illai: We could take the 4.1.2 approach -- if you're using the native language of the platform, you meet that SC.
<quintinb> +1 Illai
<julianmka> +1 Illai
<quintinb> If we admit exception, good luck getting anything out of Google
ACTION: Add Note with exception for Android, and indicating how to meet it on iOS
ACTION: Get in touch with Google about accessibility supported language at app/screen level
<quintinb> Jamie Think of it kind of like auto-captions. It's not perfect, and it's incredibly prone to hindering performance
Jamie: On the user side, VoiceOver and TalkBack have settings for the screen reader language. I've been trying to understand what triggers the automatic language detection. Is this something anyone here has explored?
JJ: This may not be a problem for users because of settings and language detection, but this SC is about what developers do, not what ATs detect/assume.
GleidsonRamos: Spannable strings only work for XML Android, the Jetpack Compose method doesn't seem to work the same way.
GleidsonRamos: We were testing on Android 11, maybe it wasn't supported yet
3.1.2 Language of Parts
<dotjay> Apple have NLLanguageRecognizer which I suspect is responsible for triggering the automatic language detection we see in VoiceOvert: https://
<dotjay> Jamie ^^
dotjay can you add that link to the GH issue?
<dotjay> julianmka: Sure
thanks!
<Jamie> isn't https://
<Jamie> "Starting with Android Studio Giraffe and AGP 8.1, you can configure your app to support per-app language preferences automatically. "
<quintinb> Jamie the app needs to actually support that language - that's the problem. As a user, I can set the language to German, but it may default back to English because the app has no localisation for German
JJ: Summarizes discussion to date, including EN301 549's determination that meeting Language of Parts is impossible for software.
<quintinb> There are localisation files in Android development, if we could programmatically determine via a11y apis which one is loaded, that would solve it
<Jamie> can;t users can only set languages that are available in the OS settings for that app?
<quintinb> it's not about making *developers* lives easier, lol
JJ: Generally, it is possible to set language of parts, but not for all components/all places. Do we say it is not applicable?
ACTION: Decide how we apply this SC, given that it is technically possible, but would impose a burden on developers to use accessibility language supported strings everywhere. Could be added as metadata automatically by Google/Apple when loading localized resources.
<quintinb> I have to drop, sorry!
<JJ> Close the queue
Jamie: Teams I've worked with sometimes state that SCs that cannot be met is due to limitations of the technology. It is still on the dev team to track when things change, but allows a pass for times when developers cannot do something due to the platform technology.
<dotjay> julianmka: w3c/
Jamie: Do we need to add a note about hybrid/web view content?
ACTION: Add note about `lang` tag for hybrid/webview content to pass 3.1.1 and 3.1.2
JJ: yes, web view content should follow web guidance.
julianmka: Also need to consider webview content rendered within a regular view, not just an in-app browser.