Meeting minutes
[JJ shares agenda]
JJ: are there topics someone wants to add?
Time picker
JJ: last week I shared the results of the meeting matrix: Wednesday best for Europe / Asia / US
JJ: times weren't clear in the surveys as daylight saving time happened between when we first started and today
JJ: so I opened a Calendly, which adjusts to your timezone taking daylight savings etc into account
JJ: we'll likely end up with one meeting for Europe/Asia and one for Europe/US
hdv: do the options include US / West coast? seems like most are earlier in the day?
JJ: there should be at least one suitable time for west coast in there
How WCAG 2.2 relates to mobile
[JJ shares screen]
JJ: some of the remarks in this doc are from 2022
JJ: we added the SCs and then in columns A to G it's WCAG, then in column H we tried to determine whether it's applicable, and in J to mobile native, and in J how to fix or apply the work
<QuintinB> I would like to spend some time going through this - I'll probably do it in notes
<QuintinB> Ah right comments - yeah comments are nice
JJ: I'm trying to work out how we could work together in this doc…with more people may get trickier
<Joe_Humbert> Who are the “we” that worked on the spreadsheet?
Aastutosh: the comment feature seems like a viable option to go
<QuintinB> If something gets out of hand, maybe then make a new sheet?
JJ: seems comments works best let's go with that
JJ: there's a lot filled in already in the doc, would be good to look at columns H and I in the spreadsheet and comment if you disagree / have thoughts
Jamie: is this something we'd go through at once or go through them one by one?
JJ: depends on the criteria, some have more comments than others
hdv: repeats Joe's question
JJ: me, and Mick and Neema
Jeanne: it was having issues for me in the COGA meeting as well
Joe_Humbert: was having issues with IRC
Jeanne: it was having issues for me in the COGA meeting as well
JJ: and Kim Patch as well
JJ: would be nice if folks take a look in the next couple of days
JJ: please let me know if you don't have access yet
JJ: then… there's also a second tab, which is about what's missing in WCAG… would probably be input for WCAG 3
JJ: any questions so far?
Carolina: should we only comment when we disagree? so not commenting means we agree?
JJ: yes would probably works best to only comment when you disagree
[yay replace works]
Mick: should we get rid of the guidelines?
JJ: probably be good to keep them for now
Joe_Humbert: with WCAG2ICT, are they providing some language changes?
Joe_Humbert: to fit non web content? wonder if we could do something similar?
JJ: they do things like replace “sets of web pages” with “set of software”
<Jamers> WCAG2ICT did not consider "set of native apps" to be a thing
JJ: maybe mobile web views and apps
Facilitators group
JJ: had a meeting with TF facilitators earlier… they mentioned about the US DOJ, confirming to WCAG 2.1… multiple remarks from other facilitators, for mobile apps they refer to WCAG2ICT and don't include any exceptions to success criteria, which is currently done in Section 508 and in Europe
JJ: they are saying WCAG 2.1 has been around for long enough. We had some discussion about this earlier today. ADA, as I understand, would apply for government apps and apps the government bought
Joe_Humbert: title II is for government, but title III is also for companies
<QuintinB> It would be nice to understand what applies to public bodies vs private companies
JJ: so would they remove exceptions?
Joe_Humbert: government like to have less standards, so it seems likely they would try and align
1.4.4 Resize text
JJ: question: does resize text apply?
JJ: what's interesting is that OS settings can be used for this… with websites, this works differently
JJ: with apps it is trickier to determine the percentage…and in iOS there is dynamic font sizing now
JJ: that makes it even harder to determine how much textt even has scaled. And we cannot inspect tex
QuintinB: what's completely missing… not sure how it works in iPhone but in Android, because we have scale independent sizes, we could set a minimum font size. This has been missing from WCAG since forever
<Joe_Humbert> On io
QuintinB: so you could say this is the smallest we allow and then go to scaling
<Joe_Humbert> on iOS they have typography in the human interface guidelines that give the pt size for all font styles and font sizes
JJ: wonder if we can add some kind of recommendation in guidelines
Carolina: if we're able to scale / zoom in and out, would only one be required or both of them?
Carolina: on iOS I use large, on Android I use the maximum
Carolina: do we need to allow for both?
joe_humbert: do you mean in hybrid situations?
Carolina: I mean if you have the web view should you be able to pinch zoom and out?
<QuintinB> The Evinced MCAG reduces everything to pixel sizes, maybe that is a logical way to go
<QuintinB> I do think we need to have a "standard minimum" font size
JJ: another issue is that WCAG uses CSS pixels wjhich for apps you'd ned to convert
<Jamers> I would strongly suggest to drop the "200%" spec from a mobile interpretation; 200% or 2x is very web-based thinking particularly for larger heading font styles
Karen: in the passed we said we should not disable scaling
Karen: but others say now that as long as magnification works that suffices, have you discussed that here?
<QuintinB> I don't think relying on magnification because that may be seriously inconvenient for many people
JJ: don't think we have discussed that here
JJ: is it sufficient if an app has its own resizing mechanism?
<julianmka> If the device supports actual text scaling through setting, apps should support that capability.
<QuintinB> agree with julianmka
<QuintinB> But at what point does it need to support the font size without loss of content or functionality?
JJ: the bold font setting is also interesting, lots of users (10%) use it we found in research
<QuintinB> woah - can we get references for that?
<JJ> Bold text stats: https://
<QuintinB> I love me some sweet sweet data
<QuintinB> thanks
<julianmka> "But at what point does it need to support the font size without loss of content or functionality?" -- show it all, let users determine whether it's functional/meets their needs
<Mick> Also agree with julianmka
<Jamers> +1 julianmka
<Jamers> making it a part of the SC
JJ: in iOS / Android there is a limit too
<QuintinB> It would be interesting to know how the web folks arrived at 200%
JJ: not sure if there is a limit on websites
<Jamers> +! QuintinB
<QuintinB> Android can be done via ADB, it's just a multiplier as a float value
JJ: there are all users who decrease font sizes
Julian: could we include some kind of statement that when an OS supports a specific AT or accessibility setting, that app developers should support it?
<JJ> Mobile Device Features sheet: https://
Julian: we often hear about users with edge cases…
Joe_Humbert: should be careful about 'should' vs 'must'… eg there could be features that are newly released and developers might not have time to explore new features before they are released, could take months
Julian: valid point
<QuintinB> On the other hand, you get settings that don’t get respected for months, to the point where the documentation actually says that it’s not usually respected because developers don’t know about it (e.g. android time to react)
JJ: maybe we can fort certain features, like text scaling, but not others
<QuintinB> Sorry, years, not months
<Mick> Could state support must be given for a certain OS version, so not to put pressure around new releases
Jamie: are you sharing the doc because you feel it should be updated?
JJ: would be good to keep an eye on new features and discuss in these meetings how we deal with the new features
JJ: in the European rules there are a lot of requirements around user preferences, like color preferences
<Joe_Humbert> I think with Assistive technology/settings we could recommend a support timeline. Like support new AT within 1-2 years, but not sure that follows other specs/notes
hdv: is it EN 301 549?
<Jamers> I don't see Full Keyboard Access on the linked document, which is available since 1OS 14. Did I miss it?
JJ: yes, 3.2.1 of that
JJ: feel free to add any features that are missing
How to test single key shortcuts?
JJ: this is specifically how do we test this in apps? and how do people do it in websites? I also don't know how you would do it on websites?
JJ: there are some default ways in iOS to find out
Rachele: for web there are bookmarklets that press all the keys for you, that seems not possible for apps
QuintinB: I'm working on figuring out how to test this
QuintinB: it is hard to find out discover shortcuts
Joe: there are tools to emulate keyboard, that may theoretically be possible, not sure if realistic
JJ: this is the Accessibility Scanner app by Google. which runs an accessibility service
<Mick> Some other options in web - look for shortcut instructions in the content, check the code for keydown, keyup and keypress listeners, and of course press all the keys
hdv: Rachele's strategy of using bookmarketls is smarter, would recommend that, but if all fails you could manually press all the keys, that should work for apps too
JJ: could be cumbersome
JJ: we probably want to write an understanding-doc for testing success criteria for apps with one or more ways to test a criterion
JJ: on web auditors can look at the source code for answers, with apps you can't unless you are given access to the source code
JJ: maybe something to discuss in the next meeting
Mick Keane: my experience is that I don't have access to the source code usually, and this is the most challenging part
JJ: when I audit I don't use the source code
JJ: equivalent to bookmarklets for websites would be automated testing, eg generic code to send key commands etc and apply this to any app… maybe interesting to build some kind of repository with some automated options
<julianmka> Create a decision tree to guide testing methods?
hdv: maybe solution to source code vs not would be: you can never audit based on source code, because what you're testing is the UI that exists when the source code result is executed
<Joe_Humbert> I think we need to be careful will only end result testing. For things like roles in accessible names. End user result can be almost the same
hdv: you'd always need to test what the user sees, not what the source code in theory would do
<QuintinB> If you want to check out some of what I am doing for keyboard testing: https://
<Joe_Humbert> thank Quintin
Joe_Humbert right, but if there's a difference, wouldn't you need to test the result instead of the source code?
RRSagent meeting, please
RRSagent end meeting, please
<Joe_Humbert> yes. Just need to be careful. Not disagreeing with you