Re: A longer description feature that vendors could accept (Was: 48-Hour Consensus Call: InstateLongdesc CP Update)

On Sep 19, 2012, at 4:50 AM, Leif Halvard Silli wrote:

> James, you recently said that aria-describedAT could be at risk in ARIA 
> 1.1 because it was the only feature that required  new things from the 
> browser level. But you were also positive about the feature - may be 
> fore ARIA 2.0 then?

I don't think there is currently a deliverable scheduled between 1.1 and 2.0, if that's what you mean.

> Sam said:
> 
>  ]] I do believe that a solution for these problems can be 
>     specified in a matter of months and demonstrably conforming
>     public implementations could be produced in a matter of 
>     months after that. [[
> 
> Do you, James, share this view w.r.t. Safari and VoiceOver for 
> instance? (I don't know when ARIA 2.0 could be due, for instance.)

In theory, that's possible. In practice, the schedule is almost always longer.

> To all: Moving it over to ARIA, I think Maciej's concern about MUST 
> level requirement to make it available to all would be solved. However, 
> I think it would not hinder 'special' browsers like iCab from 
> implementing also this new attribute as a contextual menu feature. 

I agree that this we would not want to phrase any requirement in a way that hinders UI exploration or innovation in browsers or assistive technologies.

> Speaking about deprecation: There are some features that are considered 
> obsolete but conforming. But may be we could make longdesc fully 
> conforming - for <img> elements - provided there were a aria-feature on 
> the same image?

Overcome by events, re: the extension spec proposal.

Received on Monday, 24 September 2012 22:28:57 UTC