MATF Minutes 26 March, 2015 from Kim Patch on 2015-03-26 (public-mobile-a11y-tf@w3.org from March 2015)

From: Kim Patch <kim@redstartsystems.com>
Date: Thu, 26 Mar 2015 12:21:09 -0400
To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
Message-ID: <551431F5.2040105@redstartsystems.com>

MATF Minutes 26 March, 2015 link:
http://www.w3.org/2015/01/29-mobile-a11y-minutes.html

Text of minutes:1 <http://www.w3.org/>
Mobile Accessibility Task Force Teleconference

26 Mar 2015

Agenda
<https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Mar/0022.html>

See also: IRC log <http://www.w3.org/2015/03/26-mobile-a11y-irc>

Attendees

Present
Regrets
David_McDonald, Henny_Swan, Alan
Chair
Kathleen_Wahlbin
Scribe
jon_avila

Contents

* Topics <http://www.w3.org/2015/03/26-mobile-a11y-minutes.html#agenda>
1. Comments on note
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Comments_on_Mobile_Accessibility_Note_20150226
<http://www.w3.org/2015/03/26-mobile-a11y-minutes.html#item01>
2. Use Cases
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Accessibility_Use_Cases
<http://www.w3.org/2015/03/26-mobile-a11y-minutes.html#item02>
3. New work on input methods
<http://www.w3.org/2015/03/26-mobile-a11y-minutes.html#item03>
* Summary of Action Items
<http://www.w3.org/2015/03/26-mobile-a11y-minutes.html#ActionSummary>

------------------------------------------------------------------------

<trackbot> Date: 26 March 2015

<Kathy> trackbot, start meeting

<trackbot> Meeting: Mobile Accessibility Task Force Teleconference

<trackbot> Date: 26 March 2015

<Kathy> meeting: Mobile A11Y TF

<Kathy> chair: Kathy

<scribe> scribe: jon_avila

Comments on note
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Comments_on_Mobile_Accessibility_Note_20150226

kw: Take some time to look at new comments and comments that come in on
github. Start with EO comments. KP will look to see where we left off.

<Kathy>
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Comments_on_Mobile_Accessibility_Note_20150226

I'm pretty sure we covered 2.1

kw: Pick up at 1.2.2 at authoring tools. Give example of what an
authoring tool is.

<Kathy>
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Comments_on_Mobile_Accessibility_Note_20150226

kw: will start at 2.2. Zoom and magnfication
... comment to design and develop with these features in mind
... multiple ways that we can provide this. Building it in could be one way.

Jan: thinks this is clear in our document.

<Jan> http://w3c.github.io/Mobile-A11y-TF-Note/

jan: unclear where they got the idea that we are saying that the
document doesn't cover browser options.

kw: maybe we could add something in.

jan: First bullet already covers this.
... section addresses their concern. Support going back asking for
clarification.

kw: will go back and ask for clarification.

<jeanne> JS: I recommend responding that we feel that the concerns have
been addressed in the wiki.

detlev: Perhaps we should describe what browsers need to do to support
font enlargement

mikeP: Doesn't highlight that there are good and bad ways of using the
features.

detlev: say browser vendor wants to know if there is value in adding
font size adjustment to browser. Who is this aimed at? Web content
developers?

jan: one option is where we talk about OS setting we could drop the
capitalization as the commenter suggests

MikeS: perhaps we have the bullet reversed. Perhaps we should say this
is what you should this is what you shouldn't do. We could split. We
should talk about text resize first and then talk about about blocking
pinch zoom.

kw: All agree to change capitalization
... MikeS can you walk Jeanne through moving the bullets around and she
will make changes.

mikeS: Change phrase with 200% to say at least 200%

