- From: Detlev Fischer <detlev.fischer@testkreis.de>
- Date: Mon, 7 Nov 2016 07:07:34 +0100
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: public-mobile-a11y-tf@w3.org
"Does not block the ability to use the rest of the page" is certainly a very HTML-centric expression and reminds of inaccessible elements embedded in normal page content. More typical for mobile apps would be views (like a drawing area) where the ability to use the rest of the (app) may rest either on still accessible elements on the specific view ( like the typical iOS "done" button) or navigation features of the OS/device (like a fixed back button). So the text of clause 5 certainly does not cover the requirement unambiguously. BTW I guess it's normative too and therefore not subject to changes in v2.1? Sent from phone > Am 05.11.2016 um 15:25 schrieb Patrick H. Lauke <redux@splintered.co.uk>: > >> On 05/11/2016 10:15, David MacDonald wrote: >> I've been looking at the non-interference proposal, >> >> https://github.com/chriscm2006/Mobile-A11y-Extension/blob/d9ecc74431ee5bef084b51256468838b1d9a773a/SCs/m14.md >> <https://github.com/chriscm2006/Mobile-A11y-Extension/blob/d9ecc74431ee5bef084b51256468838b1d9a773a/SCs/m14.md> >> >> it appears we may cover this in WCAG 2 in the conformance requirements. >> >> https://www.w3.org/TR/WCAG20/#cc5 <https://www.w3.org/TR/WCAG20/#cc5> > > For the touch scenario (where a native app can completely override Touch AT's gesture recognition), this is arguably covered by > > "If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page." > > However, it's not clearly called out, and ensuring that (particularly touch) AT isn't blocked/circumvented is not explicitly covered in the list of SCs that still need to apply to all page content (1.4.2, 2.1.2, 2.3.1, 2.2.2). > > I'm wondering if we should add this concern (that we think the SC we're proposing *may* already be covered by this clause 5) to our description of the SC as a note to the working group. Having said all that, not having an SC and instead having the concern addressed by wording that's admittedly buried a bit is not ideal...I know many developers who will simply go through the list of actual SCs and never bother to read the additional stuff... > > P > >> I'm trying to think of a scenario of something not covered in our >> current WCAG Conformance Requirement of non-interence that would be >> covered in our proposal ... I don't have one yet. >> >> Thoughts? >> >> Cheers, >> David MacDonald >> >> >> >> *Can**Adapt* *Solutions Inc.* >> >> Tel: 613.235.4902 >> >> LinkedIn >> <http://www.linkedin.com/in/davidmacdonald100> >> >> twitter.com/davidmacd <http://twitter.com/davidmacd> >> >> GitHub <https://github.com/DavidMacDonald> >> >> 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> > > > -- > Patrick H. Lauke > > www.splintered.co.uk | https://github.com/patrickhlauke > http://flickr.com/photos/redux/ | http://redux.deviantart.com > twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Monday, 7 November 2016 06:08:05 UTC