- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 25 Sep 2012 21:46:19 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: John Foliot <john@foliot.ca>, David Singer <singer@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Silvia Pfeiffer, Tue, 25 Sep 2012 21:53:59 +1000: > On Tue, Sep 25, 2012 at 9:38 PM, Leif Halvard Silli: >> Silvia Pfeiffer, Tue, 25 Sep 2012 13:06:58 +1000: >> 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. ... > Instead, I was pointing to the request to have a visual encumbrance > for @longdesc, something that Web devs do not want. Browser settings > are outside the scope of Web devs, so don't count in this context. So, > if a web dev wants to provide a long description for an image, but > does not want a visual encumbrance, then they won't use @longdesc > because that implies (at least for some users) a visual encumbrance. The CP did "expect" a the mouse pointer to signal that the image has a longdesc. While visual, would you count such a thing as an *encumbrance*? But apart from that, then I agree: If longdesc caused an encumbrance, by default, then authors would not use it whenever they wanted to avoid encumbrances. When John spoke about how to 'liven up' a @longdesc via javascript that inserts a iframe that can be activated etc, then I think we are then into the subject of progressive enhancement, where the longdesc makes sure that A11Y API users can get the long description also when javascript is not available. And I think that can be a good use case. -- leif halvard silli
Received on Tuesday, 25 September 2012 19:46:56 UTC