Re: Transition Request for FPWD of Mobile Accessibility

As we prepare for the CSUN Mobility meeting here are several suggestion I
will be putting forth in the mobile regarding keyboard...

Section 3.3 on Gestures
<add sentence at the end>
Note: In order to meet WCAG SC 2.1.1 any outcome accomplished by a gesture
would need to have a keyboard alternative.
=============

Section 3.4
"Therefore, even when device manipulation gestures are provided, developers
should still provide touch and keyboard operable alternative control
options. "

Could become
"Therefore, even when device manipulation gestures are provided, in order
to conform to WCAG, developers still need to provide touch and keyboard
operable alternative control options.

=====================

Section 3.1 says "keyboard accessibility remains as important as ever"...
but I think that is slightly ambiguous and different from saying Keyboard
accessibility is necessary to conform to WCAG.

=================
end of keyboard suggestions, for reference, here are all the mentions of a
physical keyboard in the document:
===================

Intro

"Have we sufficiently explained why keyboard interface and modality
independent controls are needed in the mobile environment?"
=====================

Section 1.1
"many mobile devices can be connected to an external keyboard and mouse, "

==============
Section 3.1

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).

However, keyboard accessibility remains as important as ever and most major
mobile operating systems do include keyboard interfaces, allowing mobile
devices to be operated by external physical keyboards (e.g. keyboards
connected via Bluetooth, USB On-The-Go) or alternative on-screen keyboards
(e.g. scanning on-screen keyboards).

Supporting these keyboard interfaces benefits several groups with
disabilities:..

============

Section 3.4

"Therefore, even when device manipulation gestures are provided, developers
should still provide touch and keyboard operable alternative control
options. "

===============

4.4 Grouping

... It also reduces the number of redundant focus targets, which benefits
people using screen readers and keyboard/switch control.

===================
5.2 Provide easy methods for data entry. Users can enter information on
mobile devices in multiple ways such as on-screen keyboard, Bluetooth
keyboard, touch, and speech. ...


Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Thu, Feb 26, 2015 at 12:22 PM, Hoffman, Allen <allen.hoffman@hq.dhs.gov>
wrote:

