Re: 48-Hour Consensus Call: InstateLongdesc CP Update

James Craig, Tue, 25 Sep 2012 14:53:14 -0700:
> On Sep 25, 2012, at 5:15 AM, Leif Halvard Silli wrote:
>> James Craig, Mon, 24 Sep 2012 21:10:25 -0700:
>>> On Sep 24, 2012, at 7:21 PM, Leif Halvard Silli:
>>> 
>>>> 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.
>>> 
>>> I don't think that was his point. Getting content a single way is 
>>> only possible by having natively accessible forms of content, like 
>>> accessible SVG, or MathML. Longdesc is a form of alternative content, 
>>> which is, by definition, not a single way.
>> 
>> Did not your accessible SVG example use a lot of ARIA? Is it then 
>> "natively accessible"?
> 
> Sorry, I should have used a better term. Perhaps it'd be better to 
> say "content with embedded accessibility" versus "content with some 
> form of linked accessible alternative."

OK. I see what you are thinking of.

W.r.t. iframe and longdesc, then it is interesting to note that it 
partly is the side effects that are we are after: A link, by 
definition, is optional to follow - and the long description as an 
option, is what we look for. Likewise, you told that screenreader users 
can opt to not read the content of the iframe - which is something of 
the same. And it is as if we see this as a feature in itself - the 
ability to not jump skip the long description.

>> There is a problem here: We can't compare a longdesc="" to iframe. 
>> Longdesc is just a link.
> 
> I don't think that's always the case. Didn't IBM Home Page Reader 
> implement longdesc as a temporary view?

Don't know.

> It may be okay to present 
> longdesc as merely a link, but that shouldn't preclude us from 
> comparing other presentations.

A JavaScript solution that turned an longdesc into a hidden iframe 
could be a cool solution, I think.
-- 
leif halvard silli

Received on Wednesday, 26 September 2012 23:42:03 UTC