- From: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Date: Thu, 26 Feb 2015 16:01:06 +0000
- To: Michael Pluke <Mike.Pluke@castle-consult.com>, "Richards, Jan" <jrichards@ocadu.ca>, David MacDonald <david100@sympatico.ca>, WCAG <w3c-wai-gl@w3.org>, "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>, Jeanne Spellman <jeanne@w3.org>
- Message-ID: <BY2PR03MB272D4E435CA40094D7F54CE9B140@BY2PR03MB272.namprd03.prod.outlook.com>
Ø Like the Access Board we applied WCAG 2.0 to software (thanks to the WCAG2ICT Task Force).
I’m also glad that you have layered in other software requirements that WCAG SC do not specifically address such as interoperability, support for high contrast (11.5), etc. WCAG conformance requirements touch on some of these but they are sometimes omitted from other adopted standards.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto: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: Michael Pluke [mailto:Mike.Pluke@castle-consult.com]
Sent: Thursday, February 26, 2015 10:35 AM
To: Jonathan Avila; Richards, Jan; David MacDonald; WCAG; public-mobile-a11y-tf@w3.org; Jeanne Spellman
Subject: RE: Transition Request for FPWD of Mobile Accessibility
In the standard there are different requirements related to what a platform should provide (11.3.2.1 and 11.3.2.2). I think we had it all covered in that a platform does not (typically) have a direct user interface, so (typically) these requirement wouldn’t apply to a platform. I think that the wording that we used between all these related requirement managed to cover your other points.
Like the Access Board we applied WCAG 2.0 to software (thanks to the WCAG2ICT Task Force). But when we drafted requirements that weren’t directly derived from WCAG 2.0 we opted to choose language that we felt might be most familiar to software engineers (and reflected in platform software documentation). As a result we chose “accessibility services” rather than “keyboard interface”. We believed that this term can be confusing to those unfamiliar with W3C standards as it can so easily focus the reader’s mind on whether or not an actual keyboard is involved – which is often not the point. Even the discussion in this thread between W3C experts seems to lend some weight to that concern.
Mike
From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: 26 February 2015 14:38
To: Michael Pluke; Richards, Jan; David MacDonald; WCAG; public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>; Jeanne Spellman
Subject: RE: Transition Request for FPWD of Mobile Accessibility
> 11.3.2.3 Use of accessibility services:
Where the software provides a user interface it shall use the applicable documented platform accessibility services. If
the documented platform accessibility services do not allow the software to meet the applicable requirements of
clauses 11.3.2.5 to 11.3.2.17, then software that provides a user interface shall use other documented services to
interoperate with assistive technology.
Michael, we discussed this in the task force and this is why we chose the term Keyboard Interface to cover the keyboard aspect of this discussion. I have included the definition of keyboard interface from the working draft of UAAG 2.0 below.
keyboard interface
Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g. a touchscreen-controlled device can have a keyboard interface built into its operating system<http://www.w3.org/TR/UAAG20/#def-operating-system> to support onscreen keyboards as well as external keyboards that may be connected).
Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.
Regarding the language of 11.3.3 this is good for software but leaves some potential questions in my opinion. For example, what if the software is the platform. What if the platform doesn’t provide these services in a way that apps can overcome? What if the platform doesn’t support third party assistive technologies? What assistive technologies are then required to be provided for the platform? Then you have to fall back to the functional requirement of each group of people with disabilities.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto: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: Michael Pluke [mailto:Mike.Pluke@castle-consult.com]
Sent: Wednesday, February 25, 2015 10:21 AM
To: Richards, Jan; David MacDonald; Jonathan Avila; WCAG; public-mobile-a11y-tf@w3.org<mailto:public-mobile-a11y-tf@w3.org>; Jeanne Spellman
Subject: RE: Transition Request for FPWD of Mobile Accessibility
Hi All
When we drafted the European Standard EN 301 549 (Accessibility requirements suitable for public procurement of ICT products and services in Europe) we included the following requirements that seem to be highly related to your issue (and any others where the presence or absence of OS support for accessibility applies) :
“11.3.2.3 Use of accessibility services:
Where the software provides a user interface it shall use the applicable documented platform accessibility services. If
the documented platform accessibility services do not allow the software to meet the applicable requirements of
clauses 11.3.2.5 to 11.3.2.17, then software that provides a user interface shall use other documented services to
interoperate with assistive technology.
NOTE: The term "documented platform accessibility services" refers to the set of services provided by the
platform according to clauses 11.3.2.1 and 11.3.2.2.
It is best practice to develop software using toolkits that automatically implement the underlying platform accessibility
services.”
The clauses 11.3.2.5 to 11.3.2.17 mainly refer to things like making things programattically determinable. In particular 11.3.2.11 and 11.3.2.12 are particularly relevant to David’s (very valid) concern.
11.3.2.11 List of available actions: Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3 make, a list of available actions that can be executed on a user interface element, programmatically determinable by assistive technologies.
11.3.2.12 Execution of available actions: When permitted by security requirements, software that provides a user interface shall, by using the services as described in clause 11.3.2.3 allow, the programmatic execution of the actions exposed according to clause 11.3.2.11 by assistive technologies. (Plus a note referring to the security requirements exception).
I think that these three clauses completely tie up the underlying missing keyboard alternative requirement. The EN 301 549 text is very tightly written to be used in procurement. I am sure that it is possible to write something that captures the spirit of the underlying issue that sounds a bit more like normal English!!
I hope that this helps.
PS. In the latest Section 508 refresh the Access Board seem to have chosen almost identical requirements about the accessibility services that platform software should provide. However, there does not seem to be any obligation on applications to use any services provided! This seems to be a major omission that we so very nearly made until we spotted this big omission at the 11th hour.
Best regards,
Mike Pluke
Castle Consulting Ltd.
76 Cowper Street
Ipswich
Suffolk
IP4 5JA
England
From: Richards, Jan [mailto:jrichards@ocadu.ca]
Sent: 25 February 2015 14:42
To: David MacDonald; Jonathan Avila; WCAG; public-mobile-a11y-tf@w3.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:jon.avila@ssbbartgroup.com>
703-637-8957<tel: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<mailto:david100@sympatico.ca>]
Sent: Tuesday, February 24, 2015 9:42 PM
To: Jeanne Spellman; public-mobile-a11y-tf@w3.org<mailto: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<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<mailto: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<mailto: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<mailto:public-mobile-a11y-tf@w3.org>
> [29] mailto:public-mobile-a11y-tf-request@w3.org<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<mailto:jeanne@w3.org>
>
>
Received on Thursday, 26 February 2015 16:01:46 UTC