- From: Jeanne Spellman <jeanne@w3.org>
- Date: Fri, 25 Jul 2014 11:15:58 -0400
- To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
And the link to the minutes as a web page is: http://www.w3.org/2014/07/25-mobile-a11y-minutes On 7/25/2014 11:07 AM, Kim Patch wrote: > 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> > ___________________________________________________ > -- _______________________________ Jeanne Spellman W3C Web Accessibility Initiative jeanne@w3.org
Received on Friday, 25 July 2014 15:15:59 UTC