Re: New SC: Avoid disrupting working accessibility features

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