- From: Detlev Fischer <detlev.fischer@testkreis.de>
- Date: Fri, 25 Jul 2014 17:16:30 +0200 (CEST)
- To: public-mobile-a11y-tf@w3.org
Belated regrets for today and the next few telcos - I am already on holidays and will return to work on 17. August. Detlev -- Detlev Fischer testkreis c/o feld.wald.wiese Thedestr. 2, 22767 Hamburg Mobil +49 (0)1577 170 73 84 Tel +49 (0)40 439 10 68-3 Fax +49 (0)40 439 10 68-5 http://www.testkreis.de Beratung, Tests und Schulungen für barrierefreie Websites Kim Patch schrieb am 25.07.2014 17:07: > > > - DRAFT - <http://www.w3.org/> > > 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> > 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 <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 <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 <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 <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 <mailto: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:16:55 UTC