RE: Issue 30 (Was: RE: Getting HTML5 to Recommendation in 2014)

> From: Sam Ruby [mailto:rubys@intertwingly.net]
[...]
> > In this proposed draft plan can the a11y TF simply take the authored
> > CP to re-instate longdesc and call it an extension spec? I assume
> > format changes would be required, but I thought the heavy lift had
> > been done to define it.
> 
> Yes.

Thanks. I am not part of the a11y TF, so I'll just have to wait it out.


> > Based on the number of times I have seen reference to this issue being
> > expedited, put on hold, had dates shifted, etc. I get the sense that
> > nobody wants to pull the trigger on this either way. Off-loading it to
> > the a11y TF absolves the chairs and WG of making a decision (or going
> > through a survey process). From my extremely limited experience with
> > the process it also wholly shifts the burden to the a11y TF.
> 
> Our experience is that extension specifications are less 'burden' (to use your
> words).  If the A11y TF agrees to publish this as an extension specification, it
> can do so.  It can even proceed to Last Call, CR, PR, and Rec *before* HTML5
> does if that is what is desired:
> 
> https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html

I may not have access to that -- my username and password didn't seem to work (I have emailed for a reminder).


> I don't agree with how John counts (we may differ on what it means to be
> truly 'independent'), and it remains to be seen whether the implementation
> he cites truly implement the spec or merely something resembling long
> descriptions, but I do agree that substantial progress has been made:
> 
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0382.html
> 
> Longdesc can also be reintegrated into the HTML5 specification.  To do so will
> likely require resolving what does longdesc want to be when it grows up.
> 
> We have evidence that longdesc works well in education settings that exist
> behind copyright restrictions, and authors of addons quite willing to fill in
> gaps that major browser vendors may leave:
> 
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0382.html

I think this isn't the link you meant -- it's the same as the link above.


> We also have indications that longdesc as currently defined is not quite as
> successful in non-educational non-copyright restricted settings:
> 
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0295.html
> 
> Perhaps this is contributing to the reluctance by a number of major browser
> vendors to natively implement the feature.  This needs to be resolved, either
> by gaining the support of these vendors or by properly positioning the
> feature via so that expectations are set properly as to whether users can
> expect widespread implementation:
> 
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0383.html
> 
> > This may be more appropriate, I just don't know. What I do know is
> > that I'd hate to see this come to "resolution" because it gets mired
> > in the process (where it seems to have already been lost) instead of a
> > group decision.
> 
> At the present time, I am concerned that a group decision will either result in
> one or more Formal Objections (and therefore more delay) or (and possibly
> worse) simply be ignored:
> 
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0216.html
> 
> What we are encouraging is that we unblock progress instead.  Longdesc can
> proceed to FPWD without delay, positioning and work on meeting CR exit
> criteria can proceed in parallel, and important work can be begun on bringing
> long descriptions to other elements.

I can drink that Kool-Aid. Because I am not on the a11y TF, however, I will now not able to weigh in on discussions. I don't have enough experience with the process to know if I should be concerned, but I do like the idea of the a11y TF having the power to push this through.

Thanks for all the reference links.


> > Am I just misunderstanding and/or being paranoid?
> 
> I'll leave that up to you to determine.  :-)

I'll go with both, then.

Received on Thursday, 20 September 2012 15:00:55 UTC