Meeting minutes
<mitch11> Thanks @bruce. It's not a respiratory illness, but a different kind of voice disability which I'm getting treatment for. No discomfort, just quiet voice
Announcements
maryjom: Subgroups on closed functionality and command line/text have completed spreadsheet for WCAG 2.1, 2.2 A/AA success criteria.
… Now drafting areas where updates are needed
… Would expect in the next week or 2 the subgroups should have draft content for review by the wider task force - a survey will be created and added to issue for those tasks
maryjom: Question on review of CR.
Chuck: End of July, hope to say 2.2 are published. Have 4 available slip days, so any significant changes will push into August. Right now, on track for end of July
maryjom: Once that is finalised we can move forward on WCAG 2.2 issues
… (apart from target size which we have already started due to link with CSS pixels)
Project standup and planning
maryjom: Sharing project board on github. All progressing well. Will come back to reflow once we have resolved target size and CSS pixels
… Reflow is the last SC for WCAG 2.1
… Today will discuss target size
Survey results: 2.5.8 Target Size (Minimum) draft review
<maryjom> https://
maryjom: We previously had a survey. No additional answers, but link is included above
<maryjom> w3c/
maryjom: Latest comment has all discussion assimilated
… changes included user agent or platform software
… Spacing and inline bullets had changed in latest 2.2 CR draft so these were included, along with the additional note from the CR. None had web language so can stand as is
… Then took notes from Phil, and subsequent notes from Mitch and incorporated them into the comment, but separated non web software and non-web hardware
… Also included a note for closed functionality to be produced by the sub group
… Definitions to add for this SC - need to add bounding box and pointer inputs (for apply to all). Also target (for items with specific guidance)
mitch11: New concern: Looks like we have copied notes from CSS pixel into target size. I'm not sure we should have done that
mitch11: The work on refining the text is good, it just may not appear here (target size) and should instead be in CSS pixels
maryjom: Agree - once we've refined it, we should just leave it in the definition and remove the duplicate notes from target size
bruce_bailey: equivalent bullet refers to "on the same page" which needs to be fixed
… The word substitution may be slightly more complicated
maryjom: Using the substitution from the definition - let's see if that works
<maryjom> Equivalent: The function can be achieved through a different control on the same [non-web document or content presented by software] that meets this criterion.
<bruce_bailey> agree that "on" needs to be "in"
<bruce_bailey> thanks Mary Jo for the walk thru and close review -- i missed this detail in issue thread
Definition uses [non
<loicmn> I think it would work as "... different control in the same [non-web document or sofware] that meets this criterion.
Definition uses non-web document or content presented by software...
mitch11: Agree it needs a substition, non-web document is fine. One candidate is "non-web document or software". But that is a big general
loicmn: Agree with mitch - non-web document or software
<maryjom> Equivalent: The function can be achieved through a different control in the same [non-web document or software] that meets this criterion.
bruce_bailey: Makes sense, but need to change on to in
<maryjom> Equivalent: The function can be achieved through a different control [in the same non-web document or software] that meets this criterion.
mitch11: It doesn't say web page. Does it give more leeway?
mitch11: Page doesn't always translate to screen, so software may be the best substitution
RESOLUTION: Equivalent: The function can be achieved through a different control [in the same non-web document or software] that meets this criterion.
mitch11: Back to the other sub (in the definition), the substitution may also need work
… as software can open other software, or web pages, or ...
loicmn: I think the current proposal works (non-web document or content presented by software) - for the definition note it works as is
mitch11: I wouldn't object. More a wordsmithing than a strong concern
<loicmn> +1 to mitch11 simplification "the same content"
mitch11: or just use "content" rather than non-web document. or content presented by software
<maryjom> If two or more targets are overlapping, the overlapping area should not be included in the measurement of the target size, except when the overlapping targets perform the same action or open the same [content]
<maryjom> Poll: modify definition as stated above, replacing "page" with "content"
<loicmn> +1
<FernandaBonnin> +1
<ShawnT> +1
<bruce_bailey> +1
<mitch11> +1
<Mike_Pluke> +1
+1
<maryjom> +1
RESOLUTION: modify definition as stated above, replacing "page" with "content"
maryjom: Now consider patrickhlauke's comments - nit picks in CSS definition pixel definition. They overlap with target size
patrick: Windows it is not device-independent pixels, but effective pixels
FernandaBonnin: will find out what term is used internally in Microsoft
patrick also doesn't believe that platforms always define their units with reference to some visual angle
Patrick's comments: w3c/
FernandaBonnin: Concern - if we give examples, we don't know if they are defined with reference to a visual angle. There is also a link between notes 2 and 4
maryjom: If we move all these notes from the SC 2.5.8 to the definition, then I don't think these comments change 2.5.8
bruce_bailey: Checking if patrick is correct - target size between 2 iPhones. It does seem to be correct. But agree that these should all be in the same place (in definition)
mitch11: Does it make a difference? Yes - if you have a watch/phone/tablet - all similar touch devices, but size should be based on how you see it and how you touch it.
… On previous worked examples, differences could be significant, but they work for AA as that just requires 20 some pixels, rather than platform at 40 some pixels. But it could be significant for AAA
… These techniques are not dubious, just rather imprecise
… That may be the best we can do, and we should do it.
q:
maryjom: Don't think that any of this discussion changes SC 2.5.8 as we are moving content to the definition.
<bruce_bailey> i agree with Mitch's point that "dubious" is not fair, we are merely being imprecise
PhilDay: The example that was given was added for discussion - so may need work or removal
<maryjom> Poll: 1) Keep the example size calculation or 2) Remove it?
<Mike_Pluke> 2
mitch11: As written, we should pull it, mm are confusing, if they are CSS pixels, or physical mm may be misleading as it might not be that accurate
<bruce_bailey> i also agree that, at AA, SC is just requiring 24 px so that is well below actual touch target sizes on devices
<mitch11> 2
<bruce_bailey> 2
<FernandaBonnin> 2
RESOLUTION: we will remove the example above
maryjom: Taking into consideration those changes, we should be OK with SC 2.5.8. Move notes to definition, remove the example, and change definition of target.
<maryjom> Draft resolution: Incorporate 2.5.8 Target Size (Minimum) with the changes we agreed on today.
<bruce_bailey> +1
<loicmn> +1
+1
<ShawnT> +1
<Mike_Pluke> +1
<FernandaBonnin> +1
<maryjom> Changes agreed - Software notes 1 and 2 are on the definition of css pixels, remove the example, and modify definition note for target as discussed today.
<mitch11> +1
RESOLUTION: Incorporate 2.5.8 Target Size (Minimum) with the changes we agreed on today. Software notes 1 and 2 are on the definition of css pixels, remove the example, and modify definition note for target as discussed today.
<mitch11> +1
Zakim: next item
CSS pixel definition
<maryjom> w3c/
maryjom: We will return to discussion on CSS pixel definitions
Mitch last week had suggested changes to notes - can you step through them please?
mitch11: Happy to. At the bottom of the comment I summarised the notable changes
mitch11: One was an attempt at nomenclature - borrowed 'visual angle pixel' from CSS3. We could also use device independent pixels
… Added bullet point about something could be defined but not documented
… Next was an attempt at kiosk/POS/office equipment situation - use the reference pixel for that. What I am saying is that for systems that define the pixel, it might be different to the CSS pixel. If it doesn't define, then use reference pixel
… Finally added note that low vision users hold things closer, and why we don't then use a very close distance as it has consequences
maryjom: For next time, I'll put a survey out this particular comment to review the individual notes and if we agree
mitch11: 3 main qs. Do we like the term visual angle pixel. 2) how do we handle platform defining it. 3) how handle when platform does not define it
maryjom: Other places that use device independent pixel, may not use the visual angle from CSS pixel, so device independent may be better
maryjom: Ending there due to time. Will incorporate those qs in the survey
maryjom: We are getting closer...
<bruce_bailey> agree we are getting closer !
<Chuck> +1 similar thoughts
mitch11: It's either something like this, or we're not going to solve it!