Re: 48-Hour Consensus Call: InstateLongdesc CP Update

Maciej Stachowiak, Mon, 17 Sep 2012 15:48:01 -0700:
>> It comes down to 2 paths forward as I see it: one is that we mandate
>> something that browsers will continue ignore, or we actively engage them in
>> crafting the solution, one that meets all of the user requirements.
>> 
>> I think it's fairly obvious which I hope will be chosen - the "which group
>> dictates to the other" approach is not working. (I will also note in 
>> passing
>> that active listening is a requirement on BOTH parts)
> 
> I think you are right about that. Unfortunately, the conversation 
> still seems to be on mandate-or-no-mandate rather than engagement in 
> crafting a solution.

I did describe a new way this weekend: If @longdesc points to a in-page 
resource, then we have a hash reference. And thus, revealing that 
content - even if its hidden="" - would be covered by Ted's text about 
revealing hidden="" content at user request. If combined with a 
hidden="" <iframe> (here I took some inspiration froma James plus, of 
course Ted's text), then we have a solution for off-page long 
description that works with 

	a) browsers without @longdesc support, 
	b) contextual menu operated @longdesc support, 
	c) screenreaders with (legacy) longdesc support.

Once AT would support revealing hidden="" content that is hash 
referenced, then AT would not need to follow today's praxis (where the 
longdesc resource is viewed in a new browser window) but could instead 
keep the focus on the same page.

Resend the link to my test page, where it is the first test that demo 
the above described coding praxis:

http://malform.no/testing/a-demo-of/longdesc-with-hidden-iframe/
-- 
leif halvard silli

Received on Monday, 17 September 2012 23:31:48 UTC