- From: Léonie Watson <tink@tink.co.uk>
- Date: Mon, 30 Sep 2013 11:06:45 +0100
- To: "'Charles McCathie Nevile'" <chaals@yandex-team.ru>, <public-html-a11y@w3.org>
- Cc: "'Andrew Kirkpatrick'" <akirkpat@adobe.com>, "Steve Faulkner" <sfaulkner@paciellogroup.com>
Chaals McCathie Nevile wrote: "On exposing longdesc to accessibility APIs things look rather shakier. On the other hand, it is not clear whether the testers were certain what a pass or fail actually was so our results might be unreliable here. It would be helpful to have more testing on APIs, by people who really are clear what is required." I asked the guys at TPG to take a look and Steve F provided the following information... The value of the longdesc attribute doesn't change the way the accessibility APIs handle it, so in terms of accessibility API support it's just a matter of whether the attribute itself is exposed. Firefox exposes longdesc as accDefaultAction;showlongdesc;. Chrome does not expose longdesc on Windows. The assumption is that this will be the same on other platforms, but is currently unverified. Internet Explorer 10/11 exposes the URL of the longdesc as an accessible description. This seems to be a broken implementation. The accessible name should be human readable, and if an accessible description is provided through other means (title, aria-describedby etc.) the URL as accessible name is overridden. Léonie. -----Original Message----- From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru] Sent: 30 September 2013 02:44 To: public-html-a11y@w3.org Cc: Andrew Kirkpatrick Subject: longdec testing update Hi, I realise we haven't formally adopted any tests yet (so please reply to the call for consensus[0]). On the other hand, we have a bunch of results[1] for the proposed tests[2]. On the browser + screen reader side, the results look reasonable. If anyone has IE 11 it would be interesting to see if they have fixed the apparent bugs they have, but it looks clear that longdesc can be implemented interoperably even for corner cases. I'd like to split the results to distinguish between reasonably simple implementations to use, and things that technically pass but shouldn't be considered evidence of good implementation. E.g. without extensions / assistive tech of some kind Opera 12's access is mostly very good, but discovery is poor, and my bare Firefox 23 can only be said to pass some tests because the spec makes no requirement that the UI be effective enough for the real world - although I believe they have improved that. On exposing longdesc to accessibility APIs things look rather shakier. On the other hand, it is not clear whether the testers were certain what a pass or fail actually was so our results might be unreliable here. It would be helpful to have more testing on APIs, by people who really are clear what is required. Finally, there are a few tests for validators. The basic tests come out right, but the test for the "should" requirement of encapsulating longdesc[3] doesn't get picked up by any tool I know. I've cc'ed Andrew, who wondered if we had requirements on this, to find out if he knows of any tool that would at least warn about the error. [0] http://lists.w3.org/Archives/Public/public-html-a11y/2013Sep/0067.html [1] https://rawgithub.com/chaals/longdesc-tests/master/test-results.html [2] https://github.com/chaals/longdesc-tests/ [3] https://rawgithub.com/chaals/longdesc-tests/master/fail-fragment-pointer.html cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Received on Monday, 30 September 2013 10:07:19 UTC