w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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:
- Candidate TF Resolution: ISSUE-30 longdesc
- Candidate TF Resolution: ISSUE-66 image-analysis
- Candidate TF Resolution: ISSUE-80 Title
- 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
| Choice | All responders |
|---|---|
| Results | |
| yes | 19 |
| no | 6 |
Details
| Responder | Candidate TF Resolution: ISSUE-30 longdesc | Comments |
|---|---|---|
| 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
| Choice | All responders |
|---|---|
| Results | |
| yes | 21 |
| no | 2 |
Details
| Responder | Candidate TF Resolution: ISSUE-66 image-analysis | Comments |
|---|---|---|
| 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
| Choice | All responders |
|---|---|
| Results | |
| yes | 22 |
| no | 1 |
Details
| Responder | Candidate TF Resolution: ISSUE-80 Title | Comments |
|---|---|---|
| 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
| Choice | All responders |
|---|---|
| Results | |
| yes | 21 |
| no | 4 |
Details
| Responder | Candidate TF Resolution: ISSUES-90, 91, 93, 95, 96, & 97 | Comments |
|---|---|---|
| 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
- Joshue O'Connor: last responded on 14, April 2010 at 15:56 (UTC)
- Richard Schwerdtfeger: last responded on 14, April 2010 at 16:50 (UTC)
- David Singer: last responded on 14, April 2010 at 18:23 (UTC)
- Eric Carlson: last responded on 14, April 2010 at 18:53 (UTC)
- Jon Gunderson: last responded on 14, April 2010 at 21:52 (UTC)
- Cynthia Shelly: last responded on 14, April 2010 at 22:29 (UTC)
- Leif Halvard Silli: last responded on 15, April 2010 at 02:25 (UTC)
- Markku Hakkinen: last responded on 15, April 2010 at 03:32 (UTC)
- Gregory Rosmaita: last responded on 15, April 2010 at 04:31 (UTC)
- Geoff Freed: last responded on 15, April 2010 at 10:45 (UTC)
- Jim Allan: last responded on 15, April 2010 at 13:53 (UTC)
- Marco Ranon: last responded on 15, April 2010 at 14:39 (UTC)
- Laura Carlson: last responded on 15, April 2010 at 14:54 (UTC)
- Ben Caldwell: last responded on 15, April 2010 at 15:08 (UTC)
- Martin Kliehm: last responded on 15, April 2010 at 17:03 (UTC)
- Kelly Ford: last responded on 15, April 2010 at 18:08 (UTC)
- Sean Hayes: last responded on 15, April 2010 at 18:33 (UTC)
- Frank Olivier: last responded on 15, April 2010 at 19:29 (UTC)
- Wendy Chisholm: last responded on 15, April 2010 at 19:38 (UTC)
- Philip Jägenstedt: last responded on 16, April 2010 at 01:56 (UTC)
- Silvia Pfeiffer: last responded on 16, April 2010 at 01:56 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project