w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-31/80: Text Alternative Examples - Straw Poll for Objections
The results of this questionnaire are available to anybody.
This questionnaire was open from 2011-03-29 to 2011-04-05.
8 answers have been received.
Jump to results for question:
- Objections to letting HTML5 define the requirements
- Objections to using the "Techniques for providing useful text alternatives"
- Objections to using WCAG 2.0 to define the requirements
1. Objections to letting HTML5 define the requirements
We have a Change Proposal that lets requirements on the possible values of the text aternatives to be defined by the current text in HTML5. If you have strong objections to this Change Proposal then please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to letting HTML5 define the requirements |
|---|---|
| Ian Hickson | |
| John Foliot | This is less of a technical question, and rather more of a philosophical question. It is my belief that creating modular components of a larger specification such as HTML5 allows for greater flexibility and responsiveness. The most current and complete author guidance emerging from the work-effort behind HTML5 is "Techniques for providing useful text alternatives" – a document that is being written in concert with the HTML5 effort, and one that has PFWG/WAI support. It is my belief that this is the best way forward to addressing the question on where and which specification should define requirements on the possible values of text alternative examples. Given that, I object to this change proposal as the only means to endorse moving all author guidance for accessible and appropriate text alternatives to "HTML5: Techniques for providing useful text alternatives" (http://dev.w3.org/html5/alt-techniques/). I note that at this time this document is still in Editor's Draft, and any questions and concerns over appropriate language can continue to evolve around that document, speeding closure of HTML5 Issues and bringing it to Last Call. |
| Silvia Pfeiffer | |
| Leif Halvard Silli | I object to keeping @alt guidance in the HTML5 spec on the grounds that HTML5 should just have one spec which defines these issues. As long as @alt is defined in HTML5, we will have two specs defining the same issue - HTML5 and Steve's sepc. Thus I support Ian's view about Steves doc that we if/when we go for that option, should strip out all material regarding @alt from the main HTML5 spec. Thus, I support that all unfinished debates and issues regarding these issuses, are moved to the Techniques document. (That document may have to be expanded a bit more.) Thus, do not necessarily say that the Techniques document is perfect and that I agree with everything there. The benefits of the the HTML5 spec's definitions of @alt, is that it is rather simple. However, it hides a lot of complexity. |
| Laura Carlson | Having W3C WAI specifications and W3C HTML5 specifications that provide conflicting text alternatives examples is bad. It will lead to confused authors. Having two specifications in HTML5 with conflicting text alternatives examples is also bad. It not only will lead to confused authors, it is poor language design. HTML5 should not contradict HTML5. It adds complexity and ambiguity. This is a symptom of a language that doesn't do its job. HTML5 (4.8.2.1.1 to 4.8.2.1.11) conflicts with "HTML5: Techniques for providing useful text alternatives" document [1] which is much more consistent with W3C accessibility guidelines, developed over many years, than the advice currently in the HTML5 draft. Ian's document follows his own personal accessibility rules based on his own personal perspective of accessibility. Some things are very wrong. Some examples between the two documents directly clash. For instance CAPTCHA [2], Webcam [3], and title [4] examples in HTML5 directly contradict examples in the techniques document [5] [6]. If it is desired to have text alternative information in both a standalone document AND in the HTML5 spec, as stated in the second option of the details section of Steve's proposal [7] we would need to ensure that both documents: * Are in harmony and do not contradict each other. * Do not get out of sync. * Are consistent with W3C accessibility guidelines. This could be accomplished with a server-side-include to replace and thereby correct the contents of 4.8.2.1.1 to 4.8.2.1.11 in the HTML spec with "HTML5: Techniques for providing useful text alternatives". Using the techniques document, as the source would also reduce maintenance of the HTML spec as the techniques document would provide content to the HTML5 spec. To insure overall W3C consistency the techniques document would need to be vetted by WAI. The more choices you give people, the harder it is for them to choose, and the more likelihood of them getting things wrong. Too many or conflicting examples adds complexity and leads to confusion. In contrast a narrow, focused set of examples leads to clarity, which leads to more authors getting it right. "The Paradox of Choice: Why More Is Less" (Barry Schwartz; Ecco, 2003) shows that a bewildering array of choices floods a person 's brain, ultimately restricting instead of freeing. We normally assume that more options ('easy fit' or 'relaxed fit'?) will make us happier, but Schwartz demonstrates the opposite is true. Too many choices actually makes things more difficult. Hick's Law (Hick, William E.; On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4:11-26, 1952) states the time it takes to make a decision increases as the number of alternatives increases. More choice equals more time required, more anxiety, and difficult learnability. Simplicity is treading a line. Antoine de Saint-Exupery said, "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away." It comes across as magic when it works. That is a high achievement. It is what HTML5 should aim for. -- Note: In response to Ian's comments on the two other proposals, "If we do this we should make sure to strip out all content regarding alt="" from the W3C HTML spec, so that there are no contradictory statements across specs." alt values are not machine checkable whereas a set of machine checkable validity options are. Automatic validators can programmatically determine the presence or absence of text alternatives on an <img> element in order for <img> to be considered valid. So there would be no conflict between specs in that regard. References: [1] http://dev.w3.org/html5/alt-techniques/ [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9216 [3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9215 [4] http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 [5] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9169 [6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9174 [7] http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209 |
| Henri Sivonen | |
| Steve Faulkner | I object to this proposal as it calls to "Change nothing" which is evidently inadequate as the working group has not reached consensus. The development of best practices for the provision of text alternatives is a work in progress, and is definitley not represented well by the current HTML5 spec text. It claims the current text in the HTML5 spec "includes detailed requirements and examples" but these are clearly lacking in scope and detail and some of them directly contradict normative advice found in WCAG 2.0 and HTML5: Techniques for providing useful text alternatives. The HTML5 specification should define when the presence/absence of the alt attribute for instances where this is machine checkable otherwise it should point developers to 'HTML5: Techniques for providing useful text alternatives' a document that provides more extensive coverage than the HTML5 spec text and harmonizes its best practice advice with WCAG 2.0. Having HTML5 best practice text alternative advice in a document seperate from the main HTML5 specification means that important details and examples issues can be fully provided, maintained and updated without the need to update the HTML5 specification each timean update is required. It will allow the various stakeholders in the community to have continuing input into the development of the advice. Also it means that the development can continue independent of the bottleneck created by having one person controlling the editing of content of the HTML5 specification. my objections are further elaborated in the chnage proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209 |
| Theresa O'Connor |
2. Objections to using the "Techniques for providing useful text alternatives"
We have a Change Proposal would let the requirements on the possible values of text alternatives to be defined by "Techniques for providing useful text alternatives". If you have strong objections to this Change Proposal then please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to using the "Techniques for providing useful text alternatives" |
|---|---|
| Ian Hickson | If we do this we should make sure to strip out all content regarding alt="" from the W3C HTML spec, so that there are no contradictory statements across specs. |
| John Foliot | |
| Silvia Pfeiffer | I actually like Steve's extensive document that explains clearly to authors how they should use @alt and @aria-describedby with many examples. However, I also agree that the HTML5 specification needs to fully contain a specification of all elements and attribute values of the HTML5 language. I fail, however, to understand why we cannot have both documents. The HTML5 specification can describe the technical requirements for @alt and @aria-describedby and what the values mean, and the "Techniques for providing useful text alternatives" can expand on that with all the examples it provides. |
| Leif Halvard Silli | |
| Laura Carlson | |
| Henri Sivonen | |
| Steve Faulkner | |
| Theresa O'Connor | The HTML specification should provide the requirements for the features that it defines. Web content authors, UA developers, and others consulting the spec would be done a disservice if the specification lacked a comprehensive description of <img>'s requirements, inluding those for all of its attributes. While we support the continued publication of the "techniques for providing useful text alternatives" document, we believe it should be published in addition to, not in replacement of, the alt="" requirements already present in the HTML specification. |
3. Objections to using WCAG 2.0 to define the requirements
We have a Change Proposal that propose to define the requirements for possible values of the text alternatives to be defined by WCAG 2.0. If you have strong objections to this Change Proposal then please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to using WCAG 2.0 to define the requirements |
|---|---|
| Ian Hickson | If we do this we should make sure to strip out all content regarding alt="" from the W3C HTML spec, so that there are no contradictory statements across specs. |
| John Foliot | This is less of a technical question, and rather more of a philosophical question. It is my belief that creating modular components of a larger specification such as HTML5 allows for greater flexibility and responsiveness. The most current and complete author guidance emerging from the work-effort behind HTML5 is "Techniques for providing useful text alternatives" – a document that is being written in concert with the HTML5 effort, and one that has PFWG/WAI support. It is my belief that this is the best way forward to addressing the question on where and which specification should define requirements on the possible values of text alternative examples. Given that, I object to this change proposal as the only means to endorse moving all author guidance for accessible and appropriate text alternatives to "HTML5: Techniques for providing useful text alternatives" (http://dev.w3.org/html5/alt-techniques/). I note that at this time this document is still in Editor's Draft, and any questions and concerns over appropriate language can continue to evolve around that document, speeding closure of HTML5 Issues and bringing it to Last Call. |
| Silvia Pfeiffer | |
| Leif Halvard Silli | I object ot this. HTML5 needs to provide its own text alternatives spec as the WCAG 2.0 is too general and when it provides examples, then they are not authoritative. |
| Laura Carlson | |
| Henri Sivonen | I object to deferring to WCAG 2.0, because doing so would make advice less detailed and less useful to Web authors. WCAG 2.0 itself doesn't contain any concrete examples, because WCAG 2.0 aims to be abstracted so highly that it is detached from concrete practicalities. Thus, it makes no sense to refer to WCAG 2.0 for any concrete specifics of a language feature. The WCAG 2.0 techniques document does not appear to be as comprehensive and does not appear to contain as useful examples as the texts proposed by the two other CPs. |
| Steve Faulkner | |
| Theresa O'Connor | It would be inappropriate for the HTML specification to defer to WCAG 2.0 for alt="" requirements. WCAG 2.0's techniques for HTML and XHTML <URL:http://www.w3.org/TR/WCAG20-TECHS/html.html> were written with HTML 4.01 & XHTML 1.0, 1.1, and 2.0 in mind, and don't take into account the plethora of new, changed, or removed features in HTML5 & XHTML5, unlike the advice and requirements currently in the HTML specification. Even for features present in both HTML 4.01 and HTML 5, WCAG 2.0 is not as comprehensive and lacks sufficient examples for Web authors to reference. |
More details on responses
- Ian Hickson: last responded on 29, March 2011 at 21:27 (UTC)
- John Foliot: last responded on 30, March 2011 at 01:47 (UTC)
- Silvia Pfeiffer: last responded on 30, March 2011 at 02:06 (UTC)
- Leif Halvard Silli: last responded on 30, March 2011 at 06:39 (UTC)
- Laura Carlson: last responded on 2, April 2011 at 08:54 (UTC)
- Henri Sivonen: last responded on 5, April 2011 at 11:50 (UTC)
- Steve Faulkner: last responded on 5, April 2011 at 14:22 (UTC)
- Theresa O'Connor: last responded on 6, April 2011 at 00:54 (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