Re: 48-Hour Consensus Call: InstateLongdesc CP Update

Silvia Pfeiffer, Tue, 25 Sep 2012 11:48:44 +1000:
> On Tue, Sep 25, 2012 at 11:04 AM, John Foliot <john@foliot.ca> wrote:
>> James Craig wrote:

>> I'm more concerned about a link in that hidden frame, or perhaps 3 or 4
>> links, and how/what will happen with tab-focus.  For a screen reader to be
>> able to afford the user the ability to fire a link, it must first receive
>> tab-focus. Yet those tab-focusable links are hidden to the sighted user.

>> 
http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-visible

> you can't have it both ways:
> 
> Either it is visible content, then it is created by Web Devs to be
> visible and thus also accessible.
> 
> Or it is accessibility content, then it is not visible to anything but AT.

Did you mean "or it is is accessibility content, then it is not 
__accessible__ to anything but _screenreader users_" ? Because, like 
John said, a link inside an iframe, would be accessible for a keyboard 
user. He or she would therefore 'get lost' when the tab 'took off' 
somewhere he/she couldn't see (i.e. behind the image). (From that 
angle, it is perhaps an advantage that @longdesc does not cause the 
image to become focusable - it prevents that something steals focus.)

So I don't think John's concern is "how to have it both ways". Rather, 
it is how to make sure that users only get it a single way.

When using longdesc, then only those users that uses a tool that 
supports longdesc will get to the longdesc document. And if that 
document contains links, then they should not cause problems. Whereas 
if the same links are inside the hidden iframe, then it might occur 
confusing to those that experience the tab focus disappearing somewhere 
they don't know.

> That the content in the document that you are referencing from
> @longdesc can be both, does not mean that it will be both through a
> single attribute. If our main use case is accessibility - as I
> understand it is - then the second use case is the important one and
> we need an a11y attribute (preferably an @aria-attribute). In this
> case we can encourage the Web Dev to further also expose the document
> visibly through other markup means. I think this is the only realistic
> way of solving this double use case.

James and John debated longdesc vs iframe. In a debate about longdesc 
vs aria-describedAT, then if the latter is more A11Y specific than 
@longdesc, then it is only because it lives in ARIA, which is a A11Y 
specification. Yes, it is true that the longdesc CP "expected" browser 
to reveal longdesc to all users. However, even so,  it introduced no 
hidden focus problems, as iframe does (unless authors take care).
-- 
leif halvard silli

Received on Tuesday, 25 September 2012 02:23:24 UTC