>  Been there, done that, it does.
>
> Basically you can use switch control or just turn voice off after
> activating VO and keep going.  It does change the interface, e.g. you move
> focus from keyboard, didn’t get that same focus without VO running.
>
>
>
>
>
> *Allen Hoffman*
>
> Deputy Executive Director
>
> The Office of Accessible Systems & Technology
>
> Department of Homeland Security
>
> 202-447-0503 (voice)
>
> allen.hoffman@hq.dhs.gov
>
>
>
> DHS Accessibility Helpdesk
>
> 202-447-0440 (voice)
>
> 202-447-0582 (fax)
>
> 202-447-5857 (TTY)
>
> accessibility@dhs.gov
>
>
>
> *This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain sensitive and
> legally privileged information. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution, use or copying of this message is strictly prohibited.  If
> you have received this message in error, please reply immediately to the
> sender and delete this message.  Thank you.*
>
>
>
> *From:* gregg@raisingthefloororg [mailto:gregg@raisingthefloor.org]
> *Sent:* Thursday, February 26, 2015 12:20 PM
> *To:* Neil Milliken; Jan Richards; Hoffman, Allen; David MacDonald;
> Jonathan Avila; GLWAI Guidelines WG org; public-mobile-a11y-tf@w3.org;
> Jeanne Spellman
>
> *Subject:* Re: Transition Request for FPWD of Mobile Accessibility
>
>
>
> Ah
>
>
>
> Got a quick reply from apple and they already have this feature
> (voiceover without voice to allow you to use voiceover with keyboard for
> physical access).
>
>
>
> Someone want to check it out and see if this gives full keyboard access to
> iPhone (or at least as much as Voiceover).  (Apps that create their own
> user interface instead of using the components Apple provides often don’t
> work with Voiceover)
>
>
>
> Gregg
>
>
>
>
>
>   Hello Gregg,
>
>
>
> Thank you for your email. We are happy to let you know that what you have
> requested is already a possibility! VoiceOver allows the user to turn off
> speech with a simple gesture or keyboard shortcut. It is also possible to
> disable the sound effects that are associate with VoiceOver.
>
>
>
> In order to turn speech off, you may perform a three-finger double-tap on
> the screen, or press Control + Option + S on a Bluetooth keyboard when
> VoiceOver is enabled. You will hear VO say 'Speech Off'. If you wish to
> turn off sound effects, you may do so via the Rotor, or by turning the
> setting off in Settings > General > Accessibility > VoiceOver > Use Sound
> Effects.
>
>
>
> With speech turned off, VoiceOver will still behave in the same manner
> which would allow individuals with motor skill impairments to use the
> keyboard to take control of the device.
>
> You can review the list of iOS keyboard shortcuts for VoiceOver here:
> http://help.apple.com/iphone/5/voiceover/en/iph6c494dc6.html.
>
>
>
>
>
> Apple Accessibility
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  On Feb 26, 2015, at 9:35 AM, gregg@raisingthefloororg <
> gregg@raisingthefloor.org> wrote:
>
>
>
> The Keyboard Equivalents  are for the  VOICEOVER GESTURES
>
>
>
> So if you don’t have voiceover activated they don’t work
>
>
>
> And the regular gestures do not allow you to move about on sc
>
>
>
>
>
>
>
>  On Feb 26, 2015, at 2:59 AM, Neil Milliken <Neil.Milliken@bbc.co.uk>
> wrote:
>
>
>
> I am definitely in favour of keyboard access without the voice, however I
> do have a question as to why you would want to use keyboard in voice over
> mode if all of the gestures already have keyboard equivalents in the
> default setting? The reason I ask is as a person with a cognitive
> disability I find the additional steps required by voice over add to the
> cognitive load.
>  ------------------------------
>
> *From:* gregg@raisingthefloororg [gregg@raisingthefloor.org]
> *Sent:* 25 February 2015 17:23
> *To:* Jan Richards
> *Cc:* Allen Hoffman; David MacDonald; Jonathan Avila; GLWAI Guidelines WG
> org; public-mobile-a11y-tf@w3.org; Jeanne Spellman
> *Subject:* Re: Transition Request for FPWD of Mobile Accessibility
>
> I agree with all comments below
>
>
>
> A suggestions
>
>
>
> That everyone interested in IOS allowing keyboard access WITHOUT voice
> send a comment like the following (But not identical — well identical is ok
> but better if it is even ever so slightly different - especially at the
> start)
>
>
>
> send it to
>
>
>
> *Accessibility Team at Apple <accessibility@apple.com
> <accessibility@apple.com>>*
>
>
>
> this list goes to all the right people there and IS READ and considered.
>
>
>
> Multiple comments on the same topic would be very helpful in getting this
> change made.
>
>
>
>
>
>  BRAVO AND REQUEST for  *“KEYBOARD ONLY ACCESS TO IOS”*
>
>
>
> Once again - thanks for all you are doing to implement VoiceOver and make
> / keep it working with all the apps
>
>
>
> REQUEST - Could you create a feature called  “Remote Keyboard Access”
>  that is identical to Voiceover except
>
> 1) the voice is turned off
>
> 2) you double check that all the gestures have keyboard equivalents ( I
> believe that this is already true)
>
>
>
> RATIONALE
>
> Many people with arthritis or other severe physical disabilities would
> love to use the iPhone/iPad but cannot use the gestures.  If the VoiceOver
> keyboard access were available (without the voice) they would be able to
> use the iPhone/iPad not only from an external Bluetooth keyboard - -but
> also from any of their special assistive technologies that can act like a
> keyboard (including morse code, eye gaze, EMG, direct Brain interfaces,
> auto monitoring keyboards, communication devices, environmental controls,
> etc.
>
>
>
> It would seem to be a fairly simple modification to VoiceOver with its
> keyboard equivalents for gestures (just duplicate it with voice turned off)
> - and it would open up a new world for these users.
>
>
>
>
>
> Thanks
>
>
>
> Well that is a bit longer than I thought — but you get the idea.  anything
> that covers this ground or even copies it and endorses the idea  of
>  Keyboard only access to IOS”   adds to the impact.
>
>
>
>
>
> They really do read posts to that email address and consider them.
>
>
>
>
>
> Ciao
>
>
>
> Gregg
>
>
>
>
>
>
>
>
>
>
>
>
>
>  On Feb 25, 2015, at 10:21 AM, Richards, Jan <jrichards@ocadu.ca> wrote:
>
>
>
> Hi Gregg,
>
>
>
> Just clarify:
>
>
>
> - yes, keyboard access is indeed critical on mobile devices and so the
> document states that ("keyboard accessibility remains as important as ever"
> [1])
>
>
>
> - I'm OK with strengthening the wording with adding more musts/shalls, but
> this is only an informative document pointing to the normative WCAG 2.0 SCs
> and your suggested text actually changes what WCAG 2.1.1 says (i.e.
> removing the path exception for those very few functions that require it)
>
>
>
> - and yes, keyboard interfaces are very much distinct from having a
> built-in physical keyboard.
>
>
>
> - but app developers are at the mercy of the platform managers in their
> ability to make use of keyboard input. You mention iOS, but it has the
> issue that its keyboard navigation only works when VoiceOver is on, which
> is annoying for sighted users. And, as far as I know (and last tested),
> Windows Phone does not yet include Bluetooth keyboard support.
>
>
>
>
>
> [1]
> http://www.w3.org/WAI/GL/mobile-a11y-tf/WD-mobile-accessibility-mapping-20150224/#keyboard-control-for-touchscreen-devices
>
>
>
> Cheers,
>
> Jan
>
>
>
> (MR) JAN RICHARDS
>
> PROJECT MANAGER
>
> INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
>
> OCAD UNIVERSITY
>
>
>
> T 416 977 6000 x3957
>
> F 416 977 9844
>
> E jrichards@ocadu.ca <jrichards@ocadu.ca?Subject=Re%3A%20AUWG%20Teleconference%20for%2017%20March%202014%20%28Boston%20time%20has%20changed%20-%20%20please%20re-check%20time%29&In-Reply-To=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E&References=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E>
>
>    ------------------------------
>
> *From:* Gregg Vanderheiden [gregg@raisingthefloor.org]
> *Sent:* February-25-15 10:59 AM
> *To:* Allen Hoffman
> *Cc:* Richards, Jan; David MacDonald; Jonathan Avila; GLWAI Guidelines WG
> org; public-mobile-a11y-tf@w3.org; Jeanne Spellman
> *Subject:* Re: Transition Request for FPWD of Mobile Accessibility
>
> I am a bit confused by some of the discussion about keyboard access not
> being important on mobile devices or gesture based devices.
>
>
>
> *Of course Keyboard access is critical for people being able to use the
> devices and software who cannot use the touchscreen or cannot make
> gestures. *
>
>
>
> *And since ALL of the smartphones HAVE a keyboard interface  — I’m not
> sure why there is any discussion about not keeping this as a prime
> requirement.  *
>
>    - the presence of a physical keyboard is not required.    a Bluetooth
>    or USB interface for keyboards is fine.
>
>
>
> Note that even the iPhone - has both a keyboard interface and keyboard
> equivalents to all of the accessibility gestures — so it is keyboard
> operable fro the Keyboard Interface.
>
>
>
>
>
> If there are mobile devices that have a keyboard interface - but that do
> not have keyboard navigation — then that is the reason for INCLUDING the
> requirement — not excluding it.  (we don’t remove wheelchair access
> requirements because there are some building that don’t have wheelchair
> access).
>
>
>
> NOW - if there area mobile devices that have NO Keyboard Interface — (e.g.
> a phone built into a broach) then the provision could be written to say
>
>
>
>  *“For any device that has a physical or wireless keyboard interface, all
> functionality shall/must be available using the keyboard interface.”*
>
>
>
> That would eliminate any concern about devices that do not have a keyboard
> interface — and also end the confusion about devices that have one — but
> that most people -control through a  gesture or voice or any of the other
> modes that are potentially exclusionary.
>
>
>
>
>
> As to content — it shall/must always provide keyboard access — so that
> those who have devices with keyboard interfaces - can use them to access
> the content.
>
>
>
> (my thoughts/ opinions)
>
>
>
> Gregg
>
>
>
>
>
>
>
>  On Feb 25, 2015, at 9:16 AM, Hoffman, Allen <allen.hoffman@hq.dhs.gov>
> wrote:
>
>
>
> Just my two cents worth after “not” being in the weeds on this.
>
> While mobile platforms for some may not have keyboard support, giving
> guidance on how to improve is great, but clearly stating that keyboard
> interface access is required is critical.  Accepting otherwise would really
> break the keyboard success criteria.
>
>
>
>
>
> *Allen Hoffman*
>
> Deputy Executive Director
>
> The Office of Accessible Systems & Technology
>
> Department of Homeland Security
>
> 202-447-0503 (voice)
>
> allen.hoffman@hq.dhs.gov
>
>
>
> DHS Accessibility Helpdesk
>
> 202-447-0440 (voice)
>
> 202-447-0582 (fax)
>
> 202-447-5857 (TTY)
>
> accessibility@dhs.gov
>
>
>
> *This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain sensitive and
> legally privileged information. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution, use or copying of this message is strictly prohibited.  If
> you have received this message in error, please reply immediately to the
> sender and delete this message.  Thank you.*
>
>
>
> *From:* Richards, Jan [mailto:jrichards@ocadu.ca <jrichards@ocadu.ca>]
> *Sent:* Wednesday, February 25, 2015 9:42 AM
> *To:* David MacDonald; Jonathan Avila; WCAG; public-mobile-a11y-tf@w3.org;
> Jeanne Spellman
> *Subject:* RE: Transition Request for FPWD of Mobile Accessibility
>
>
>
> Hi David,
>
>
>
> I wrote a good chunk of the keyboard section (3.1).  I share your view
> that keyboard accessibility is crucial (and no, we did not intend to treat
> gestures with the WCAG path exception).
>
>
>
> I'm open to tightening up the keyboard accessibility wording where
> appropriate in the next draft (this is just the first public working
> draft).
>
>
>
> That said, there are mobile operating systems that have not yet added
> keyboard navigation support, and so we need to find wording to help app
> developers on those platforms do the best they can.
>
>
>
> Cheers,
>
> Jan
>
>
>
> (MR) JAN RICHARDS
>
> PROJECT MANAGER
>
> INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
>
> OCAD UNIVERSITY
>
>
>
> T 416 977 6000 x3957
>
> F 416 977 9844
>
> E jrichards@ocadu.ca <jrichards@ocadu.ca?Subject=Re%3A%20AUWG%20Teleconference%20for%2017%20March%202014%20%28Boston%20time%20has%20changed%20-%20%20please%20re-check%20time%29&In-Reply-To=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E&References=%3C0B1EB1C972BCB740B522ACBCD5F48DEB012E4B50AC%40ocadmail-maildb.ocad.ca%3E>
>
>    ------------------------------
>
> *From:* David MacDonald [david100@sympatico.ca]
> *Sent:* February-25-15 12:16 AM
> *To:* Jonathan Avila; WCAG; public-mobile-a11y-tf@w3.org; Jeanne Spellman
> *Subject:* Re: Transition Request for FPWD of Mobile Accessibility
>
> The keyboard issue to me is very important. I think the document should be
> very clear that all functionality including gesture outcomes must be
> achievable via keyboard for it to meet WCAG. I don't think this is clear in
> the document.
>
>
>
> The 3.2.3 Consistent navigation issue is not as important to me. All of
> the examples in 3.2.3 understanding are about navigation elements, all of
> our discussion 2001-2006 when this success criteria was being formed were
> about navigation in the days when there were not many templates, and so I'm
> nervous about any interpretation that over reaches that. But it is
> something that could be addressed in revision.
>
>
>    Cheers,
>
> David MacDonald
>
>
>
> *CanAdapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
> On Tue, Feb 24, 2015 at 9:56 PM, Jonathan Avila <
> jon.avila@ssbbartgroup.com> wrote:
>
> David, when you say show stoppers – are you saying that these are show
> stoppers for putting this out for public comment as a working draft or show
> stoppers that must be addressed before non-working draft publication?
> Please let us know.
>
>
>
> In regards to your concern with 3.2.3 -- the WCAG understanding page for
> SC 3.2.3 states:
> <http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-consistent-locations.html>
>
> The intent of this Success Criterion is to encourage the use of consistent
>  presentation and layout for users who interact with repeated content
> within a set of Web pages and need to locate specific information or
> functionality more than once.
>
>
>
> This sounds very pretty similar to what we have and thus the mobile
> document seems consistent with other WAI guidance – to be specific our
> current understanding documents do talk about consistent presentation and
> layout already – so the mobile document is not pushing WCAG any more than
> is already done.
>
>
>
> Jonathan
>
>
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com
>
>
>
> 703-637-8957 (o)
> Follow us: Facebook <http://www.facebook.com/#%21/ssbbartgroup> | Twitter
> <http://twitter.com/#%21/SSBBARTGroup> | LinkedIn
> <http://www.linkedin.com/company/355266?trk=tyah> | Blog
> <http://www.ssbbartgroup.com/blog> | Newsletter <http://eepurl.com/O5DP>
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* Tuesday, February 24, 2015 9:42 PM
> *To:* Jeanne Spellman; public-mobile-a11y-tf@w3.org
> *Subject:* Re: Transition Request for FPWD of Mobile Accessibility
>
>
>
> I've read top to bottom and agree with almost everything... there are a
> few important issues
>
> ​and a few nits
>
> .
>
>
>
> ​The important show stopper issues are:
>
>
>
> -ambiguity about the need for keyboard alternatives for gesture actions in
> section 3.3 and section 4.6
>
> -a creep on WCAG requirements for consistent navigation SC 3.2.3 in
> section 4.2 which could impact the meaning of 3.2.3 and 3.2.4 in WCAG
>
>
>
> There are a few other nits that are not show stoppers for me.
>
>
>
> A walk through with details below:​
>
>
> ======================
>  I think 3.3 needs a bullet with explicit mention that every touch gesture
> should have a keyboard equivalent, although there is a bullet in 3.4 about
> this it's not clear that this is necessary for 3.3 issues in the mobile doc.
>
> perhaps there is no mention of a keyboard equivelent requirement because
> of the exemption in 2.1.1
> "except where the underlying function requires input that depends on the
> path of the user's movement and not just the endpoints. (Level A)"
>
> This WCAG exemption was intended for drawing programs and when the user
> uses a mouse to draw something...I don't think the exemption should apply
> to gestures even though they depend on the "user's movement between
> endpoints".
>
> ==================================
> I think the mention of keyboard in 3.4 is a bit soft ... It says "should"
> rather than "must"
> "Therefore, even when device manipulation gestures are provided,
> developers **should** still provide touch and keyboard operable alternative
> control options.
>
>
> =====================
> Section 4.2
> "Components that are repeated across multiple pages should be presented in
> a consistent layout....Consistency between the different screen sizes and
> screen orientations is not a requirement under WCAG 2.0."
>
> This infers that consist component layout is required within screen sizes.
>
> I don't think this is quite what WCAG was getting at with SC's 3.2.3,
> 3.2.4.
> 3.2.3 was really just about left
> **
>
> navigation
> **
> menus, rather than components, and 3.2.4 was about labeling and
> identification rather than placement. I'm not saying that authors shouldn't
> place other things consistently
> , but I think this could lead to confusion about Consistency as it is
> required in WCAG
> , which it isn't  from my memory of those discussions and the current WCAG
> text.
>
>
> 3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on
> multiple Web pages within a set of Web pages occur in the same relative
> order each time they are repeated, unless a change is initiated by the user.
>
> 3.2.4 Consistent Identification: Components that have the same
> functionality within a set of Web pages are identified consistently. (Level
> AA)
>
>
> I think section 4.2 of the mobile requires some rewriting
> to correct this confusion.
>
>
> ====================
>
>
> - the following sentence about orientation is confusing to me. I read it 4
> times and am still not sure what it means.
>
> "Therefore, mobile application developers should try to support both
> orientations. If it is not possible to support both orientations,
> developers should ensure that it is easy for all users to change the
> orientation to return to a point at which their device orientation is
> support"
>
> It's the part about "ensure that it is easy for all users to change the
> orientation to return to a point at which their device orientation is
> support"
>
> that confuses me...
>
>
>
> ========================
>
> 4.4
> This sentence confuses me
>
> "When multiple elements perform the same action or go to the same
> destination (e.g. link icon with link text), these should be contained
> within the same actionable element. "
>
> I guess it means, put the lined image and image text in the same anchor.
> But I had to read it 4 times.
>
> ================
>
> 4.5
> -Conventional style: Underlined text for <add>inline</add> links, color
> for link
>
> ======================
>
> 4.6
> "Therefore, instructions (e.g. overlays, tooltips, tutorials, etc.) should
> be provided to explain what gestures can be used to control a given
> interface and **whether** there are alternatives. "
>
> I think the word *whether* leaves it ambiguous whether there need to be
> keyboard alternatives. I think WCAG requires keyboard alternatives for all
> gestures.
>
> ================
>
>
>
> Cheers,
>
> David MacDonald
>
>
>
> CanAdapt Solutions Inc.
>
> Tel:  613.235.4902
>
> LinkedIn
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
>   Adapting the web to all users
>
>             Including those with disabilities
>
> If you are not the intended recipient, please review our privacy policy
>
> On Tue, Feb 24, 2015 at 12:53 PM, Jeanne Spellman <jeanne@w3.org> wrote:
> >
> > Judy,
> >
> > The Mobile Accessibility Task Force of the Web Content Accessibility
> Guidelines Working Group (WCAG WG) and the User Agent Accessibility
> Guidelines Working Group (UAWG) requests approval to transition "Mobile
> Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile"
> to First Public Working Draft. This is planned as a W3C Note.
> >
> > Title:
> > Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to
> Mobile
> > Shortname:
> > mobile-accessibility-mapping
> > Version ready for publication as FPWD:
> >
> http://www.w3.org/WAI/GL/mobile-a11y-tf/WD-mobile-accessibility-mapping-20150224/
> > Editor's Draft
> >
> > Estimated Publication Date:
> > Thursday 26 February 2015
> >
> >
> > == Abstract ==
> >
> >    This document, “Mobile Accessibility: How WCAG 2.0 and Other
> >    W3C/WAI Guidelines Apply to Mobile” describes how the Web
> >    Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] and
> >    its principles, guidelines, and success criteria can be applied
> >    to mobile web content, mobile web apps, native apps, and hybrid
> >    apps using web components inside native apps. It provides
> >    informative guidance, but does not set requirements. It also
> >    highlights the relevance of the User Agent Accessibility
> >    Guidelines 2.0 [UAAG20] in the mobile context.
> >
> >    This document is intended to become a Working Group Note and is
> >    part of a series of technical and educational documents
> >    published by the [20]W3C Web Accessibility Initiative (WAI).
> >
> >      [20] http://www.w3.org/WAI/
> >
> >
> > == Status of This Document ==
> >
> >    This section describes the status of this document at the time
> >    of its publication. Other documents may supersede this
> >    document. A list of current W3C publications and the latest
> >    revision of this technical report can be found in the [21]W3C
> >    technical reports index at http://www.w3.org/TR/.
> >
> >      [21] http://www.w3.org/TR/
> >
> >    This document is a First Public Working Draft by the Mobile
> >    Accessibility Task Force (Mobile A11Y TF) operating under the
> >    terms of its [22]Work Statement under the joint coordination
> >    and review of the[23] Web Content Accessibility Guidelines
> >    Working Group (WCAG WG) and the [24]User Agent Accessibility
> >    Guidelines Working Group (UAWG), which is part of the [25]Web
> >    Accessibility Initiative (WAI) of the [26]World Wide Web
> >    Consortium (W3C). This document is intended to become a [27]W3C
> >    Note.
> >
> >      [22] http://www.w3.org/WAI/GL/mobile-a11y-tf/work-statement
> >      [23] http://www.w3.org/WAI/GL/
> >      [24] http://www.w3.org/WAI/UA/
> >      [25] http://www.w3.org/WAI/
> >      [26] http://www.w3.org/
> >      [27] http://www.w3.org/2004/02/Process-20040205/tr.html#WGNote
> >
> >    Feedback on this draft is essential to the success of this
> >    guidance. The Mobile Accessibility Task Force asks in
> >    particular:
> >     1. Is this document helpful in understanding the applicability
> >        of WCAG 2.0 and UAAG 2.0 to the mobile environment?
> >     2. Is the format of this information helpful for designers,
> >        developers and testers of content that can be viewed with
> >        mobile devices and in mobile apps? Is it useful for
> >        policymakers?
> >     3. In Appendix A, is listing relevant existing WCAG 2.0
> >        techniques helpful for mobile content and mobile app
> >        developers?
> >     4. Are there additional accessibility needs in the mobile
> >        environment related to the WCAG principles that we should
> >        address?
> >     5. Have we sufficiently explained why keyboard interface and
> >        modality independent controls are needed in the mobile
> >        environment?
> >
> >    To comment on this document, send email to
> >    [28]public-mobile-a11y-tf@w3.org ([29]subscribe, [30]archives)
> >    or [31]file an issue in Github. Comments are requested by 26
> >    March 2015. In-progress updates to the document may be viewed
> >    in the [32]publicly visible editors' draft.
> >
> >      [28] mailto:public-mobile-a11y-tf@w3.org
> >      [29] mailto:public-mobile-a11y-tf-request@w3.org?subject=subscribe
> >      [30] http://lists.w3.org/Archives/Public/public-mobile-a11y-tf/
> >      [31] https://github.com/w3c/Mobile-A11y-TF-Note/issues
> >      [32] http://w3c.github.io/Mobile-A11y-TF-Note/
> >
> >    WCAG 2.0 is a stable web standard. Comments on this document
> >    will not affect WCAG 2.0 wording.
> >
> >    Publication as a First Public Working Draft does not imply
> >    endorsement by the W3C Membership. This is a draft document and
> >    may be updated, replaced or obsoleted by other documents at any
> >    time. It is inappropriate to cite this document as other than
> >    work in progress.
> >
> >    This document was produced by a group operating under the [33]5
> >    February 2004 W3C Patent Policy. The group does not expect this
> >    document to become a W3C Recommendation. W3C maintains a
> >    [34]public list of any patent disclosures made in connection
> >    with the deliverables of the Web Content Accessibility
> >    Guidelines Working Group and also maintains a [35]public list
> >    of any patent disclosures made in connection with the
> >    deliverables of the User Agent Accessibility Guidelines Working
> >    Group; those pages also include instructions for disclosing a
> >    patent. An individual who has actual knowledge of a patent
> >    which the individual believes contains [36]Essential Claim(s)
> >    must disclose the information in accordance with [37]section 6
> >    of the W3C Patent Policy.
> >
> >      [33] http://www.w3.org/Consortium/Patent-Policy-20040205/
> >      [34] http://www.w3.org/2004/01/pp-impl/32212/status
> >      [35] http://www.w3.org/2004/01/pp-impl/36791/status
> >      [36]
> http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential
> >      [37]
> http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure
> >
> >    This document is governed by the [38]1 August 2014 W3C Process
> >    Document.
> >
> >      [38] http://www.w3.org/2014/Process-20140801/
> >
> > == Delta specification ==
> >
> > This is not a delta specification.
> >
> >
> > == Decision to publish: ==
> > UAWG:
> https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Feb/0006.html
> > WCAG:
> https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Feb/0019.html
> > Mobile-A11y-TF:
> http://www.w3.org/2015/02/19-mobile-a11y-minutes.html#item03
> >
> > --
> > _______________________________
> > Jeanne Spellman
> > W3C Web Accessibility Initiative
> > jeanne@w3.org
> >
> >
>
>
>
>
>