- From: David MacDonald <david100@sympatico.ca>
- Date: Tue, 24 Feb 2015 21:43:03 -0500
- To: WCAG <w3c-wai-gl@w3.org>
- Message-ID: <BLU437-SMTP31B72ADB7869A021BE48ACFE170@phx.gbl>
> 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 > > > > 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 > > > > >
Received on Wednesday, 25 February 2015 02:43:36 UTC