See also: IRC log
https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Mar/0003.html
https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Mar/0003.html
<Jan> One of the most common characteristics of mobile devices is the small size of their screens. This limited size places practical constraints on the amount of information that can be effectively perceived by users at any one time, even when high screen resolution might enable large amounts of information to be rendered. The amount of information that can be displayed is even further limited...
<Jan> ...when magnification is used, for example by people with low vision (see “2.2 Zoom/Magnification”).
<Jan> Some methods for helping users to make the most of small screens include:
Jan: wording, added a link to section 2.2, methods rather than best practices
<Jan> 2.2 Zoom/Magnification
<Jan> A variety of methods allow users to control content size on mobile devices with small screens. Some of these features are targeted at all users (e.g. browser “pinch zoom” features), while others tend to be made tend to be available as “accessibility features” targeted at people with visual or cognitive disabilities.
Marc: typo first paragraph tend to be made tend to be available
Jan: should be tend to be made available
<Jan> Should be: tend to be made available
<jeanne> +1, I think it addresses the comments
https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Mar/0003.html
<Jan> Note on reflow: There are important accessibility differences between zoom/magnification features that horizontally reflow content, especially text, and those that do not. When text content is not reflowed, users must pan back and forth as they read each line.
Jan: note on reflow goes beyond editorial, mirrors 2.1
Detlev: qualify text size, Windows phone doesn't have magnification feature
Jan: from developers perspective others do
<Jan> 2.4 Non-Linear Screen Layouts
<Jan> With limited screen “real estate” but a variety of gesture options available, mobile developers have experimented with a variety of screen layouts beyond the conventional web paradigm in which the user begins at the “top” and generally works down. Some mobile layouts start the user somewhere in the “middle” and provide highly dynamic visual experiences in which new content may be...
<Jan> ...pulled in...
<Jan> ...from any direction or the user’s point of regard may shift in various directions as previously off-screen content is brought on-screen.
<Jan> Such user interfaces can be disorienting when the only indicators of the state of the user interface and what is happening in response to user actions are visual.
<Jan> The WCAG 2.0 success criterion related to the issue of non-linear layouts is:
<Jan> • 1.3.1 Info and Relationships (Level A)
Detlev: also 1.3.2 and 2.4.3?
<Jan> Adding: * 1.3.2 Meaningful Sequence
Detlev: any technique to be addressed with the on-screen layout issue?
Jan: starts to get to a point where you need offscreen text or some kind of label to explain what's going on
Detlev: case of web intranet application where you have a processor the several steps, press a button jump to another state where you end up in the middle of a page which is fine in the sense of that's where you want to continue but you have the rest on top so you could scroll up, so you're within the flow of the process, so you know you're in the middle of something. Processes like these –...
... would that be an extension to a mobile technique – what do we want to see here?
Jan: not necessarily mobile specific, also linearization, even if something pulled in from the side sequentially navigating brings you back to where you originally were an elegant way rather than getting to the end and this is over
Detlev: complex thing so we need to be careful how prescriptive any technique would be
agreement accept Jan above changes
<Jan> 3.1 Keyboard Control for Touchscreen Devices
<Jan> Mobile device design has evolved away from built-in physical keyboards (e.g. fixed, slide-out) towards devices that maximize touchscreen area and display an on-screen keyboard only when the user has selected a user interface control that accepts text input (e.g. a textbox).
<Jan> However, keyboard accessibility remains as important as ever. WCAG 2.0 requires keyboard control at Level A and keyboard control is supported by most major mobile operating systems via keyboard interfaces, which allow mobile devices to be operated using external physical keyboards (e.g. keyboards connected via Bluetooth, USB On-The-Go) or alternative on-screen keyboards (e.g. scanning...
<Jan> ...on-screen keyboards).
Jan: talking about row column scanning example
Group accepts against changes above for 3.1
Jan: discussing two notes
Jeanne: add note to bullet point?
<jeanne> Ensuring that touch targets are at least 9 mm high by 9 mm wide, independent of the screen size, device or resolution
<Jan> 3.3 Touchscreen Gestures
Jan: added link and note about keyboard accessibility
<Jan> Note: While improving the accessibility of touchscreen gestures is important, keyboard accessibility is still required by some users and to meet WCAG 2.0 (see “3.1 Keyboard Control for Touchscreen Devices”).
Jan: generally section 5 needs more work. It's the only one that doesn't take any direct reference to WCAG 2.0 SC's, and I think it should
Detlev: do you think there are hooks that can be tied back to?
<jeanne> Jeanne: I share Jan's concern about the lack of links to WCAG in Principle 4
Jan: it's a very limited guideline. Only 2 success criteria. None of them are about parsing.They'll all have to hang off name role and value.
Detlev: giving the appropriate interface if you know you're going to type an email address, nothing to do with robustness. Keyboard.
Jan: at the end of my proposals I don't have proposals in this area, so if someone else wants to take this up
Detlev: should we try to sort out the numbering so we can map to the WCAG numbering? Mixup about which we are talking about?
... ingrained to know that 1 is perceivable etc. But disadvantage is that might force a mapping that's not there
John: what happens if we don't have something that covers a certain section. Are we going to have to address all the WCAG sections in our document?
Kim: add a letter?
Jan: sometimes they cross
Jeanne: parenthetical after so you can tell
Detlev: or keyboard I always think of two and to create some kind of tension to read 3.2…
<jeanne> ACTION: jeanne to research respec properties to change the numbering so that Perceivable is #1. [recorded in http://www.w3.org/2015/04/16-mobile-a11y-minutes.html#action01]
<trackbot> Created ACTION-29 - Research respec properties to change the numbering so that perceivable is #1. [on Jeanne F Spellman - due 2015-04-23].
Marc: 2.2 and 2.3 references OS level and platform level
Jan: user agent, Java virtual machine etc. Is intentional to have both
Detlev: is platform still in there
Marc: 2.2 just above the last paragraph
https://github.com/w3c/Mobile-A11y-TF-Note/tree/gh-pages/Techniques
http://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Mobile_Technique_Template
This is scribe.perl Revision: 1.141 of Date: 2014-12-16 08:53:31 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Kim Inferring Scribes: Kim Default Present: Kim_Patch, Jeanne, Detlev, Marc_Johlic, Jan, +1.703.637.aaaa, jon_avila Present: Kim_Patch Jeanne Detlev Marc_Johlic Jan +1.703.637.aaaa jon_avila Regrets: Kathy Henny Alan Agenda: https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Apr/0010.html Found Date: 16 Apr 2015 Guessing minutes URL: http://www.w3.org/2015/04/16-mobile-a11y-minutes.html People with action items: jeanne[End of scribe.perl diagnostic output]