Meeting minutes
<AlainVagner> https://
I can scribe today
<Joe_Humbert> https://
Joe: article on list: Apple does research on automated a11y report generation
… maybe the will improve the a11y of their own tool as well ;)
JJ: indicating extending checks to several screens
… leverage AI Computer Vision
Joe: why do they use AI to identify objects rather than accessing the code?
… code is more accurate
JJ: using private APIs, iphone sharing (mirror on Mac)
… not yet available in EU maybe due to privacy issues
EU with regulations may open up iOS a bit more
View subgroup
JJ: forwarded Email with invitation of AGWG for the View subgroup (result of talk at TPAC about definition of view)
… what does it mean in context of web page, Apps, mobile apps
… may be used in WCAG 3
… if interested please fill in survey w available meeting times
… questions?
Jamie: How much commitment - what is the time line - how long is it going to take compare what we do here?
JJ: not sure - timeline will be defined in subgroup
2.5.8 Target Size (Minimum)
JJ: first discussion was 1 May 2024
JJ shares Issue from GitHub
JJ: Apple and Android have requirement for larger touch targets
JJ: explaining spacing exception in 2.5.8
JJ: continue discussion?
Detlev: go beyond WCAG (target size)?
JJ: stay in line with WCAG2ICT but some notes for best practices could be added
JJ: such as recommending larger sizes, reference developer documentation
JJ: Question was whether we better align with WCAG or WCAG2ICT -- the latter was preferred
Julian: Tell people to choose whatever is the more accessible (eg. decide between WCAG requirement and Android/iOS recommendations).
… Android and iOS are closed platforms where WCAG has no clout - that'S why we could instruct user sdto chosse the better one
JJ: could be trouble to link directly to Apple and Google
Joe: we should not use could language to inform people what they *should* be doing
… could is not used
… we could say it is too small for touch and one could point to triple A guideline without spacing exception
Jamie: as to adding Apple and Google resources: WCAG resources do include references to these
… "for information purposes only"
… not endorsed, but available - we could do it as well
… we are talking about AA 2.5.8 - we can point to AAA as best practice - should not linger longer, this is the AA standard
JJ: most people felt it can be applied 'as is'
JJ: comfortable with accepting as such and add a note to preferability of larger sizes?
<JJ> Add note to 2.5.8 to point people towards resources which recommend larger touch target sizes (such as WCAG 2.5.5, Apple, Google)?
<julianmka> +1
<Karla> +1
<Detlev> +1
<jeroen> +1
<Jamie> a+
<Joe_Humbert> +1
<Jamie> +1
<AlainVagner> +1
<Carolina> +1
Jamie: We would not be using the term CSS-pixels - replace with something else
JJ: may be density pixels or other units that make sense
ACTION: Add note to 2.5.8 to point people towards resources which recommend larger touch target sizes (such as WCAG 2.5.5, Apple, Google)
ACTION: Replace CSS Pixel unit with appropriate unit on mobile such as Density Pixel
JJ: will set up draft version of what guidance would look like
3.2.1 On Focus
JJ: can we keep going through SCs (niot focus on medium variations as suggested by Jamie)?
JJ: (reads 3.2.1 On Focus and add. notes)
… of WCAG2ICT
JJ: (going through examples)
JJ: example that filling out second form field should not force focus to first. ANy comments?
Joe: WCAG2ICT did not change definition of "change of context" even things that explicitly mention "web page"
… we should change the definition
<Joe_Humbert: we need to be able to change definitions
Joe_Humbert: We need to look at user agent and viewport as well
JJ: Structure in WCAG2ICT can be a bit confusing - some wordign changed - but not when applied as written
JJ: Can't remember why this was marked as large variation...
… seems straightforward
Jamie: wondering what the idea of focus was - keyboard focus, SR focus - in the mobile space, voice control ans switch access - do we need to differ from the description in the WCAG context - what tools create focus... that may have been the reason what we were marking it as large variation
JJ: define perhaps what user interface components would be - a label?
JJ: most work would be on the definitions (UIE, change of context)
ACTION: Create Github issue for User Interface Component
ACTION: Create Github issue for Change of Context
3.2.2 On Input
JJ: (looking at WCAG2ICT text for 3.2.2 on input)
… reading intent
… looking at the MATF Github issue
Joe_Humbert: We also need to look at the definition of user interface component, check if we need to modify that
… what is it we think a control is?
JJ: same note about user interface element
JJ: agenda is finnished - any additional topics?
Jamie: what is the next SC?
JJ: (checking which is next - consistent navigation)
Joe: Should be staret a document for "proposed definitions" so we can work outside meetings?
ACTION: Mark Github issues related to Definitions with 'definition' tag
3.2.3 Consistent Navigation
<Jamie> +1 to Joe_Humbert
JJ: WCAG2ICT added a note that while not required SC should be considered best practice
… relates to the problematc definition to "set of software programs" (rather than "set of views")
JJ: In the EN 301 549 it is also considered to change to sets within software
Jamie: If we have a note, the way it is written does not clearly stating the purpose
… seems confusing right now - we should not use the same wording
JJ: if we can view or screen it will be clearer
JJ: We might need an exception because there may be valid reasons to deviate in terms of order
… need ti figure out if exception is needed - may not be needed since note is not normative
JJ: we may also discuss consistent help - applies more to web sites
JJ: will send out minutes after the meeting