Meeting Minutes 25 Jul 2014 - Mobile A11y Task Force from Kim Patch on 2014-07-25 (public-mobile-a11y-tf@w3.org from July 2014)

From: Kim Patch <kim@redstartsystems.com>
Date: Fri, 25 Jul 2014 11:07:00 -0400
To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
Message-ID: <53D27294.50201@redstartsystems.com>

W3C <http://www.w3.org/>

- DRAFT -

Mobile Accessibility Task Force Teleconference

25 Jul 2014

See also: IRC log <http://www.w3.org/2014/07/25-mobile-a11y-irc>

Attendees

Present
Kathy_Wahlbin, Kim_Patch, Jeanne, Jan, wuwei, +1.512.596.aaaa,
+44.179.281.aabb
Regrets
Alan
Chair
Kathy Wahlbin
Scribe
Jan

Contents

* Topics <http://www.w3.org/2014/07/25-mobile-a11y-minutes.html#agenda>
1. 2. Research on minimum text sizes on different displays (Jan)
<http://www.w3.org/2014/07/25-mobile-a11y-minutes.html#item01>
* Summary of Action Items
<http://www.w3.org/2014/07/25-mobile-a11y-minutes.html#ActionSummary>

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

<trackbot> Date: 25 July 2014

<Kathy> meeting: Mobile A11Y TF

<scribe> Scribe: Jan

<Kathy>
https://www.w3.org/WAI/GL/wiki/Creating_a_conforming_alternate_version_for_a_responsive_web_page_designed_with_progressive_enhancement

KW: Big question is that this is about progressive enhancement...but did
it have mobile implications?
... Let's read...

JR: It can be boiled down to the Procedure...

Check enhanced versions of the web page contain a link to the
"Conforming Alternate Version".

Check that the alternate version is a conforming alternate version of
the original page and that it conforms to WCAG 2.0 at the claimed
conformance level.

JS: Doesn't seem like progressive enhancement, nothing about screen size

Gavin: Don't agree with it, satisfies with text version.

JR: Needs to have accessible path through to the link

JS: What about functionality

Gavin: We have used progressive enahncement...eg. caroussel to list

http://www.w3.org/TR/WCAG20/#conforming-alternate-versiondef

KW: Big question for WG....
... Removes all styles, scripts... what does it mean for responsive
design site?
... Sometimes in responsive desing, multiple versions of things appear
on base page and script selects which one

Gavin: Should take into account scope of testing...

<jeanne> responsive image sizes would be wrong, without any scripting

Gavin: Only reason not to assume CSS, Script

JR: Doesn't seem that mobile specific

Gavin: I need to get a bit more into this before I comment, but
something doesn't sit right

<jeanne> Jan: What about progression pages, wouldn't the user complete
the simple page and then click to go to the next page, and then be back
in the complex pages, and have to go back and get trapped.

KW: What should be our response? Publish or not or with changes?

<jeanne> JR: What sc is this associated with? Or is it a uber technique?

KW: Do we need to do anything for mobile?

Gavin: Depends on how mobile website is created...media queries, etc.

<jeanne> JS: I think advising developers that they can accomplish
accessibility by stripping a page of all styles and scripts is a step
backward for accessibility.

KW: This tech has gone through several iterations....started as create
conforming alterantive version

JS: I have a number of concerns...in description area, the message that
comes through clearly is that you can do accessibility by stripping
everything out
... On mobile side i'm concerned about responsive image

JR: I'm also concerned about all the stuff at the top that makes it look
like this tech has lots of meat and then the procedure makes it clear
that its just a link to the accessible version

KW: OK I will take back the concerns
... This is still something being discussed in WG
... A lot of back and forth

2. Research on minimum text sizes on different displays (Jan)

http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2014Jul/0006.html

<KimPatch> Jan: I went looking for something that would mention minimum
text sizes and found this US federal aviation Association human factors
design standard the talked about the size of displays in terms of
degrees -- if it's far can be bigger really close to your eye can be
smaller. I scaled that for what would that be at 50 cm (tablet) and 30
cm (smart phone)

<KimPatch> Kathy: so seems like the 1.5 multiplier is actually good

<KimPatch> Jan: it seems reasonable

<KimPatch> Gavin: many different cross related things between mobile Web
best practices and mobile web application best practices -- I only
touched on the BBC future mobile guidelines and WCAG

<KimPatch> Gavin: 1.4.4 and what is seen as an alternative in mobile web
practices to resize. UAAG also, still in draft at the moment good stuff
related to zoom, 1.8.5 and 1.8.7

http://www.w3.org/TR/2013/WD-UAAG20-20131107/#sc_185

<KimPatch> 1.8.5 help users to orient through the viewpoint

<KimPatch> This is really what we do with mobile phone

<KimPatch> Gavin: more focused on Zoom on the mobile side of things
except best practices which focuses on relative phone sizes

<KimPatch> Gavin: this is a little dated -- concerned that we have
examples that are up-to-date

