W3C WBS Home

Results of Questionnaire Call for Consensus: Proposals from the April 2010 Face to Face meeting

The results of this questionnaire are available to anybody.

This questionnaire was open from 2010-04-13 to 2010-04-15.

27 answers have been received.

Jump to results for question:

  1. Candidate TF Resolution: ISSUE-30 longdesc
  2. Candidate TF Resolution: ISSUE-66 image-analysis
  3. Candidate TF Resolution: ISSUE-80 Title
  4. Candidate TF Resolution: ISSUES-90, 91, 93, 95, 96, & 97

1. Candidate TF Resolution: ISSUE-30 longdesc

Refer to Candidate TF Resolution: ISSUE-30 longdesc.

Do you support this as a decision of the task force? If no, please indicate what changes would enable you to support this.

Summary

ChoiceAll responders
Results
yes 19
no 6

(2 responses didn't contain an answer to this question)

Details

Responder Candidate TF Resolution: ISSUE-30 longdescComments
Steve Faulkner yes
Michael Cooper yes
John Foliot I have a minor issue with the heading: "There is a superior alternative to longdesc: aria-describedby" - this is akin to saying that orange juice is superior to milk.

Both @longdesc and aria-described by, as we currently have them, serve to solve a specific problem, but in different ways; neither is superior to the other, simply different. The use-cases for both are very similar, but significantly different that both should remain available to content authors, just as milk and orange juice are both healthy drinks, but hardly the same drink.

The draft resolution also notes that there may be changes in ARIA 2.0 that extends aria-describedby to support URLs as well as IDREFs - should that be the case, then I could live with the deprecation of @longdesc. However, I believe that this question is out of scope at this time, as guessing what may or may not arrive in ARIA 2.0 should not influence our discussion at this time, although I agree that noting these possibilities is useful supplementary data.

My desire is to see @longdesc retained, and if accepting a 'warning' is what we are going to get with that larger goal, I can live with that. Abstaining for now on 'language issues' (the use of the word superior), but supportive in general should it come to a vote.
Janina Sajka yes
Ian Hickson no We do not seem to have described a good rationale here.
http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0143.html
Gez Lemon no I agree with the parts of the resolution that ask for the longdesc attribute to be retained. I'm also not against a replacement for longdesc, but I don't think aria-describedby is a suitable replacement. If I understand correctly, aria-describedby will annotate text in the target id referenced by the idref, meaning that AT users won't be able to control how they interact with the long description. As, by definition, this is going to be long, it doesn't seem a good solution. Something that moves the user's reading cursor to the longer description (either on the same page or in a different page) where the user can control how they read the long description would be a better solution.
Joshue O Connor yes
Richard Schwerdtfeger yes
David Singer yes
Eric Carlson yes
Jon Gunderson yes In general I like using aria-describedby and deprecating longdesc since it is little used or supported. In Web 2.0 resources descriptions will not be separate pages, rather the descriptions we be hidden on the same page and user will be able to selectively show or hide the description using a button or a link, which would work with the current aria-describedby feature.
Cynthia Shelly yes
Leif Halvard Silli no I support the main part of the resolution, which says that there should be no warning for using @longdesc.

And the perspective for aria-describedby in ARIA 2.0 sounds good - if somehow unclear (I wonder how one can change aria-describedby to accept both IDREFs and URIs - don't we rather need aria-longdesc="uri"?). It is a good plan that @longdesc can be replaced then, with whatever ARIA 2.0 has on the table. But we are not there yet.

I will support this resolution if

(1) I do not have to sign up to a promise about deleting @longdesc in the future. May be you could say that "many of use believe that an @aria-* attribute should take over, if and when ARIA 2.0 to provide a feature for pointing to descriptions in other pages."

(2) the option for a negotionable warning is removed. I principally agree with co-chair Sam Ruby that HTML5 should not (in my words) smash authors on the fingers for using (what some think are) legacy features. Such punishment should be the task of separate authoring conformance spec - of different kinds (may be a A11Y conformance spec).
Markku Hakkinen no As probably the first to implement longdesc in a UA, and then to see it rarely used, I have no problem to see it removed from HTML5 and replaced with describedby. Those few who invested effort to create content with longdesc can also surely invest the effort to move to describedby. A mechanism for out of page describedby targets should be accelerated (implementation seems more an AT issue than UA IMO).
Gregory Rosmaita no obsolete but conforming is an oxymoron which causes george orwell to spin in his grave - this is what i support:

RESOLUTION: There is a need for some mechanism that supports longer
descriptions.

RESOLUTION: People agree to have in page descriptions.

RESOLUTION: Group agrees that we should have out of page
descriptions, but has concerns about its implementation.

RESOLUTION: The group wants longdesc to continue in HTML 5.

RESOLUTION: we do not want to ask for a new feature in HTML 5 to
replace longdesc.

RESOLUTION: We do not want to change aria-describedby to support
descriptions in a separate page in the ARIA 1.0 time frame.

RESOLUTION: aria-describedby should be enhanced in the ARIA 2.0 time
frame to support external descriptions (out of page).


i am against the following:

MINUS ONE: We can live with a two step process, in which users
follow an aria-describedby reference to a link and then must follow the
link to get the actual description, but we do not prefer it.

MINUS ONE: While the HTML-A11Y Task Force prefers the proposal that
restores longdesc without warning we are prepared to accept the
alternative proposal at
http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning
to produce a warning (assuming we can agree to warning text)

QUESTION: what happened to:

http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc

and the discussion thereof:

http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/longdesc

it is far more palatable to me
Geoff Freed yes
Jim Allan yes
Marco Ranon yes
Laura Carlson no On January 14, 2009 the WAI CG created a Task Force on text alternatives, to consider the various alternative text approaches discussed over the past few years, and to develop consensus WAI recommendations for appropriate handling of alternative text in HTML5. The WAI CG special alt task force studied the matter comprehensively for five months and developed a holistic solution. The resulting report provided WAI consensus recommendations for alternative text support in HTML 5.

The recommendations were reviewed and agreed to by the following WAI Working Groups: Authoring Tools Working Group (AUWG), Protocols & Formats Working Group (PFWG), User Agent Working Group (UAWG), and Web Content (WCAG WG).

This resolution does not concur with WAI CG Consensus Resolutions on Text alternatives in HTML 5 regarding LONGDESC. The WAI CG June 10, 2009 consensus document [1] stated the following regarding LONGDESC:

Quote

"Because we are confident that aria-describedby will be supported by assistive technologies at least as well as longdesc when HTML5 becomes a W3C Recommendation:

* IF
** aria-describedby is incorporated in HTML5
** and aria-describedby allows pointing to long text alternatives that are off of the page (by pointing to a link on the page)

* THEN
** we believe it is acceptable to obsolete longdesc in HTML5.

RATIONALE: It is important that a long text mechanism exist which is capable of pointing off page. Long descriptions are often too lengthy and detailed to be included on the main page. If aria-describedby can point off page (by pointing to a link on the page) then it would remove any need for continued support of LONGDESC which is not widely used by authors at this time. (NOTE: it is understood that aria-describedby cannot point off page directly.)"

Unquote

BOTH IFs need to be fulfilled *BEFORE* the longdesc attribute can be made obsolete.

[1] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
Ben Caldwell yes
Martin Kliehm yes
Kelly Ford yes This is less than perfect and in a future version of HTML this entire area needs more attention. It is too complicated for end users to get good descriptions of images and too hard for page authors to understand how these are important today.
Sean Hayes yes I would like more clarity over the status of the aria attributes in HTML5, and also I would like some means of labelling the distinction in aria-describedby between a long description of a resource, and a verbatim transcript of a resource.
Frank Olivier yes
Wendy Chisholm yes
Philip Jägenstedt
Silvia Pfeiffer yes Am not an expert, but deprecating longdesc through warning in validator sounds like a sensible step forward toward introducing aria-describedby for this purpose.

2. Candidate TF Resolution: ISSUE-66 image-analysis

Refer to Candidate TF Resolution: ISSUE-66 image-analysis.

Do you support this as a decision of the task force? If no, please indicate what changes would enable you to support this.

Summary

ChoiceAll responders
Results
yes 21
no 2

(4 responses didn't contain an answer to this question)

Details

Responder Candidate TF Resolution: ISSUE-66 image-analysisComments
Steve Faulkner yes
Michael Cooper yes
John Foliot yes
Janina Sajka yes
Ian Hickson no The proposal seems out of date with the specification.
http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0144.html
Gez Lemon yes
Joshue O Connor yes
Richard Schwerdtfeger yes
David Singer
Eric Carlson
Jon Gunderson yes
Cynthia Shelly yes
Leif Halvard Silli no I feel that image analysis is merely a "good idea". Good ideas can be placed in authoring conformance documents and texts like that - not in be HTML spec.

Thus I support the idea that it should be removed. But not for the same reason as provided. I would support it if the TF would be willing to move towards supporting that authoring conformance should be moved out of HTML5.

(When I agree with decision but not with rationale, then it is a bit hard to know how to vote...)
Markku Hakkinen yes
Gregory Rosmaita yes
Geoff Freed yes
Jim Allan yes
Marco Ranon yes
Laura Carlson yes
Ben Caldwell yes
Martin Kliehm yes
Kelly Ford yes
Sean Hayes yes
Frank Olivier yes
Wendy Chisholm yes
Philip Jägenstedt
Silvia Pfeiffer I'm ambivalent about the image analysis paragraph - I know that certain automated analysis is totally feasible today and the paragraph only states "may". But it is also context that is not necessary in a specification.

3. Candidate TF Resolution: ISSUE-80 Title

Refer to Candidate TF Resolution: ISSUE-80 Title.

Do you support this as a decision of the task force? If no, please indicate what changes would enable you to support this.

Summary

ChoiceAll responders
Results
yes 22
no 1

(4 responses didn't contain an answer to this question)

Details

Responder Candidate TF Resolution: ISSUE-80 TitleComments
Steve Faulkner yes
Michael Cooper yes
John Foliot yes
Janina Sajka yes
Ian Hickson no The proposal's arguments seem inconsistent with the specification, arguing against a position that is not the specification's.
http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0145.html
Gez Lemon yes
Joshue O Connor yes
Richard Schwerdtfeger yes
David Singer
Eric Carlson
Jon Gunderson yes
Cynthia Shelly yes I can live with it either way.
Leif Halvard Silli yes This is an authoring conformance issue, it seems, which HTML5 therefore should be silent on. HTML5 should try to limit itself to talk about ALT.
Markku Hakkinen yes
Gregory Rosmaita yes there are myriad reasons why one would want to annotate a link with hyperlink text and a title, as well as alt and a title -- alt is a terse descriptor, title annotates the link (result is often better "viewed" with a list of links, as setting an AT to expose the title for every link causes extreme cognitive dissonance when reading hyperlink text in context; also there is the multiplicity of benefits that title offers as a global attribute
Geoff Freed yes
Jim Allan yes
Marco Ranon yes
Laura Carlson yes
Ben Caldwell yes
Martin Kliehm yes
Kelly Ford yes
Sean Hayes yes I would prefer that title be an element, rather than an attribute; since it contains text that should be offered to the user it may need markup.
Frank Olivier yes
Wendy Chisholm yes
Philip Jägenstedt
Silvia Pfeiffer I can't make a decision here since I am unsure about what effects @title and @alt have. If on all elements @title is interpreted by screen readers and read out, it would make sense to have this used universally. But I don't think that is the case.

4. Candidate TF Resolution: ISSUES-90, 91, 93, 95, 96, & 97

Refer to Candidate TF Resolution: ISSUES-90, 91, 93, 95, 96, & 97. Note that an amended candidate resolution was sent as well; you may express a preference for that one in the comments if you wish, but (attempting to reduce confusion) the formal vote on this survey question is on the original proposal.

Do you support this as a decision of the task force? If no, please indicate what changes would enable you to support this.

Summary

ChoiceAll responders
Results
yes 21
no 4

(2 responses didn't contain an answer to this question)

Details

Responder Candidate TF Resolution: ISSUES-90, 91, 93, 95, 96, & 97Comments
Steve Faulkner yes
Michael Cooper yes
John Foliot yes I support the Candidate Recommendation, and have contributed to the other counter-proposal being prepared at http://www.w3.org/html/wg/wiki/User:Eoconnor/keephidden
Janina Sajka yes
Ian Hickson yes
Gez Lemon yes
Joshue O Connor yes
Richard Schwerdtfeger yes
David Singer yes
Eric Carlson yes
Jon Gunderson no I think the more we can simplify HTML 5 elements the easier it will be to get HTML 5 and accessibility implemented and to explain to authors how to create accessible content in HTML5. Browser developers will probably not implement these elements anyway if they don't like them or do it inconsistently. There is a lot in HTML5 and I think we have enough to discuss without spending time on elements that may never be implemented.
Cynthia Shelly yes I support both the TF resolution and the "Retain several newly-introduced semantic elements, attributes, and controls" zero-change proposal at http://www.w3.org/html/wg/wiki/User:Eoconnor/keephidden.
Leif Halvard Silli no I will eventuallly express my independent opinion on this issue. There is nothing you can do to make me support this. I get a bad feeling from all the people that have rushed to express that they are against Shelley's proposal. I don't think we need to stay "united" on this.

The best thing would perhaps be to say that I am not a warm supporter of many of these elements. Whether I will actually work for removing them is another issue ...

I think that some of these problems these elements are meant to solve should have been solved in a different way - not necessarilty like Shelley suggest, though, but still.

My main concern is that I am worried about the way these elements are "marketed" to eat from current HTML4 features. (Most notably, recently: <details> vs @summary. Same thing could be said abotu some aria-* attributes versus HTML4 attribtues. I don't want to hype ...)
Markku Hakkinen yes
Gregory Rosmaita yes support the relevant TF resolutions for ISSUE-90, ISSUE-91, ISSUE-93, ISSUE-95, ISSUE-96, ISSUE-97, as well as http://www.w3.org/html/wg/wiki/User:Eoconnor/keephidden
Geoff Freed yes
Jim Allan no This was a difficult decision. Creation of orphaned, poorly implemented or non-implemented elements is not the goal. Having rich semantics that do not require an accessibility api to function (not all people with disabilities use AT) is laudable. But, only if implemented. Current implementations - 0, aria workarounds - 5.
Marco Ranon yes
Laura Carlson no If the task force wants to propose opposing these proposals it should properly state how and why EACH element is useful for accessibility and how and why that outweighs Shelley's rationale. That is not only the rational thing to do but also a professional courtesy. The proposals should not all be lumped together in an all encompassing resolution.

The task force had previously agreed not to work on figure, details, or hidden at this time [1] [2] [3]. The others elements aside, progress, and meter were not even on our radar.

At this point I am undecided about Shelley's six Change Proposals to remove these elements. Therefore, I cannot say I oppose them, because I don't know if I do or not. I cannot in clear conscience oppose them. Counter proposals by individuals would help me to decide. That is happening outside of the task force in the HTMLWG [4] which is fine.

I have a lot of thinking to do about everything. I don't know if the elements are needed. But if they are really needed, maybe a different set of them would help accessibility more. It is an odd set as Patrick pointed out [5].

It is premature for me to make this decision or the task force for that matter.

If the task is interested in pursuing such a sweeping resolution, serious study and due consideration should be given to these six elements not only individually but also in a holistic manner.

Some questions:

In regards to the interactive elements, I have always used the three legged stool approach to web standards. Separate structure, presentation, AND behavior. Is this relevant anymore? How is the conflict between introducing native interactive elements and separating behavior reconciled?

There is a question of scope creep and quality. Douglas Crockford talked about HTML scope creep as well as quality recently [6]. He said,

"Speaking of HTML5‚ A big step in the wrong direction. In my view it's way too complicated, way too much crap in it. There's some good stuff in it, there's some very good stuff in it, some very bad stuff in it, and the HTML5 committee cannot tell the difference. I would like it to go away. I would like to start over. I think there are definitely things that we could do better in the browser platform based on what we've learned in Ajax. That stuff's not being factored into HTML5, and that's unfortunate."

"Because it turns out that Ajax developers are much better at this stuff than browser makers. You look at the quality of design in any Ajax library and it's infinitely better than what we've got coming out of the browsers, and it's infinitely better than what we've got coming out of HTML5. So I think this community should be the community for deciding what the next version of the platform should be."

Another question: Is ARIA a stop gap measure or not?

In one way it seems not to be, as WAI CG was hot to add @role="presentation" and @aria-labelledby text alternative options for HTML5 in the June 2009, "Consensus Resolutions on Text alternatives in HTML 5" document [7]. It seems as they want it to be a permanent part of HTML moving forward.

On the other hand, the ARIA road map talks about ARIA as being a bridge [8].

Have any of these elements been implemented or tested in AT? The resolution states: "We maintain the work item to check these elements and make them better." How would this work? Do we have volunteers to do this?

On June 9, 2008, in his email "How to add features to HTML5" [9], Ian stated his nine step procedure for adding new features to the spec. Ian concluded by saying that the default state for a feature request is for it to be rejected and the default state for a section of the spec was for it to be eventually dropped unless the feature is widely implemented and so important that browser vendors "are actually ready to commit money and risk interop issues over it". From all I have gathered, it has not been verified that these elements are indeed widely implemented and so important that user agent vendors "are actually ready to commit money and risk interop issues over it".

Again, I have a lot of thinking to do about everything. It is premature for me to make this decision or the task force for that matter.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8404#c56
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c14
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8118#c14
[4] http://lists.w3.org/Archives/Public/public-html/2010Apr/thread.html#msg189
[5] http://www.brucelawson.co.uk/2010/html5-details-element-built-in-and-bolt-on-accessibility/#comment-666275
[6] http://developer.yahoo.com/yui/theater/video.php?v=crockonjs-4
[7] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
[8] http://www.w3.org/TR/wai-aria-roadmap/
[9] http://lists.w3.org/Archives/Public/public-html/2008Jun/0140.html
Ben Caldwell yes
Martin Kliehm yes
Kelly Ford yes
Sean Hayes yes I think this needs more work in the justification before its advanced to the WG. I'm not convinced by the arguments we are currently putting forward, nor the manner in which we are expressing them. However I'm not fundamentally opposed to the idea that semantic elements are good for accessibility, but we havent really made that case. Clearly we arent in a position to include every semantic element that might be required, so some assembly will still be required by authors, if we include aria to make those accessible, its not clear to me what is special about these elements.
Frank Olivier yes
Wendy Chisholm
Philip Jägenstedt yes
Silvia Pfeiffer With the limited context available to me, I can only make a gut feeling decision on these.

I am ambivalent wrt removing aside, details and @hidden. There is sufficient existing functionality to do what they propose and these don't provide such a huge win over what exists. But I can understand why people might be asking for them.

I oppose removing figure, progress and meter - they provide functionality not otherwise available easily.

I have, however, not spent a lot of time investigating these issues, so don't take them for more than an indicative feedback.

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Liam Quin <liam@w3.org>
  3. Charles McCathie Nevile <chaals@yandex-team.ru>
  4. Philippe Le Hégaret <plh@w3.org>
  5. Paul Cotton <Paul.Cotton@microsoft.com>
  6. Shane McCarron <shane@aptest.com>
  7. David MacDonald <David100@sympatico.ca>
  8. Sam Ruby <rubys@intertwingly.net>
  9. Michael[tm] Smith <mike@w3.org>
  10. Stefan Schnabel <stefan.schnabel@sap.com>
  11. Matthew Turvey <mcturvey@gmail.com>
  12. Kenny Johar <kensingh@microsoft.com>
  13. Sally Cain <sally.cain@rnib.org.uk>
  14. David Bolter <dbolter@mozilla.com>
  15. Jeanne F Spellman <jeanne@w3.org>
  16. Jean-Pierre EVAIN <evain@ebu.ch>
  17. Jatinder Mann <jmann@microsoft.com>
  18. Ian Pouncey <w3c@ipouncey.co.uk>
  19. Léonie Watson <lwatson@paciellogroup.com>
  20. Masatomo Kobayashi <mstm@jp.ibm.com>
  21. Bob Lund <b.lund@cablelabs.com>
  22. Mark Watson <watsonm@netflix.com>
  23. Adrian Roselli <roselli@algonquinstudios.com>
  24. Jason Kiss <jason@accessibleculture.org>
  25. Billy Gregory <bgregory@paciellogroup.com>
  26. Mark Sadecki <mark.sadecki+w3c@gmail.com>
  27. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  28. Brian Kardell <hitchjs@gmail.com>
  29. Joseph Karr O'Connor <josephoconnor@mac.com>
  30. Joanmarie Diggs <jdiggs@igalia.com>

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.129 2015/07/01 16:13:23 kahan Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)