Meeting minutes
Scribe
<JJ> IRC cheetsheat: https://
<JJ> nominate a scribe
<JJ> nominate a scribe
How WCAG 2.2 Relates to Mobile
Touch Target size (2.5.8)
JJ considering moving comments for sheet in a data repo (git)
<Joe_Humbert> I like github, because people can add comments and they are visible
I like Github too, we could use issues for each criteria
<Devanshu> +1
<Mick> +1 for Github, and creating documents for each criteria, will be easier to manage and track.
<julianmka> could we move out of the spreadsheet and into Github fully? I would rather not track 2 places.
agree julianmka
<Joe_Humbert> +1 for not 2 places
I am nothing if not redundant
<Joe_Humbert> I was seeing if anyone was in the queue
JJ confirms to use GitHub
How do we use GitHub? JJ to propose
2.5.8 Target Size
Joe: Pixel conversion: CSS pixel is the native density for the platform.
JJ: We should align with WCAG2ICT
<Mick> I asked this question recently in the MATF slack channel. The consensus was the same - to see 24 pixels being equivalent to whatever the appropriate unit used for other platforms - for iOS this is 24 points and for Android this is 24 density-independent pixels. This is an approach Deque follows as well I believe.
AA: should we just use mm on the screen, as specified by NN?
<Devanshu> WCAG2ICT notes: w3c/
JJ: Android can modify density, so perhaps mm can be difficult
Joe: Can't verify, but it's consistent across devices and settings
<Mick> Would points or density-independent pixels be more helpful to developement teams then using mm?
quintinb: Users can define what they want the physical size to be, the separation is intentional
julian: Should we just follow the platform guidelines? Fingertips are variable in size and not precise. Shouldn't we be advocating for large touch targets?
Rachele: Shouldn't we just reference the AAA requirement?
Joe confirms
JJ: (AA) Spacing can be 24 from another target and then size can be anything
Sorry that was a reference to WCAG_AA not AA the user
<Mick> As an observation - we tried previously pushing Apple and Android sizes to our teams and got so much pushback from designers about it being too big.
<AA> I will make sure to add my name as AAK, to avoid confusion quintinb
ty AAK
quintinb: we also need to be considerate that Google does allow for 32x32dp in seemingly certain cases
JJ: Relying on public documentation can be problematic as the internal algo doesn't necessarily follow the 48x48 rule
JJ: We may have to figure out what Google's math is - maybe someone can look later
JJ A lot of people asking how to check size
quintinb: ADB can be used to extract the ally tree and the density, which can calculate the dp size
<Mick> A physical ruler or sending screenshots and using likes of photoshop. Neither massively accurate but have struggled to find other methods when not having access to code in audits.
JJ: but we need to be understanding of what tools auditors need
Joe: Uses the scanner with larger requirements because it reports the details of what is wrong
<Mick> That's clever Joe_Humbert
agree - thanks Joe - I think I failed to understand previously
Mick has done an audit against 2.2
They have been sending screenshots and measuring with a ruler
1.3.5 Input Purpose
<Joe_Humbert> there is no way to set a custom size in Apple's Accessibility inspector. Also I think the inspector rules are closed source
JOE: In HTML if a first name is registered, but no autocomplete doesn't work then it's a fail
JJ: Should we just add guidance on attributes and how to validate if they are available
Joe: keyboard types might be easier
Joe: Will try research how he can find out how to find autofill attributes
Joe: Where can testers put this dummy data
JJ: will look into MarkDown as a format for the success criteria
Joe: Do we know anyone who has experience writing tests
<julianmka> iOS can set autofill for Safari from any contact. Wondering if that setting propagates throughout apps.
<JJ> Quintin: has experience writing automated accessibility tests
<JJ> JJ: also has experience writing these; with source code access you can certainly extract input type related properties. Without source code access it's harder, believes it's possible on Android but probably not on iOS.