<KimPatch> Gavin: thoughts on maintaining the technique or advice given
that we should always specify text size with percentages (Jan's) or let
the device

<KimPatch> Jan: even if specified, will be overwritten and can stretch
it, but that means a lot of panning around. That's where the reflow comes in

<KimPatch> Jan: UAAG 1.8.7

<KimPatch> Jan: for that em's are better than pixels still

<KimPatch> Gavin: so panning isn't acceptable?

<KimPatch> Jan: just lots more movement

<KimPatch> Gavin: you can double tap to resize

<KimPatch> Jan: there's also keyboard alternatives for these, it's not
the, it's doing it every time

<KimPatch> Gavin: iPhone overrides

<KimPatch> Jan: iPhone and android platforms are dumb, just zoom, but
the browser also re-flows

<KimPatch> Gavin: but not if it's pixels?

<KimPatch> Jan: it does pixels as well, but then you run into container
issues

<KimPatch> Gavin: can get truncated -- that's the point that I should
have mentioned on this email. Can get difficult.

<KimPatch> Gavin: the technique that we need to put in is to maintain
the ability -- best practice to retain relative size compared to an
absolute unit but possibly add something in there in relation to fixed
containers or content may be truncated or obscured from site, if reflow
using pinch and zoom

<KimPatch> Jan: the already is a technique the talks about the fixed
size, but we should inject some mobile language into that

<KimPatch> Kathy: technique that says we should have a minimum font size
on mobile

<KimPatch> Jan: tiny text is 1.9 mm high. Huge text is 4.8 mm. the tiny
text is 22 arc minutes so as far as the FAA is concerned, big enough to
meet what is required for critical display elements

<KimPatch> Gavin: I'm trying to grasp is from a developers perspective
-- they use CSS so it's what size they would be developing in is at 14
to 18 point?

<KimPatch> Jan: WCAG 2 doesn't require minimum text size, just says for
contrast if 18 and over or if your bold and 14 or higher than you can
also qualify

<KimPatch> Jan: maybe should be advisory -- if you're using really small
text there's going to be more pinching -- your design is going to be
morphed more than usual

<KimPatch> Kathy: it also depends on what color you are using. During
usability studies gray text is always a problem no matter what it falls
out as far as contrast ratios. Have to magnify the screen larger than
you typically would if the text was a different color. That would hold
true on mobile as well. If we've got text the color also indicates what
the minimum size would need to be. If it's gray...

<KimPatch> ...text you would have to increase it larger because it's
harder to read.

<KimPatch> Gavin: which size the normal size would be in relation to 2.6
mm or would that depend on the actual viewport or size of the phone

<KimPatch> Jan: my phone, which is a little bigger than an iPhone, it
comes out to 2.6 mm

<KimPatch> Gavin: for developers, you must use the minimum font size of
let's say 6, and then when viewed on different devices is going to be
different sizes and give a different user experience. So if you develop
the same, say 16 point size on an iPad or mini, is it going to be
different, or do you take the point size as well as the viewing distance
from the screen and make that a requirement

<KimPatch> Jan: one point is 1/72 of an inch. So it's invariant, same if
it's a phone or TV. Same with arc minute. It's a degree of your visual
field.

<KimPatch> Jan: advisory, translate to degrees, then translate to
millimeters and say for a smart phone it's this in a tablet it's this.
This is not a minimum, but know that the more you go beyond this the
more pinch zooming, re-flowing will change your interface

<KimPatch> Kathy: if I change it from tiny to small to large does it
proportionately change the text size based on what it is or is it
actually changing it to a fixed size on most mobile devices? is it fixed
or relative to what you already have?

<KimPatch> Jan: I can do some testing

<KimPatch> Jeanne: it used to be relative, that used to be the way we
recommended, but it may have changed

<KimPatch> Kathy: we need to see how mobile devices in general are
handling that both from her browser and OS setting. If we recommend
minimum size -- is this already in the devices. What is the implication
of that depending on different settings

<KimPatch> Gavin: I think this is the reason WCAG didn't specify font sizes

<KimPatch> Kathy: mobile needs this

<KimPatch> Gavin: developers need as much guidance and advice as
possible, may be varying device guidance

<KimPatch> Kathy: WCAG 's general. Maybe notes about specifics. We need
more research on this.

<KimPatch> Kathy: discussing meeting time

<KimPatch> Kathy: a lot of work ahead of us writing techniques so
there's a lot we can do outside of the meeting time as well

<KimPatch> Kathy: next steps -- we have a few items to go over still. I
started creating a summary sheet with a list of all the techniques we
need to create based on our recommendations. We will review that list
and bring that to the UAAG and WCAG working groups before we start
writing techniques. probably some we can start writing right away,
others will discuss back and forth. We will have folks start...

<KimPatch> ...writing techniques, then present in the group and discuss.
Once they are done they go back to the working groups for review, and we
cycled back. The working group has a publication schedule for techniques
and we have to figure out how to coordinate with that.

<KimPatch> Kathy: we will intermix techniques we are modifying versus
new, so we can get the ones we feel are most important for developers
out now.

<KimPatch> Kathy: I'll be sending out items to look at, please look at
before next week

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.138 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2014-07-25 15:03:00 $

------------------------------------------------------------------------
[End of scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
diagnostic output]
--
___________________________________________________

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 Friday, 25 July 2014 15:07:30 UTC