<jeanne> Use techniques that support text resizing without requiring
horizontal panning. Relying on full viewport zooming (e.g. not blocking
the browser's pinch zoom feature) requires the user to pan horizontally
as well as vertically. While this technique meets the success criteria
it is less usable than supporting text resizing features that reflow
content to the user's chosen viewport size.

<jeanne> Ensure that the browser pinch zoom is not blocked by the page's
viewport meta element so that it can be used to zoom the page to at
least 200%. Restrictive values for user-scalable and maximum-scale
attributes of this meta element should be avoided. While this technique
meets the success criteria it is less usable than supporting text
resizing features that reflow content to the user's

<jeanne> chosen viewport size.

<Kathy> http://w3c.github.io/Mobile-A11y-TF-Note/#zoom-magnification

detlev: varying options may exist -- for example could offer desktop
view with breakpoints.

jeanne: New CSS item called snappoints which allow authors to put in
points that allow the user to snap to certain points while scrolling.

<Mike_Pluke> +1

MikeS: We should be consistent when referring to OS and platform

<Jan> Support for system fonts that follow platform level user
preferences for text size. -> Support for OS text accessibility
settings. For web applications this will depend on browser support.

<Alan_Smith> Sorry, I'm late. Was overbooked.

<Jan> Support for system fonts that follow platform level user
preferences for text size. -> Support for OS text accessibility
settings. For web content this will depend on browser support.

<Kathy> +1

<Detlev> +1

<Alan_Smith> +1

<Mike_Pluke> +1

<HSwan> +1

<marcjohlic> +1

<Kim> +1

ja: say text size settings instead of accessibility text settings.

kw: Can we just say OS text size settings?

<Jan> Support for system fonts that follow platform level user
preferences for text size. -> Support for OS text size settings. For web
content this will depend on browser support.

<Alan_Smith> +1

<tbabinszki> +1

mikeS: Change phrase geared toward to say designed for specific population.

kw: any objections?
... Discussion of point size. Commenter suggests changing point size to
more generic text size.
... comment applies to 2.3

dm: point size refers to 1/72 of an inch on the users device.

detlev: can we talk about measuring on-screen

jan: who hold mobile device closer

detlev: users with low vision may hold device closer just like they look
closer at monitor

<David> http://www.w3.org/TR/WCAG20/#larger-scaledef

<David> Note 3: The actual size of the character that a user sees is
dependent both on the author-defined size and the user's display or
user-agent settings. For many mainstream body text fonts, 14 and 18
point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the
default size for body text (assuming that the body font is 100%), but
authors would need to check this for the particular...

<David> ...fonts in use. When fonts are defined in relative units, the
actual point size is calculated by the user agent for display. The point
size should be obtained from the user agent, or calculated based on font
metrics as the user agent does, when evaluating this success criterion.
Users who have low vision would be responsible for choosing appropriate
settings.

<Mike_Pluke> +q

mikeP: went through these argument in the EU standard. Avoided using
points. Only way to go on large size and then rely on definitions

kw: Any objections to change to large text instead of points?
... hearing none we will make that change and close that out.
... will come back to this conversation next week

<Kathy>
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Accessibility_Use_Cases

<Mike_Pluke> -q

Use Cases
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Accessibility_Use_Cases

kw: Have a small list of mobile use cases. If you think of other things
from user perspective put them in so we can make sure we cover needs of
different people with disabilities and how they interact with their
devices to make sure we have everything covered and cover all the
necessary techniques.
... Please take a look and see if you can add use cases.

New work on input methods

kw: Had good discussion at CSUN on different input techniques. We need
to create list of important techniques/best practices that we need to
create for each of these areas.
... Perhaps we'd put in placeholder where we could link off to for
future editions of this document. Is that correct Jeanne?

jeanne: Yes, that is correct. We could probably link to wiki pages where
we are doing the work of drafting the content.

kw: discussion on charters. Once those are complete we should know more
about direction of how and where things are going to look like.
... Like us to concentrate on techniques and best practices.
... focus on web first (sites and web apps)
... Brainstorm now into github. We will pick this up next week.
... will setup survey where we can start talking about different
techniques. Focus on section #3 operable.
... thanks everybody.

Summary of Action Items

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.140 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015-03-26 16:02:05 $

___________________________________________________

Kimberly Patch
President
Redstart Systems, Inc.
(617) 325-3966
kim@redstartsystems.com

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

Blog: Patch on Speech
+Kim Patch
Twitter: RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________

Received on Thursday, 26 March 2015 16:21:37 UTC