W3C

- DRAFT -

Mobile Accessibility Task Force Teleconference

25 Jul 2014

See also: IRC log

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


<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 version 1.138 (CVS log)
$Date: 2014-07-25 15:03:00 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Otr is it a uber technique/Or is it a uber technique?/
Succeeded: s/make sit clear/makes it clear/
Found Scribe: Jan
Inferring ScribeNick: Jan
Default Present: Kathy_Wahlbin, Kim_Patch, Jeanne, Jan, wuwei, +1.512.596.aaaa, +44.179.281.aabb
Present: Kathy_Wahlbin Kim_Patch Jeanne Jan wuwei +1.512.596.aaaa +44.179.281.aabb
Regrets: Alan
Found Date: 25 Jul 2014
Guessing minutes URL: http://www.w3.org/2014/07/25-mobile-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]