<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

<Jatin> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.0_Techniques_Applicable_to_Mobile_without_Changes

<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