- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 13 Mar 2012 00:56:55 +0100
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Charles McCathieNevile, Mon, 12 Mar 2012 19:29:55 +0100: >> So, the process is the reason we can't say 'use @aria-describedat' ... > > No. The problem is that some important projects are not implementing > the functionality described. Apart from ARIA 1.0, here are some other projects which have failed to include @longdesc in the product: * Opera Mobile - at least, I see no context menu. * Opera Mini - at least, I see no context menu. * Webkit browsers - except desktop iCab * Chromium * Konqueror I don't know about IE for mobile. Or Firefox Mobile - except that it has no context menu. Of mainstream browsers, then desktop Firefox on Windows, IE and Opera have varying degrees and kinds of support. But it is notable that from desktop to mobile, the longdesc feature - or the add-on for it - just 'falls off': in iCab Mobile, in Firefox Mobile, in Opera Mobile and Mini. So support on a deeper level, such as an accessibility layer which is turned on rather than always being available to the user, perhaps *is* the way to go? Btw, I know that the iCab developer is in principle willing to implement @longdesc in the mobile version. But is left to do it via JavaScript plus that there are small screen issues with regard to implementing it as e.g. a button on the image. Apple must be willing before it could happen - at least with Webkit. But VoiceOver on iOS might be another cup of tea ...? > There are reasons for using longdesc as is: it's relatively > well-known, it's relatively well described. There are reasons for > preferring something that does the same with a different name: people > get to say they were right about longdesc being broken as shown > because we move to the new version, longdesc as currently specced in > HTML4 doesn't apply as generally as required. Even for @alt, there are implementation problems. Especially when we consider the other elements - apart from <img> - where @alt is used. [E.g. VoiceOver did not read @alt on <area> when I, earlier in the HTML5 process, checked that.] My hope and belief is that this can improve, *precisely* because of ARIA's systematic approach. Namely: The fact that @alt is included in the accessible name algorithm. Something similar needs to happen with @longdesc as well. So, for @longdesc, then I think that *only good things* can come out of 'the ARIA feature'. It hurts longdesc that 'the ARIA feature' is not there yet. > The specification can be done in a tiny amount of time if that is > needed. May be the PF does not think that that is what is needed? Anyway: I said what I said based on the situation we have. Even if specced tomorrow, there would still be no support for 'the ARIA feature'. Which means that it would be questionable to immediately forbid @longdesc even - *if* - a full move from @longdesc to 'the ARIA feature' is ruled to be the way forward. > But without implementor commitment, it just isn't needed very > urgently. Understanding the basics can be done just as well by > implementing longdesc... I read that as critical remarks towards PF/ARIA > If aria-describedat will get implemented, that is pretty much trumps > for me. But if an ongoing discussion about it is an excuse to do > nothing for a few extra weeks, I'd rather talk about something more > productive. True. We need to see 'the ARIA feature' to be. But we also need to see thing as realistic as possible. > frustrated -- leif halvard silli
Received on Monday, 12 March 2012 23:57:32 UTC