See also: IRC log
<Kathy_> meeting: Mobile A11Y TF
<scribe> Scribe: Detlev
Kathy: We are behind schedule
KW: Have to do one per week
... Please respond to emails asking for feedback for finalising
SCs
<patrick_h_lauke> (early warning: need to duck out early from this call for childminding)
KW: Your feedback is
critical
... Have to finalise Accidental activation and touch target
today - othwerwise will be finalised on list
<Kathy_> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_revision_of_2.5.3
KW: Last week we made revisions to Accidental activation SC
DMD: We need the language of the
SC itself - many things can be revised later, like examples and
benefits
... Broad strokes most important
KW: But get language right
... Any concerns regarding other aspects of SC (benefits
etc.)?
... Not going back to SCs that have already been sent to WCAG
WG
... Focus on Accidental activation and touc htarget today
... Any comments?
... Consider this final?
DMD: Note should be added to collect feedback
KW: Resolution: SC No Accidental Activation has been accepted, ready for WG review
<Kathy_> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_Target_Size
KW: Next one is Touch Target
Size
... A lot of back and fortth, changes, info on evidence,
diverging recommendation
... Question to input sizes for touch and mouse/pencil
activation
... Please read SC text no, for a few miutes, then let's
discuss
... Comments on coarse and fine pointing accuracy?
PL: As commented research papers
have a lot of grey areas - studies were in controlled
environments with fixed size screens - our issue is that we
don't know usera' device size
... That's why we focus on CSS pixels
... Size for web buttons on small mobile devices may be
excessive - viewing distance should be taken into account
(closer usually with phones, so larger relative size)
... Research is interesting but data from Apple / Google /
Microsift guidance possibly more relevant
... Apple goes for 44 (like BBC), Google goes for 48 px - 50
would be a round number
... We just pickled 20 px with no clear guidance, could make it
25 px (half od large pointer target size)
q*
CM: does 24 / 46 make sense if ratio / scaling od CSS pixels is added?
LP: Depends on dpi of device
<patrick_h_lauke> getting lots of interference on the line
<patrick_h_lauke> i'm call-in 3 and am muted
<patrick_h_lauke> detlev might be your line
PL: 44 px is a good value - the issue with too little buttons on screen referred to a much larger value (150 px)
<patrick_h_lauke> 50's good for me
KW: MIT study arrived at 44-57 px - my preference would be at the higher end, say 50 px
DMD: agrees
... Better to start with a larger requirement and then reduce
it in negotiations than the othe rway round
<patrick_h_lauke> 50 / 26
PL: different terms effective pixes, density pixels all map onto CSS pixels
<jeanne> +1 50 and 26
<chriscm> +1 50 and 26
KW: Any objections to 50 / 25 pixels?
<dmacdona> DO we want 26 or 25 for the small?
MJ: The most relaible thing woulf be using actual millimeters but we have no way of measuring it across devices - hopes that manufactures CSS calculations are correct
PL: usinf CSS pixels will be more accurate because there is no way of testing it across devices
MJ: Similar issue with contraast, actual screen contrast on different devices
PL: Same way device differences cannot be factored in
KP: does it more sense to pick 24/28 px?
CM: No technical reason to pick one over the other - would there be less pushback if measures match Google's suggestion?
KW: We have some evidence from research that larger target sizes make things easier - device manufacturers have different values anyway - so we cab just as well round to 50
PL: Problem migh rtbe that 48 would already fail where Google suggests the nearly identical 49 px could be annoying
DMD agrees
KW; that happened with color contrast, ISO standard slightly lower
<marcjohlic> +1 to 48 as our starting point
CM: Developers would leave ot at 48 if 50 is required
detsiled calculations of pix vs. mm conversions, too much to script)
PL: difference betwee 50 and 48 px is less than .4 mm
<patrick_h_lauke> 24/48
<chriscm> +1 48 and 24
<jeanne> +1 48 and 24
<Jatin> +1 48 and 24
+1
RESOLUTION: target size is 48 and 24 px
<patrick_h_lauke> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_Target_Size
KW: Change to definition of CSS pixels under Related Glossary additions or changes - please have a look nw
<patrick_h_lauke> yeah current definition is slightly back-to-front
PL: CSS pixel definiton should have addition in brackets (when the page is using the device'S ideal viewpoint)
viewport, not viewpoint
<patrick_h_lauke> https://www.w3.org/TR/CSS2/
PL: pointer spec references CSS
spec
... should not be defined sepearately but part of the SC
text
<patrick_h_lauke> https://www.w3.org/TR/pointerevents/
KW: Changes text / definition
CM: for natiove apps CSS px is useless - there are conversions though
KW: Focus is web stuff now - if applied to nave there would be more about conversion to native environments
PL: A note could be added to point to the resp. native environments and their terminologies
KW: Description, evidence, examples, testability (new) - may be change to ideal viewport needed?
PL: makes sense
... Question about "larger than vs. larger or equal to"
KW (changes text)
KW: Any other changes
needed?
... Can we finalise this?
<patrick_h_lauke> ship it!
+1
<jon_avila> agree
RESOLUTION: SC Target Size is accepted
<Kathy_> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements
KW: Schedule for SC
submission
... Kim is working on Speech SC
... PL is working on several - need to reassign work?
KP: Three SC on speech - feedback
is welcome, mail Kim
... it's M12
<patrick_h_lauke> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements
KW: M12 is empty
KP: On main wiki page -
KW: put on timeline
document
... Patrick - split soemtzhing off? Will chat to Detlev
Chris
I can pick something up
KW: Will package the ones now agreed
PL: There were questions on WCG
WG call about touch with AT on - comment it might be too
specific, reference to desktop / keyboard with AT on
... Wonders whether it is worth merging the Touch + AT and
Keyboard + AT to a more generic SC
KW: We shoulf stick with what we
have now, can be merged later by WG
... First get feedback, then revisit after Dec 1
... closes call
<patrick_h_lauke> need to shoot off
Jatin: Looking for a technique for mobile accessibility ? (not fully understood by scibe)
<Kathy_> https://www.w3.org/WAI/GL/mobile-a11y-tf/MobileTechniques/
<Kathy_> https://www.w3.org/TR/mobile-accessibility-mapping/
Jatin: Applicable to native mobile?
KW: respective applicability should be visible on techniques
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Detlev Inferring ScribeNick: Detlev WARNING: No "Topic:" lines found. Default Present: patrick_h_lauke, Detlev, Jatin, davidmacdonald, jon_avila, marcjohlic Present: patrick_h_lauke Detlev Jatin davidmacdonald jon_avila marcjohlic Found Date: 01 Sep 2016 Guessing minutes URL: http://www.w3.org/2016/09/01-mobile-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]