Re: Call for Consensus (CFC) to move forward the HTML5 Image Description Extension spec for publication (FPWD)

Snipping liberally again for brevity…

On Nov 27, 2012, at 4:10 PM, Charles McCathie Nevile <chaals@yandex-team.ru> wrote:

>> embedded content should maintain its own accessible alternative, as
>> demonstrated in the SVG+ARIA example.
> 
> Totally agree. And serious props to you guys for making something real out of that, plus apologies for my unnecessarily snarky comment the first time around.

No worries, I didn't take it as snarky.

> But it won't readily retrofit into <img> as used on the Web for the last couple of decades.
> 
> That would need something like EXIF. Do you know the RDFPic stuff from about 10 years ago? It was an attempt to show that an approach like EXIF *could* work for img elements. It's a tough sell because it takes a serious change in tooling for producers and consumers. And the data is too often too hidden - and we know where that leads...

Yes. Great idea, but as you note, hard to implement in a usable way.

>> Standard links and iframes both handle off-page resources in a way that all users can access.
> 
> Yes, but you lose the association. For a back-end services provider like Yandex, that's a loss that's hard to make up algorithmically.

Perhaps that could be solved with a WCAG Technique to include the link reference in a figure caption?

> BTW I get the impression we're entirely on the same page about making the functionality available to all users.

In general probably so, but with regards to this specific feature, probably not. ;-)

>> If an e-book reader unexpectedly navigates to a view that is not within the normal reading flow of a book, it may get into a UI blocking state for the user, where there is no way to navigate back or out. My point is that this would require special and separate UI specifically on behalf of the hosting application for AT users, that is not controlled by the AT.
> 
> That depends on how you build your whole UI, but yes it can arise. Like early WAP browsers that didn't have back buttons (or allowed site authors to remove them).

I'm somewhat lost regarding whether you mean native application UI, user agent UI, or web content UI. I was trying to point out that the extension spec is ambiguous as to whose responsibility it is to ensure this UI exists in other contexts. Is it the app's, the user agent's, or author's responsibility? If it works as a simple navigation link in a standard desktop browser, that's fine, but that functionality is not appropriate everywhere.

>> As history has shown, these separate interfaces are rarely equal.
> 
> And as history has shown, people aren't always good at learning from history.

;-)

> You are quite probably right that someone will make the same mistake again, despite the years of experience whose conclusions are readily available. Sadly, given that AT is often pretty slow-moving, the pain is likely to last longer than it would in a "mainstream" product (look at how accesskey implementations are allowed to suck for years on end for an example of what I mean).

I think that example hurts your cause. Accesskey sucks (in part) because it works differently on each platform due to incomplete specification (re: focus versus activation when triggered, and what should happen when a hotkey is reserved). Longdesc also sucks (in part) because of incomplete specification. IMO, adding this extension spec appears to resolve the complaint that some people had against the validation errors.

> But we already rely on common sense and market failure to weed out bad implementation, and I don't think the risk here is any higher than normal.

Fair enough.

> I think we're closer than we might seem on this whole thing. I appreciate you taking the time to clarify your thoughts.

Likewise, thanks for your responses.

James

Received on Wednesday, 28 November 2012 00:44:38 UTC