Re: 48-Hour Consensus Call: InstateLongdesc CP Update

Silvia Pfeiffer, Tue, 25 Sep 2012 13:06:58 +1000:
> On Tue, Sep 25, 2012 at 12:21 PM, Leif Halvard Silli:
>> Silvia Pfeiffer, Tue, 25 Sep 2012 11:48:44 +1000:
>>> On Tue, Sep 25, 2012 at 11:04 AM, John Foliot:
>>>> 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.

>>> you can't have it both ways:

>> Did you mean "or it is is accessibility content, then it is not
>> __accessible__ to anything but _screenreader users_" ?
> 
> Yes, screenreader users and any tools that rely on the a11y API of browsers.

>> 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.
> 
> My point was: what if for a particular Website the owner decides that
> the long description is not relevant to be exposed visually, but would
> still like to provide it to the a11y API. Thus, if we *require* it
> both ways, we will end up getting nothing.

I think you point to a problem with the iframe technique: iframe is not 
meant for the A11Y API alone - not unless one isolates it via hidden="" 
and use aria-descriedby="" or similar (why not longdesc=""!) to point 
to it. So using iframe is, effectively, a 'both ways' technique. 

The positive side of longdesc="" and aria-describedAT="" is that they, 
typically, point off-page. I don't know if I understand you correctly, 
but you might be saying that it is problematic if non-A11Y API users 
get access to the longdesc/describedAT link (and thereby to the 
resource that it points to). However, I don't think that this is a 
problem, provided - of course - that the resource is a visible (to 
sighted) resource.
-- 
leif halvard silli