RE: A11y for Web App Sec Anti clickjacking spec

Thanks for this, Léonie.  It was nice to meet you as well, and we really appreciate your and the WAI's taking the time to review our spec.

The canvas used to render the "control image" for obstruction testing will never be accessible to the user, so those concerns are moot.

Below is the text I've added based on this feedback.  I think the UA implementers should have an easier time telling if A11Y technologies are enabled in the browser, because they are coding "from the inside", even if no external APIs are exposed.  As a final fallback, we suggest that UAs should provide a way to disable the obstruction check manually if it interferes with users' chosen A11Y technology.

-Brad
9.1 Accessibility Technologies
Certain classes of accessibility technologies such as screen readers will provide strong defenses against many classes of UI Redressing attacks by presenting the content to the user in a manner not subject to interference. Such user agents should set the unsafe attribute of the UIEvent interface as this may be interrogated by client applications doing feature detection, and should ignore X-Frame-Options headers when presented in combination with UI Safety directives in a Content Security Policy.
Use of accessibility technologies must not cause the input-protection heuristic to be triggered. Accessibility technologies that modify the appearance of a resource, such as screen magnifiers or color and contrast modifications to the display have the potential to interfere with the obstruction checkif not applied in a consistent manner to both the user image and control image. To prevent this inteference, user agents should apply accessibility transformations to the control image. If a user agent is able to detect that accessibility technologies are in use that cannot be applied uniformly as part of the obstruction check, the check must be disabled.
User agents should provide a means for the user to manually disable enforcement of the Input Protection Heuristic if it interferes with their chosen accessibility technologies.





From: Léonie Watson [mailto:tink@tink.co.uk]
Sent: Sunday, November 18, 2012 7:01 AM
To: Hill, Brad
Cc: public-webappsec@w3.org; w3c-wai-pf@w3.org
Subject: A11y for Web App Sec Anti clickjacking spec

Brad,

It was good to meet you and the Web App Sec WG at TPAC. Thanks for inviting PF to work with you on the accessibility of this specification:
http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html

Our assumption is that screen readers afford a measure of protection against some clickjacking techniques, because of their reliance on HTML (rather than what's visible on screen). This should be tested when any example use cases become available though.

One instance when this behaviour is likely to influence the spec is when HTML5 canvas is used as part of an obstruction check. The method used to hide the canvas content off screen should render it invisible to screen readers as well. Either visibility:hidden; or display:none; should do the trick.

Assuming there is no intention for the canvas to be available to the user, its accessibility is a moot point. If that's not the case though, the following notes might prove helpful.

You can include HTML elements inside the canvas element. This fall back content is keyboard navigable, and you can create relationships  between the rendered canvas and elements within the HTML.

You can define a path around an object in the canvas and bind it to an element in the fall back content. This creates a location that can be used to pass mouse events through to the fall back content (hit testing).

If you don't define paths, the hit testing is handled by the canvas. Anything without a path is routed to the canvas element, and the mouse event is routed to the handlers associated with it.

When you associate a path with a fall back element, it can be used to form a rectangle that can be exposed to the browser's accessibility API. For example, a screen magnifier would be able to zoom in on a targeted area of the canvas.

In terms of the visual appearance of content to be compared in an obstruction check, canvas isn't subject to CSS styling or adaptations such as high contrast mode. The challenge will be preventing a false positive from being triggered when legitimate accessibility adaptations have been made to the on screen content.

Microsoft has introduced a proprietary CSS3 media query for detecting high contrast mode in Windows8/IE10:
http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx

Otherwise, I haven't been able to find other methods for detecting high contrast or increased text size adaptations at the UA or OS level. It may be that the browser vendors can offer some suggestions for detecting adaptations made within the browser, but detecting the presence of assistive technologies like screen magnifiers isn't viable.

This may mean catch 22. If it isn't possible to detect accessibility adaptations there is no way to disable the policy (and that has security implications as an action anyway of course), but if the policy isn't disabled the likely outcome is a false positive trigger.

Léonie.


--
Léonie Watson

E. tink@tink.co.uk<mailto:tink@tink.co.uk>
T. @LeonieWatson
S. Leonie.Watson
W. tink.co.uk