Re: why are we pursuing this idea? (was: Implementation Details request on Issue 204 Decision)

Chaals McCathieNevile, Tue, 21 Aug 2012 19:27:38 +0200, in reply to 
Steve:
>> James teh wrote [3]:
>> 
>> "To clarify my position on this: I have no problem with the idea of
>> the longdesc attribute. However, I believe it should be discoverable
>> to *all* users, not just users of assistive technology. This means
>> that the right place to implement this is in the browser (where all
>> users can access it), not in screen readers such as NVDA."
> 
> OK. For what it is worth, I agree 100%. I still think it would be helping
> NVDA users to implement longdesc support.

Given that Steve’s focus on A11Y APIs, then I don't understand that he 
mention this statement by NVDA developer James Teh. What James Teh says 
sounds in theory very correct. But when one thinks about it, then it 
sounds like he demands an egg before he will agree to keep chicken - or 
opposite. Here is why:

* iCab *does* support longdesc. However, VoiceOver has no support for
  it, so is doesn't help that it has been implemented in the browser.
  (VoiceOver works essentially as well with iCab as it works with
  Safari. This is different from e.g. OmniWeb, which is quite 
  broken with regard to VoiceOver. [OmniWeb also implements @alt in
  a way that is more like Firefox, so it seems to modify Webkit
  much more.])

* Also, Firefox has support for @longdesc - I mean: that is Steve’s 
point.
  So why doesn't NVDA have support for it?

From listening what Steve says about other things, then it seems to me 
that the support has to come in the accessibility API first. And for 
@longdesc in Firefox, then the API is ready. Hence, I don't understand 
James Teh's reasoning.

Not my field at all, unfortunately, but of there had been a documented 
way for iCab to extend VoiceOver so that e.g. would announce a longdesc 
as something activate-able, then I pretty sure that developer would 
have done it.
-- 
leif halvard silli

Received on Tuesday, 21 August 2012 19:41:54 UTC