- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Mon, 18 Jul 2016 10:09:00 -0400
- To: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Cc: WCAG <w3c-wai-gl@w3.org>
Sometimes I have run into an issue that prevents use of handwriting feature on an iPhone/iPad when VO is on on a Web page and sometimes in an app. The new SC will cover this. Sailesh On 7/18/16, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: > Ø Non-Interference: > > Ø don't we already have that? > > I tend to agree with Sailesh that I’m not sure interoperability and > non-interference are captured fully with WCAG. From what I understand WCAG > applies to anything that might be served up via HTTP so this could include > Silverlight, Flash, PDF, Java, canvas, etc. I think embedded technologies > are more likely where these issues may come up. The non-interference clause > in the conformance requirements section seems to really be about > technologies that are not used to claim conformance on the page. What if > the technologies are used to claim conformance and they interfere? > > Possible types of interference could include: > > · Slowdowns of AT or crashes > > · Screen corruption of content > > · Overriding audio from the AT > > · Ignoring of system features like high contrast in Java applet or > Flash > > · Ignoring system features like filter keys in applet > > · Ignoring system caret blink rate in Flash or Java > > Some of these things might also fall under accessibility supported – but > right now I don’t think these types of issues are often tested or thought of > for embedded web content. > > Ideally these would also be addressed by any documents that apply WCAG to > non-web ICT. > > Jonathan > > Jonathan Avila > Chief Accessibility Officer > SSB BART Group > jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com> > 703.637.8957 (Office) > Visit us online: Website<http://www.ssbbartgroup.com/> | > Twitter<https://twitter.com/SSBBARTGroup> | > Facebook<https://www.facebook.com/ssbbartgroup> | > Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | > Blog<http://www.ssbbartgroup.com/blog/> > Check out our Digital Accessibility > Webinars!<http://www.ssbbartgroup.com/webinars/> > > From: David MacDonald [mailto:david100@sympatico.ca] > Sent: Friday, July 15, 2016 12:47 PM > To: Alastair Campbell > Cc: Sailesh Panchang; WCAG > Subject: Re: New SC: Avoid disrupting working accessibility features > > don't we already have that? > > Non-Interference: If > technologies<https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#technologydef> > are used in a way that is not accessibility > supported<https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#accessibility-supporteddef>, > 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. In addition, the Web > page<https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#webpagedef> > as a whole continues to meet the conformance requirements under each of the > following conditions: > > 1. when any technology that is not relied > upon<https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#reliedupondef> > is turned on in a user agent, > > 2. when any technology that is not relied upon is turned off in a user > agent, and > > 3. when any technology that is not relied upon is not supported by a user > agent > In addition, the following success criteria apply to all content on the > page, including content that is not otherwise relied upon to meet > conformance, because failure to meet them could interfere with any use of > the page: > > · 1.4.2 - Audio Control, > > · 2.1.2 - No Keyboard Trap, > > · 2.3.1 - Three Flashes or Below Threshold, and > > · 2.2.2 - Pause, Stop, Hide. > > Cheers, > David MacDonald > > > > CanAdapt 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> > > On Fri, Jul 15, 2016 at 12:07 PM, Alastair Campbell > <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote: > Hi Sailesh, > > That’s an interesting idea, I get the goal, but I’m not sure about the > practicalities. > > Just taking keyboard-use as one example, as a developer, would I have to > know all the keyboard short cuts of all operating systems and all screen > readers before applying keyboard commands to a web application? > > It sounds like something that would apply to a closed platform (e.g. iOS) > rather than the web. > > I’m open to examples, but at first glance (on a Friday afternoon 5 minutes > before leaving) I can’t see how it would be possible. > > Kind regards, > > -Alastair > > On 15/07/2016, 16:46, "Sailesh Panchang" > <sailesh.panchang@deque.com<mailto:sailesh.panchang@deque.com>> wrote: > > An SC is needed along the lines of: > • Applications shall not disrupt or disable activated features of > other products that are identified as accessibility features, where > those features are developed and documented according to industry > standards. > • Applications also shall not disrupt or disable activated features of > any operating system that are identified as accessibility features > where the application programming interface for those accessibility > features has been documented by the manufacturer of the operating > system and is available to the product developer. > [Ref: S508 1194.21 Para (b) Softtware Apps] > > This is relevant because authors misapply techniques or implement > them incorrectly / incompletely leading to confusion and > inconsistencies. > > Thanks, > Sailesh Panchang > > > >
Received on Monday, 18 July 2016 14:09:37 UTC