w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-66 - Image Analysis Heuristics - Straw Poll for Objections
The results of this questionnaire are available to anybody.
This questionnaire was open from 2010-05-12 to 2010-05-19.
10 answers have been received.
Jump to results for question:
- Objections to the Change Proposal to Strike Paragraph
- Objections to the Change Proposal to Keep The Paragraph As Is
- Objections to the Change Proposal to Be More Explicit
1. Objections to the Change Proposal to Strike Paragraph
We have a Change Proposal to remove the image heuristics paragraph from the img element section. If you have strong objections to adopting this Change Proposal, 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 the Change Proposal to Strike Paragraph |
|---|---|
| Ian Hickson | The first paragraph of the rationale suggests that it is impossible to "recover from images with missing" alternative text. This is a straw-man argument, since the text in the specification (or proposed in one of the other change proposals) does not claim to enable user agents to "recover", merely allows user agents to make best-effort attempts to help users try to interpret such images. The second paragraph continues arguing against this straw-man, citing software that has shown a remarkable ability to identify images, and claiming that it cannot solve all problems. Yet no claim is made that any software can solve _all_ problems. Any improvement in accessibility is better than no improvement, even if the improvement is only helpful in limited case. For example, OCR is a mature technology that can be of huge help to users unable to see images, as there is a large class of images that merely consist of styled text. Certainly, relying on OCR software is no substitute for real alternative text, but no claim is made that it is — quite the contrary in fact — and _any_ improvement is an improvement, even if it is not a complete substitute. The change proposal continues in this vein throughout. Removing these paragraphs removes helpful text that might inspire user agent implementers to improve their accessibility. This would be a mistake, and I object strongly to doing so. It is always better to be explicit in stating what user agents are allowed to do than to rely on user agent implementers making educated guesses about what is likely to be the most helpful solution. |
| Matthew May | |
| Larry Masinter | |
| Laura Carlson | |
| Julian Reschke | |
| Cynthia Shelly | |
| David Singer | |
| Gregory Rosmaita | |
| Martin Kliehm | |
| Krzysztof Maczyński |
2. Objections to the Change Proposal to Keep The Paragraph As Is
We have a Change Proposal to keep the HTML5 specification as is. If you have strong objections to adopting this Change Proposal, 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 the Change Proposal to Keep The Paragraph As Is |
|---|---|
| Ian Hickson | |
| Matthew May | The rationale states that the current text should remain because "OCR has existed for decades". To be blunt, so what? OCR is not a specification in itself; it's an entire field of research, consisting of an unknown number of algorithms and processes, many if not most of them proprietary and patented. If you specify it further, you run the risk of patent challenges. If you leave it as vague as it is now, you will end up with numerous implementations of questionable value to the user. The editor cites OCR as "one simple and unambiguously possible technique" when it is neither. Anyway, the original reason the issue was raised was the even more nebulous "image analysis heuristics" passage, which remains in part in the current draft. UA developers don't need to be told in the specification that they're allowed to do more for the user. One would hope they've got ideas of their own. I'm in favor of either fleshing this out in a way that everyone can agree is actually beneficial for accessibility, or striking it. This is a half-step which is worse than either of the other two options. |
| Larry Masinter | see 4 below |
| Laura Carlson | 1. The spec mixes directives to authors and directives to user agents, which will cause confusion. 2. It is not clearly noted that the cited paragraph [1] is not an escape clause for authors to get out of writing text alternatives. Some authors may take the paragraph as saying, If: User agents can help users with visual disabilities make sense of an image then: I don't have to worry about it. 3. Any User Agent image repair verbiage should be left to or vetted and coordinated with User Agent Accessibility Guidelines Working Group (UAWG). They are the domain experts. Any such verbiage in HTML5 would need to be carefully worded so the two specs are harmonized. Currently the two specs are out of sync. |
| Julian Reschke | I don't think the paragraph is helpful; of course UAs can apply whatever techniques they want. Also, even if the UA can detect the contents of the image it still has no idea about the intent for including it. |
| Cynthia Shelly | There is no need to have this informative text in the spec, and there is consensus among accessibility experts that this is not useful, confusing, and potentially harmful. The spec is already too long, so let's remove this unnecessary and problematic text. |
| David Singer | |
| Gregory Rosmaita | the discussion of potential repair techniques, including the image heuristics paragraph belongs in the HTML5 Alt Techniques document, which has been compiled by Steve Faulkner and which can be found at: http://dev.w3.org/html5/alt-techniques/ i have an action item from the HTML Accessibility Task Force (http://www.w3.org/WAI/PF/HTML/track/actions/28) to create an Appendix to the Alt Techniques document, which would address both "potential repair" techniques such as image heuristics and crowd-sourcing; as well as a discussion of existing techniques that enable authors to provide meaningful descriptions when uploading images to aggregator sites, using the W3C's RDFPic open source software: http://jigsaw.w3.org/rdfpic/ http://jigsaw.w3.org/rdfpic/rdfpic-2/rdfpic-readme.html as described in the W3C technical recommendation, "Describing and Retrieving Photos using RDF and HTTP" http://www.w3.org/TR/photo-rdf/ |
| Martin Kliehm | |
| Krzysztof Maczyński | see my Objections to the Change Proposal to Be More Explicit |
3. Objections to the Change Proposal to Be More Explicit
We have a Change Proposal to be more explicit about potential repair techniques. If you have strong objections to adopting this Change Proposal, 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 the Change Proposal to Be More Explicit |
|---|---|
| Ian Hickson | |
| Matthew May | |
| Larry Masinter | The kind of activity to tell people what possible repair technologies might be to help a user understand an image are completely out of scope for the W3C HTML Working Group. Fundamental to having a "Web Architecture" is to accept that "Architecture" actually means something, and that a fundamental component of any kind of system architecture, a fundamental requirement, is the concept of "modularity". The justifications for modularity are broad, deep, and found in any text book on complex systems design and should not require review here. Among them is the notion that technologies evolve at different rates. The mechanisms for repair techniques are likely to evolve considerably, especially as "accessibility" extends to universal access on mobile devices and not just assistive technology for those with personal persistent visual impairment (I can't watch my screen while I'm driving). As these technologies evolve, any list of explicit potential repair techniques will become out of date, inappropriate, or even misleading. This kind of material does not belong in the HTML specification because it should be allowed to evolve independently. |
| Laura Carlson | Any User Agent image repair verbiage should be left to or vetted and coordinated with User Agent Accessibility Guidelines Working Group (UAWG). They are the domain experts. Any such verbiage in HTML5 would need to be carefully worded so the two specs are harmonized. Currently the two specs are out of sync. |
| Julian Reschke | I don't see any value in listing even more techniques; it doesn't help *any* consumer of the spec. |
| Cynthia Shelly | Repair techniques are out of scope for HTML5. The spec is already too long, let's not add more stuff. That said, this proposal is preferable to no changes. |
| David Singer | |
| Gregory Rosmaita | any such information belongs in the HTML5 Alt Techniques document, and should be mirrored by/aligned with WCAG 2.0 http://dev.w3.org/html5/alt-techniques/ http://www.w3.org/TR/WCAG20/ |
| Martin Kliehm | I don't think the repair techniques should be part of HTML5, but belongs into the domain of the WAI UAAG and ATAG. I'd like to point out that the issue should be addressed by authoring tools. An authoring tool can and should recommend authors to provide an alternative text. They interact with humans, so there's amuch better chance to get a good result than technically guessing what a human meant. Authoring tools accessibility guidelines are maintained by WAI. HTML5 should not be redundant. |
| Krzysztof Maczyński | The paragraph and suggested longer replacement are disproved of by notable accessibility experts and are widely believed to be far from consensus and from providing best possible guidance for implementors and authors. Also from this WG's angle it doesn't belong in HTML because of broader applicability. The right document to whose WG the collected suggestions should be passed for due treatment with expert attention (not excluding ours, just moving responsibility), refinement and probable inclusion is UAAG. In this way spec bloat (our big problem) will be avoided, concerns decoupled, architectural consistency maintained and independent evolvability assured. The same reasoning pretty much applies against the Change Proposal to Keep The Paragraph As Is. |
More details on responses
- Ian Hickson: last responded on 12, May 2010 at 08:09 (UTC)
- Matthew May: last responded on 12, May 2010 at 17:21 (UTC)
- Larry Masinter: last responded on 12, May 2010 at 18:25 (UTC)
- Laura Carlson: last responded on 13, May 2010 at 13:17 (UTC)
- Julian Reschke: last responded on 13, May 2010 at 16:32 (UTC)
- Cynthia Shelly: last responded on 13, May 2010 at 19:25 (UTC)
- David Singer: last responded on 18, May 2010 at 18:40 (UTC)
- Gregory Rosmaita: last responded on 18, May 2010 at 21:52 (UTC)
- Martin Kliehm: last responded on 19, May 2010 at 08:39 (UTC)
- Krzysztof Maczyński: last responded on 19, May 2010 at 19:23 (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