W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2012

Re: Drop longdesc, get aria-describedat?

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Thu, 8 Mar 2012 03:01:36 +0100
To: Judy Brewer <jbrewer@w3.org>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20120308030136518078.efea5d09@xn--mlform-iua.no>
Judy Brewer, Wed, 07 Mar 2012 19:42:37 -0500:

>>>> My druthers would be to accept longdesc right away and call it obsolete
>>>> but conforming.

>> How do we get consensus for 'obsolete but conforming' + a CG

> I suggest you come to an HTML A11Y meeting for discussion; the next 
> one is scheduled for March 15th, due to other accessibility meetings 
> and conferences this week; or better yet to the text alternatives 
> sub-team meeting (next one should be March 13th and I am happy to put 
> this on the agenda)

I'm interested in discussing this, if Janina is. If so, which of the 
two dates would be most suitable?

> where we had been exploring this specific 
> category of issues in more depth. Also, please note that there has 
> been heavy discussion around many approaches on this already, and the 
> multiple delays by the HTML WG on processing the longdesc change 
> proposal may at this point themselves be contributing to the 
> confusion regarding alternative solutions on this question. The 
> TF-supported change proposal on longdesc is still overdue for a fair 
> hearing; getting another change proposal considered ahead of that 
> would be bad process.

Not 'ahead'. Only as a third or fourth CP - alongside the nochange and 
Laura's CP etc. The chairs have just made some comments on Laura's CP. 
At some point there will be a decision, and it that that point that I 
say that there perhaps should be a 'obsolete but conforming' option.

> As for a community group approach, note that that does nothing to 
> actually standardize anything, only to explore an issue. Creating a 
> community group for aria-describedat outside of the people who've 
> been working most directly on developing ARIA, and already thinking 
> about aria-describedat in some depth, could slow rather than speed 
> things up, or at best not materially change the timeline.

I would, personally, prefer that such a describedAT spec was specced 
without - for instance - my involvement. Nothing would be better if the 
ARIA WG/community specify it. May be CG is not the right approach. But 
a mini-spec could be the right approach. HTML5 itself can't invent 
aria-describedat - it must reference some spec or draft.

>> Meanwhile, another option: What if HTML5 simply was silent on @longdesc
>> ... I mean: If we want to reuse @longdesc in ARIA - rather than
>> creating a new @aria-describedAT, then HTML5 should not say that it is
>> obsolete and should as well, not say that it is conforming - until it
>> has been defined.
> 
> Another option is to add your voice to requesting that the 
> TF-supported longdesc proposal actually gets direct consideration and 
> fair hearing under the HTML WG decision policy, as is supposedly 
> imminent; though previous indications of imminence haven't yet borne 
> fruit...........

That an 'obsolete but conforming' CP - or any other CP - materializes, 
would not inflict on that. It would only mean that yet another CP would 
be heard, together with the current ones. Meanwhile, I have supported 
and contributed to Laura's CP. But I have also heard the latest 
responses form the chairs. It is quite possible that sitting quietly in 
the boat would have been the best - or just as good. However, it it  is 
good for myself to finally have understood, that - to many in the 
HTMLWg and the A11Y TF, the @longdesc conformance is only a temporary 
solution anyway. That something is temporary, is often not a good 
reason to allow it. But on the other hand, that it is temporary, also 
affects how binding vendors would see @longdesc's presence in the spec. 
And, hence it would be less controversial to have it in the spec. And 
the chairs are looking for lack of controversy.

Perhaps I misremember, but I think that in the previous vote, the 
'obsolete but conforming' status was rejected because the justification 
for that status bordered on 'it would not hurt if it was conforming'. 
But I think we can say that it hurts: Authors must then use another 
spec, in other to be conforming. And that does not make sense when we 
want people to switch to HTML5.
-- 
Leif Halvard Silli
Received on Thursday, 8 March 2012 02:02:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:27 UTC