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-safe
ty.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

T. @LeonieWatson

S. Leonie.Watson

W. tink.co.uk