w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-30: include a longdesc attribute for images - Straw Poll for Objections
The results of this questionnaire are available to anybody.
This questionnaire was open from 2010-06-24 to 2010-07-01.
24 answers have been received.
Jump to results for question:
- Objections to the Change Proposal to restore longdesc as a fully conforming attribute
- Objections to the Change Proposal to keep longdesc non-conforming
- Objections to the Change Proposal to make longdesc conforming, but with a validator warning
1. Objections to the Change Proposal to restore longdesc as a fully conforming attribute
We have a Change Proposal to restore longdesc as a fully conforming attribute. 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 restore longdesc as a fully conforming attribute |
|---|---|
| Chaals Nevile | |
| Leif Halvard Silli | I support this proposal. However, I belive that we need to work more on making @longdesc useful as well. See my comments in my objetions to the other two proposals. Key questions: 1) URL validation to secure that @longdesc contains a valid and meaningful URL. Currently, Validator.nu performs no validation to secure that @longdesc contains a URL. While it _does_ check that e.g. @href contains a valid URL. (But perhaps it goes without saying that it would perform such checking if @longdesc becomes conforming/obsolete-but-conforming. Validator.nu in general doesn't report errors on obsolete features - the only error it reports is the actual use of the feature. It only checks errors on conforming featurs and obsolete-but-conforming features) 2) use of @role together with an <img> that uses @longdesc: Should an <img> with @longdesc permit/default to a certain @role? E.g.: <img role="img link" src="foo" alt="bar" longdesc="longURL">? 3) in what way is/should @longdesc taken into calculation by ARIA supporting ATs? |
| Michael Puls II | I object to this. longdesc is obsolete and I've never seen it used in the wild. Opera even supports it now, but it seems like an unused, waisted feature. Unused accessibility equals no accessibility. Any use cases for longdesc should be solved some other way with some new, better method. |
| Tantek Çelik | I strongly object to restoring the longdesc attribute. The longdesc attribute is badly designed, and has been harmful to accessibility. It is one of the worst forms of invisible metadata or "dark data" which are known to rot and become inaccurate over time (see: meta keywords, RDF in comments, sidefiles, etc.). It is VERY poorly named - seems to imply a "long description" as even this survey misstates it whereas it is actually a URL. Because it is invisible metadata and poorly named, the longdesc attribute encourages and causes misinformation about the image. This has been well documented: http://wiki.whatwg.org/wiki/Longdesc_usage Because it has been framed/claimed as an "accessibility feature" - this damage is particularly bad. On the rare occasion that a user finds an alternative browser that reveals the longdesc attribute, they will get a noisier (lower fidelity/quality) web experience. The existence of the longdesc attribute can cause a superficial sense of "false comfort/support" - because it exists and is alleged (falsely) to solve an accessibility problem, it can be used to reject alternative accessibility techniques or feature proposals. I have documented these additional reasons for strongly objecting to longdesc on the WHATWG wiki: http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc |
| Debi Orton | |
| Theresa O'Connor | The many problems with longdesc="" have been established for some time, and known alternatives not only exist, but are more likely to be used correctly by authors. Given this, to endorse longdesc="" in the spec is to engage in the worst form of accessibility theatre--to put the appearance of caring about accessibility over actually supporting accessibility. |
| Ben Boyle | I see no specific "harm" in keeping longdesc conforming, but I see no value either. I believe it would be beneficial to promote other techniques over longdesc, and restoring longdesc to conformance detracts from the importance of these other approaches — e.g. descriptions in the page augmented with aria-describedby, figure captions, SVG with appropriate embedded text. Even in the pre-HTML5 world, respected accessibility professionals recommend(ed) alternative approaches over longdesc. Great example right here: http://www.webaim.org/techniques/images/longdesc.php |
| Henri Sivonen | Longdesc has been shown to be a failure. This point has been made in the HTML WG numerous time and in many ways, but there is one particularly convincing email I'd like to highlight for the chairs: http://lists.w3.org/Archives/Public/public-html/2007Sep/0350.html I object to making longdesc conforming, because doing so would make Web authors continue to put effort into supporting the failed feature, which would be effort and attention away from accessibility features that aren't such failures. Misdirecting author effort to something that doesn't work is bad for accessibility, since effort only helps when it's directed into something that works. |
| Tab Atkins Jr. | I strongly object to restoring longdesc as conforming. As shown in the study referenced in the no-change proposal, less than a tenth of a percent of pages use @longdesc. This, by itself, isn't necessarily a problem - some features may be very useful in rare circumstances, but not needed the majority of the time. However, another study referenced in the no-change proposal showed that, of the instances where @longdesc is used, at least 99% of the uses are *trivially wrong in a machine-checkable way*. Hand-reviewing those that passed the machine check eliminated even more as invalid. A feature being almost universally used incorrectly is about as damning an indication of it being broken as is possible. Practice shows *very strongly* that @longdesc is a fundamentally broken idea for the web. Keeping it within the web platform does a disservice to the very users it's intended to help, by drowning the tiny amount of correct usage in a torrent of broken and useless usage, so that those users can't rely on the feature at all. It is crystal clear that those authors who wish to provide long descriptions of an image should be using something other than @longdesc to do so. |
| Jonas Sicking | I strongly object to restoring the longdesc attribute for the following reasons: 1. It is a poster-child for features that is very rarely used in a way that helps users. There is no stated reason in the change proposal, and no other reason that I can think of, why this feature would be used more in the coming 10 years than it has in the past 10 years. In other words, not only is there little reason to believe that the feature will actually help users, there is in fact data giving reason to believe that it will *not* help users. http://blog.whatwg.org/the-longdesc-lottery 2. There are better alternatives: the aria-describedby attribute. While this attribute does not have the full feature set, that longdesc has, in that it doesn't support directly linking to descriptions in external documents, no one has provided information indicating that the missing feature set is one that users are requesting. On the contrary, aria-describedby more strongly encourages providing accessibility information in-page which many more users prefer. 3. The proposal provides two rationales for adding longdesc: 3a) "it has been implemented multiple times successfully". This does not seem like a rationale for putting a feature in the spec. It only removes a potential argument for removing a feature. Additionally, information of which "multiple times" is referring to is missing. I personally only know of one implementation in opera and one in firefox. And the one in firefox was so poor and received so little usage that it has been removed from later releases. So I wouldn't qualify it as a "successful" implementation. 3b) "[users] can still benefit from a *good* usage". While this is true, it is almost entirely hypothetical as usage over the past 10 years have in fact not been good, and no rationale is given for why usage would improve in the future. 4. I strongly believe that the simpler and more clearly we can communicate how to improve accessibility, the more successful we will be at it. Thus I believe that saying "to add a description to an image, either use the longdesc attribute, which contains a uri, or use the aria-describedby attribute, which contains a list of identifiers, or use a normal link pointing to the description. If you are using the longdesc attribute, we encourage you to not use a uri pointing to a different page, but rather link to a specific section in the same page using the #foo syntax" will be less successful than saying "to add a description to an image, or use the aria-describedby attribute, which contains a list of identifiers, or use a normal link pointing to the description." 5. I am worried that if people indeed decide to spend time on adding accessibility attributes, that they'll use the longdesc attribute to do so in a way that users do not prefer. The data on http://webaim.org/projects/screenreadersurvey2/#images shows that people generally prefer to get the information in the same page, whereas longdesc does not encourage this. If the same accessibility-minded person was faced with a spec that didn't have longdesc but instead encouraged the use of aria-describedby, then it's likely that the page would be more accessibility friendly to more people. 6. If we add longdesc to the HTML5 I believe we are setting a very bad precedence. That would mean that as long as a feature can be demonstrated to be implemented we will add it to the specification, even if it can't be demonstrated to actually help a significant number of people. Possibly it can be argued that the precedence only applies for accessibility feature, though I don't think that is in any way better. In fact, accessibility is in general an under invested area for HTML implementations, and so we should be extra picky there with features that we think is important for implementations to spend time implementing. By making longdesc non-conforming in this version of HTML, we can likely remove it in future versions, thus freeing up implementors time to work on other accessibility features, as the usage out there is doesn't seem to be large enough that it will forever be unfeasable to remove it from HTML. |
| Aryeh Gregor | The other change proposals cite very strong evidence that longdesc is used very rarely and almost always incorrectly. This means that user agents will not expose it routinely, because doing so would expose much more useless noise than helpful information. Even if user agents did expose it, users would quickly learn to ignore it based on the overwhelming number of useless usages, so they would miss any actually useful usages. What this means is that the feature provides basically no value to users. Authors should be informed of this somehow, at least by a warning. Even if they use it correctly, it doesn't help a significant number of users, so they need to be aware that they have to provide the description through some method that's actually available to users. Raising not even a warning will give even fully competent authors a false sense of security that their description is available to typical AT users. More to the point, though, practically no authors do use the feature correctly. If 99% of longdesc uses are useless, then (roughly speaking) telling authors to just remove the attribute will improve the utility of the page 99% of the time and hurt it only 1% of the time, in a UA that exposes longdesc. When a feature is misused overwhelmingly more often than it's used right, it actually hurts the utility of a language, and the language would be better if it were removed. (Unless the correct uses are very useful and the incorrect ones are only very mildly harmful, but that doesn't seem to be the case here.) As such, I object to this change proposal. It would legitimize the use of markup that's nearly useless at best, and very likely harmful. This is exactly the type of markup that validator errors and warnings should be used to discourage. |
| John Foliot | |
| David Singer | I feel that there is ample evidence that longdesc has been so badly abused in practice that preserving it gives the pretense of serving accessibility while, in fact, not providing it. We can and must do better. It should be either non-conforming, or, if backwards-compatibility is needed, conforming but obsolete or conforming but warned (options 3 and 4 of this quetionnaire). |
| Sam Johnston | longdesc, in the extremely unlikely event that it is used, is more often than not misused or abused. It is a distraction for implementors and designers alike and the information it contains is generally better made visible within the document itself where all users can benefit from it. Perhaps most importantly though is that while its intention is to improve accessibility, it may actually harm it by increasing the workload for those who choose (or are required) to go down this route. Overall I see no reason to keep it and every reason to remove it. |
| Laura Carlson | |
| Jens Oliver Meiert | @longdesc is rarely used in practice (.13 % of pages analyzed in 2007), and if it is used it’s rarely used correctly. There is no benefit in keeping the attribute, neither for users (accessibility) nor authors (maintainability). |
| Gez Lemon | |
| Andrew Wilson | Making longdesc a fully conforming attribute has a set of implications - it asserts that: 1) web authors *should* use it 2) screen readers *should* support it 3) users will gain value by paying attention to the data supplied by this attribute Given the overwhelming data showing that this attribute is in practice nearly universally used incorrectly, it is no surprise that in practice longdesc is ignored by both users and screen readers (as described here: http://lists.w3.org/Archives/Public/public-html/2007Sep/0350.html). It seems clear that encouraging web authors to use this attribute actively harms the accessibility community by directing authors to present information where no end user will find it, and by discouraging authors from using other forms of presenting this data to the user in a way that will actually be accessed. |
| Lachlan Hunt | I strongly object to this proposal on the grounds that no compelling use cases - in fact, none at all - have ever been presented by advocates for longdesc. It is thus not at all clear what problems are revealed by such use cases, and no analysis has ever, nor could have ever, been performed to demonstrate why longdesc would be an optimal solution in preference to the many other available alternative techniques. The LongdescRetention [1] wiki page claims to list use cases, but the information provided there is not even close to being a list of use cases. It merely contains a list of the kinds of people, and their disabilities, who may benefit from the provision of alternative content. There is no description of what kind of images may be published, nor what information the publisher may be trying to convey, nor any description of the kind of information a user may be attempting to obtain. Without any of that information, there is absolutely no way to evaluate the bogus use cases in a way that would reveal their specific problems that need solving, nor which of the many possible solutions would even be suitable. The subsequent "analysis", for lack of a better term, provided in that page then proceeds to list pros and cons for individual solutions, without ever referencing what use cases they would or would not be appropriate for. The correct way to perform a real analysis of this, would have been to derive specific problems from valid use cases, and then determine the requirements that any given solution would need to meet in order to address each problem. These requirements could then be compared with available solutions to determine which solutions work, which don't work, and which is best. Without this, it is simply impossible to know whether or not there are any problems for which longdesc may be the only adequate solution. Because no such evidence has ever been presented, any claim that longdesc is useful or necessary to solve any problems is completely unsupported and must be rejected. It is also clear that the functional design and interaction model of longdesc does not lend itself to the creation of well written alternative content that is actually useful to end users, even in the unlikely event that an end user finds it. There are arguments based on the idea that hidden metadata is useful for some unspecified use case, with the supposed problem that any additional information that may be referenced by longdesc, must be hidden from the vast majority of users, and not otherwise affect the design of the page. Such arguments are misguided, because it is far better for accessibility for such issues to be considered a prominent part of the page's design and/or user experience from the outset, and for the accessible content to be treated as a first class citizen of the site. Hiding it behind the longdesc attribute, or any other similar method, effectively treats it as a second or even third class citizen which has been clearly demonstrated to result in suboptimal alternative content that never actually helps those it's intended to. Besides, even if there were such a case, there are ways of designing and building a page using a wide range of existing techniques, such that the accessible content remains accessible to those who need it, but where it is not so prominent as to be a distraction for those who don't. I also concur with the arguments pertaining to the widespread misuse of longdesc, its failure in the marketplace among implementers, authors and, most importantly, end users. [1] http://www.w3.org/html/wg/wiki/LongdescRetention |
| Joshue O'Connor | |
| Denis Boudreau | |
| Ojan Vafai | I object to this proposal. longdesc is not a good solution to the problem (as evidenced by it's current lack of use and abundance of mis-use) and is not needed for web compatibility. As such, we are free to come up with something better. |
| Monika Trebo | |
| Benjamin Hawkes-Lewis |
2. Objections to the Change Proposal to keep longdesc non-conforming
We have a Change Proposal to keep longdesc non-conforming. 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 longdesc non-conforming |
|---|---|
| Chaals Nevile | This proposal fails to adequately address two functionalities of the longdesc attribute. 1. A direct, reusable reference to a description of an image. 2. A method to reference a longer description of an image, without including the content in the main flow of a page. The failure is more serious in the first case than the second. It may happen that a future revision to ARIA can provide the necessary functionality in a more generalised, and more useful way, but that is not currently the case. This functionality is only going to be relevant to a fraction of images on the Web - and where even functional alt attributes are missing it is a minor case overall. Nevertheless it is valuable when it works, and effort to improve accessibility can likely be minimised by building on what we have. While the attribute is badly implemented in general, in recent years it has been implemented in a couple of pieces of browsing software (Opera, JAWS+browser) and the framework to use it is in place for Wikis. It seems reasonable to assume that, like the slow but steady growth in use of the alt attribute (still only a minority case, but widely regarded as successful when ten years ago it was widely regarded as an unreasonable requirement for accessibility), improvement in software will lead to a slow improvement in usage. |
| Leif Halvard Silli | I object to making @longdesc obsolete. The justification is as follows: My reading of the WebAim survey predates Ian's longdesc proposal and differs from his conclusion: [1] http://lists.w3.org/Archives/Public/public-html/2009Nov/0056 Summary: A) I present another reading. B) Ian applies a narrow perception of @longdesc. C) the traditional @longdesc model is not as bad as claimed. Ian says most users don't like they way @longdesc usually is expected to work. But although I disagree with that narrow/typical perception of how it should work, the traditional way deserves its defence, as well: @longdesc usually works like an <a> element with a target="_blanK". (iCab, Jaws and others) And that interaction model also has its advantages - including that it works when ARIA and JavaScript is failing. For a descripiton of some usability advantages of the traditional @longdesc model see this message: [2] http://lists.w3.org/Archives/Public/public-html/2008Feb/0299.html Summary: a @longdesc URI could very well open in a new window, even if the longdesc URI merely points to a fragment within the same page - that model has some advantages: It means that the user can open the long description - wherever it is located (same page or another page), read it and close - or change - the window, and be back at the same location where he was when he/she followed the longdesc URL. I believe some (of the WebAim survey) users reacts description links on other pages, if - to follow that link - you lands on a different page. Because when you navigate to the new page, you may also loose the context - in some AT program - on the current page. E.g. to simply hit the back button may not bring you back to the location you were at before you followed the link. However, with @longdesc, since the description (usually) opens in a new window, the reader can open it, without being afraid of loosing context - all it takes to continue the reading, is to close the window with the longdesc URL. It is important that a @longdesc basically is only a link. How can links be described as having a problematic interaction model? They are the key thing of the Web. Authors have dozens of ways to tailor how links are opened and what they opens. E.g. a link can lead to an AJAX resource - thus the long description could indeed be on another page, but still be perceved as being on the same page by the user. And, as the <a href="#top">Take The Acid2 Test</a> link on the ACID2 page shows (http://acid2.acidtests.org/), one can hide the the target to which the link leads, and reveal it when the link is activated. The user experience, when clicking that link, is that thee page is updated with new content. Users who don't look a the URL bar, may even think that they arrived at a new page. Now, imagine that that link was an <img> with a @longdesc URL: <img longdesc="#top" src="foo" "alt="Take The Acid2 Test" >. (And also imagine that there was a reason to have a long deescription, of course!) Iit could then make sense to open that URL/link in a new window - the fact that the actual long description is located on the same page is not important - it is the user experience that is important. And the user experience would in this case be the same regardless of whether the @longdesc URL pointed to a fragment on the same page or to another page. ACID2: [3] http://acid2.acidtests.org/ As for ARIA-* then ARIA currently has no clear way to point to a long description on another page. In case of <img aria-describedby="alink"><a id="alink">Long description</a>, then the <a> element does in fact not contain the long description. There is also a general problem of making features obsolete: making features obsolete means that validators stop checking that they are used correctly. Henri's splendid Validator.nu HTML5 validator is a good example. It checks the URLs of @href, @src etc. But Validator.nu does not perform any testing of @longdesc, since it is obsolete. The keeping/making of @longdesc as obsolete involves a (justified!) high trust in the effect of validation – authors pick up "messages" from validators, the obsolete status will impact on whether authors use it. On the other side, keeping/making it obsolete will only underline the bad situation of today, which to a not small degree seems to be caused be the comination of @longdesc being a 'specalized/seldom used attribue' on one side, while on the other side, the HTML4 validators lack of URL validity checking. (The HTML4 validator also do not check @href URLs, however @href is so universially understood that authors does not need help from the validator to understand it.) Exactly because @longdesc is so specialized, it had been important, during the 12 years of its existence, to check that it did contain a URL. There are many examples of @longdesc containing simply plain text - words - because authors misunderstood it. Invalid and meaningless URLs should be a validator checkable feature - this way we should be able to catch up to 96% of all @longdesc errors, if I have gotten Mark Pilgrim right. Pilgrim: http://blog.whatwg.org/the-longdesc-lottery |
| Michael Puls II | |
| Tantek Çelik | I object to the misleading naming of this survey question. "keep longdesc non-conforming" could easily be misread as "keep longdesc" and make it "non-conforming" in the spec. |
| Debi Orton | I object to making longdesc non-conforming. Several years ago, I polled several user groups comprised of visually impaired individuals regarding the utility of longdesc for artwork and other complex visual content. The majority of responses I received were in favor of using longdesc in such a way. Several of the respondents went on to explain that they were late-blinded and reading longdesc entries helped them visualize the object being described. I teach web development, and I always teach longdesc and how to use it effectively. |
| Theresa O'Connor | |
| Ben Boyle | |
| Henri Sivonen | |
| Tab Atkins Jr. | |
| Jonas Sicking | |
| Aryeh Gregor | |
| John Foliot | I strongly object to a backward slide on any accessibility feature previously implemented in earlier versions of HTML. Spurious claims of 'harm' to accessibility caused by @longdesc are nothing more than FUD. While ARIA describedby is a workable solution in some instances, the inability to reference URI's (http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby) in the current ARIA Draft Specification limits it's ability to fully replace @longdesc - for example when a content author does not want to include any text on a page for design considerations. Insisting that content authors thus write the description in the same document and then move off screen using CSS is an awkward workaround. As part of this objection, I would be willing to support "Longdesc Conforming With Warning" (following in the footsteps of the current @alt validator warning 'solution') which I see as an opportunity for offering good author guidance: *IF* a better alternative means of providing extended information regarding a complex image can be used, content authors may do so, but it in no ways removes the option of using @longdesc when/if appropriate and any "warning" should be phrased as an advisory, and not an admonishment for using @longdesc. |
| David Singer | |
| Sam Johnston | |
| Laura Carlson | SUMMARY We are talking about a concrete HTML 4 feature with normative text. This is not an editorial issue. Longdesc is a specified known method for doing a specific thing, which if used properly, will provide a known result. Some implementers have implemented it. Some authors do use it. Other standards, guidelines and laws depend on it. Longdesc provides for rich, expressive documentation of a visual image to the blind or visually impaired. It is useful to users. I strongly object to making it non-conforming. I strongly object to the removal of longdesc from the HTML language at this time. User and author needs deserve to be addressed. HTML5 does not provide an equivalent or alternative mechanism. A functional replacement does NOT currently exist as Chaals illuminated. Use cases for longdesc and aria- describedby are related, but significantly different that both should remain tools for content authors. OTHER STANDARDS, GUIDELINES, & LAWS Longdesc is a technique recommended in both the WAI guidelines [1] and the Section 508 standards [2]. Standards issued by the Access Board under Section 508 of the Rehabilitation Act cover access to electronic and information technology procured by United States Federal agencies. One example: longdesc is an official part of United States Postal Service policy [3] It has also trickled down to States and State agencies. For instance, longdesc is a recommended solution in many University Web Standards like the University of Minnesota. [4] Longdesc is part of Dutch Accessibility Law (section R-pd.7.3) [5] Translation: "Do not use d-links on government websites. The use of longdesc (long description) attribute is preferred if the alternative text in the alt attribute is inadequate for understanding the information in the image." AUTHORING TOOLS Longdesc is implemented authoring tools, such as Dreamweaver and XStandard. UTILITY & NO CURRENT REPLACEMENT Many images cannot be sufficiently described with other long description techniques. For instance, longdesc currently provides a solution for describing the content of pie and flow charts to the blind when 1.) it would be not only visually apparent and redundant to a sighted person but 2).) it would also be completely unacceptable to the marketing department due to aesthetic considerations. There is currently absolutely no other direct way of doing that without a longdesc. As Gez Lemon has further explained [6], aria-describedby does not provide a functional replacement for longdesc. aria-describedby will annotate text in the target id referenced by the idref. This means assistive technology users would not be able to control how they interact with the long description (as they can with longdesc). As, by definition, a long description is in fact long, aria-describedby is not good solution for a longdesc. Some future feature that that moves the user's reading cursor to the longer description in a different page where the user can control how they read the long description could be a possible solution. But some future version of aria-describedby is out of scope for this decision. It does not exist. And even if some future version of aria-describedby did provide the same functionality as longdesc, which it currently does not, aria-describedby lacks browser support. IE 8, Opera and Safari browsers on Windows do not support aria-describedby [7]. It was recently announced that IE9 will not support aria-describedby. [8] USAGE & IMPROVEMENT: Don't throw it away; make it better. No set number of use cases proves a feature should be included or excluded from the spec. There can be reasons a feature in the language is not used much. Accessibility features address failure modes that are infrequent, but critical when they occur. People with disabilities are a minority. The number of images that require a long description are few in proportion to the total number of images in existence. Other mechanisms work for the majority, that's fine, but it is unacceptable to rule out the accessibility edge cases based on numbers, or necessarily how difficult they are (although easier is always better). The very idea that longdesc should be eliminated because it has not been used much or has not been used correctly is counter productive. Access for people with disabilities is essential. Features should not be omitted if not all users can fully make use of them, but rather mechanisms like longdesc must be provided, when there is no better replacement. When you throw away a feature, an outlandish amount of money is wasted, as a base already exists (tools, tutorials, dependent policies, etc.). Incremental renovation: tinkering, improving, is more productive than bulldozing a feature flat. Bugs can be solved, one at a time, by careful thinking, collaborating, factoring, making incremental changes, optimizing. When a useful feature is used incorrectly we should figure out how to improve it, not throw it away. Specific suggestions are in my answers to the last question on this survey. -- [1] http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H45.html [2] http://www.section508.gov/index.cfm?FuseAction=content&ID=12#Web [3] http://www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr13 [4] http://cap.umn.edu/ait/web/TablesAndCharts.html [5] http://www.webrichtlijnen.nl/besluit/tekst-besluit-en-toelichting/ [6] http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq2 [7] http://www.paciellogroup.com/blog/aria-tests/aria-labelledby-input.html [8] http://lists.w3.org/Archives/Public/wai-xtech/2010Jun/0020.html |
| Jens Oliver Meiert | |
| Gez Lemon | There is a definite need to be able to provide long descriptions for some images. There is no replacement for a long description in HTML5 or ARIA. ARIA has aria-describedby, but that doesn't allow the user to control how they interact with the longer description - it's just forced on the user as a string of text. The user needs to control how they interact with the long description, and the longdesc attribute provides that capability. |
| Andrew Wilson | |
| Lachlan Hunt | |
| Joshue O'Connor | I object to keeping longdesc non-conforming. It should be retained, improved and better supported. /Any/ HTML element can be abused, this is not sufficient reason to remove them. There is no sufficient replacement/alternative in HTML 5, so @longdec should be retained, its functionality improved etc. Also citing lack of awareness among users, or people with disabilities is not reason enough to remove the attribute. We cannot expect users to be conversant with the minutiae of the tech they use. It's like asking the patient if they know what the spleen does, and if they say 'no' - do we suggest that the doctor removes it? |
| Denis Boudreau | As long as there won't be a proper mechanism in HTML5 or ARIA for users to control how they interact with a longer description provided in another document, I strongly object to keeping @longdesc non-conforming. |
| Ojan Vafai | |
| Monika Trebo | Users turn to the internet to find relevant information faster than in other media. Sighted users screen a web page and decide if it contains relevant content within mere seconds. It has been stated by some members of the HTML WG, that even web accessibility specialists question the usefulness of longdesc and we should expose that content to all users instead. Some alternatives to longdesc, as for example described in http://www.webaim.org/techniques/images/longdesc.php may however, negatively impact usability for sighted people by adding long passages of descriptive text that is irrelevant to them (eg: it is of no use for a sighted user to read that ”The cat in the photo has brown fur, with a white spot on the nose, white paws and blue eyes”), forcing them to screen more information. Slowing users down by explaining them in detail what was obvious for them to begin with is a usability issue that may discourage content authors to provide such information altogether. Furthermore, adding descriptive text on the same page might create an accessibility issue for people with cognitive disabilities, by adding to information overload. Exposing descriptive text in the flow of a document may also push relevant information below the fold. It is therefore preferable to find a way to hide such information from users who don’t need it. It is true that longdesc is not widely adopted and often not correctly implemented, but this cannot serve as an argument to mark it as deprecated. Nobody thinks of abandoning the title tag, just because we have thousands of <title>Untitled Document</title> out there, and we are not considering to abolish conformance checking, just because only a few percent of web pages may actually validate. One reason for longdesc not being used more widely, maybe the fact that the person developing or maintaining a web site is hardly ever the person who provides the content. I cannot imagine, that a web designer/developer would be capable of creating a useful description of the content of a medical image or graphic in a research paper. Also, web sites are often being maintained by web authors with little or no knowledge of web technologies. The problem with missing long descriptions is not caused by the attribute itself. Therefore, the situation is unlikely to improve with a replacement, especially should it be more difficult to implement. Furthermore, we do not have a functional alternative yet. The solution should be education, rather than abandonment of longdesc. I strongly object to making longdesc non-conforming. |
| Benjamin Hawkes-Lewis | WCAG2 defines text alternatives as "programmatically associated" with content. Long/complex text alternatives should ideally be programmatically associated with img elements so that UAs can provide rapid access to text alternatives without requiring authors to "include… the information inline" and users to consume content linearly, and without requiring users to locate text alternatives manually from references or links. I object to this change proposal because it disallows a native feature ("longdesc") for programmatically associating "img" elements with long/complex text alternatives, leaving HTML dependent on ARIA (specifically "aria-describedby") for a subset of the same functionality. This is a problem because: * The WAI-ARIA working draft states that ARIA is intended to be a "bridging technology", expects that host languages will evolve to provide ARIA semantics natively, and suggests authors should prefer native semantics. * While the WAI-ARIA draft does at least allow any user agent to reflect ARIA semantics in its UI, it's not clear that this can be done without conflicting with author implementations and in practice popular browsers seem to be implementing ARIA only by exposing its semantics to the DOM and to platform accessibility APIs, which practically limits its utility to users of AT that makes use of the DOM or APIs. * A key implementor (Microsoft) are reluctant to actually implement the proposed replacement feature "aria-describedby" (as Laura Carlson mentions) even though they've implemented "longdesc" (http://www.paciellogroup.com/blog/?p=43). * The more technologies required to make documents accessible beyond native HTML features, the more complex the author's task becomes and the less likely we are to see accessible results. To address the proposal's rationales: * "The longdesc='' attribute is extremely rarely used". This appears true, but in my view it is unscientific to conclude automatically that this reflects the intrinsic quality of the design of the feature rather than the relative rarity of images requiring long descriptions, flaws in previous spec text, and the general lack of commitment to accessibility by implementors and authors. * "longdesc='' is extremely rarely used correctly". This appears true, but historically many authors motivated and capable of using "longdesc" correctly have been advised not to use it (thanks to lagging implementations), so again it is not clear the sample reflects the intrinsic quality of the design of the feature. It is also unclear how much impact this incorrect usage has on real-world popular web usage, and how easily it could be fixed. For example, how would the landscape change if the Wikipedia codebase stopped misusing "longdesc"? * "Most users (more than 90%) don't want the interaction model that longdesc='' implies." While suggestive, the cited study does not suffice to justify this claim. The "users" include expert testers without disabilities rather than being typical target users. Further, the "interaction model" favoured by less than 10% of participants ("On a separate page, announced by and available to my screen reader") need not apply to "longdesc" values that point to a same-page fragment, while "longdesc" values that do point off-page could perhaps be presented to users as a normal link with generated link text (an interaction model favoured by 20% of participants: "On a separate page, available by following a link"). * "Users that try to use longdesc='' find it doesn't work". If this sample of one user (!) is in fact representative, this likely reflects the incorrect usage already discussed. To address Tantek Çelik's further rationales: * "The longdesc attribute is … is one of the worst forms of invisible metadata". This argument - should the WG choose to accept it - applies only to "longdesc" values that reference off-page resources. "longdesc" can also be used to reference same-page fragments. * "It is VERY poorly named - seems to imply a "long description" as even this survey misstates it whereas it is actually a URL." For better or worse, typically HTML attribute names do not declare their data type in their name (e.g. "src" not "srcurl", "alt" not "alttext", "for" not "forid"). If the WG wants to provide native programmatic association, but agrees with the proposal and Tantek that allowing "longdesc" to reference off-page resources pose an accessibility risk, the WG could retain "longdesc" with the following changes to mitigate its problems: 1. Make it non-conforming when "longdesc" links off-page. While I think being able to meet external design requirements by referencing an off-page resource is useful despite the risk of link rot, this would still allow programmatic association with a native HTML feature and authors could hide alternatives off-screen with CSS if necessary ("awkward workaround" though it may be). 2. Specify how user agents should detect and discard the machine-detectable subset of erroneous "longdesc" values. Alternatively, if these are found not to mitigate these problems, the WG could mint a new "describedby" attribute, applicable at least to the "img" element, that would parallel "aria-describedby" in behaviour (or perhaps a "description" element that could be associated with an "img" using "for"). But given that this would have poorer backwards compatibility than "longdesc", and given that (as the proposal admits) user agents may need to continue to process "longdesc" for backwards compatibility with existing content, I'm not sure this would be preferable to modifying "longdesc". |
3. Objections to the Change Proposal to make longdesc conforming, but with a validator warning
We have a Change Proposal to make longdesc conforming, but with a validator warning. 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 make longdesc conforming, but with a validator warning |
|---|---|
| Chaals Nevile | |
| Leif Halvard Silli | It is my understanding that this proposal suggest to make @longdesc obsolete-but-conforming. And on the condition that HTML5 specifies that the (hypothetically) obsolete-but-confomring @longdesc must undergo _the same_ rigorous conformance validation as the a@name attribute (which is obsolute-but-conforming as well), then I can live with making it obsolete-but-conforming. Stated another way: I object to this proposal, if it means that @longdesc _does not_ get such a rigorous testing. However, making @longdesc obsolete-but-conforming on that condidtion, would involve specification of so many things, that it would make more sense to define it as fully conforming. I'll much rather see serverely strict validation criterias (in fact, that is what I would like to see!) together together with full conformance, than any form of automatic warning just because of the very presence of @longdesc. I believe that @longdesc will get a more "serious" specification if we plan it to be conforming. If we allow it to be obsolete&conforming, it _may_ get a sloppier definition and boiler-plate warnings like "use @aria instad". Please note that a@name is an exception. Most the other obsolete&conforming features, have severe restrictions on their use. So if @longdesc undergoes the same cheecking as a@name, it means that Validator.nu must start to check whether the @longdesc URL is a valid URL - the same way that Validator.nu already checks whether @src and @href contains valid URLs. (HTML4 did not check URLs for correctness.) This is highly relevant, as Mark Pilgrim has stated (see link in the proposal) that 96% of @longesc URLs today are either invalid (often they typed in words instead of an URL), the empty string or in other ways totally meaningless. (A probable reason why @longdesc became a fail is the lack of URL checking.) Thus, I want it to be very clear, that if @longdesc becomes obsolete-but-conforming, then we must also make sure that it is checked properly for correct use. The irony then, is that HTML5 would deprecate @longdesc on one side, while on the other side, put it to more rigorous tests than HTML4 did (and thus ensure more correct use) on the other side. As for a warning: One would have to be very careful with the kind of warning. There isn't universal agreement that @longdesc is always worse than using @aria-describedby. Yes, @aria-describedby has some advantages. But it is not for pointing to other pages. See what Charles said about the same in his response to Ian's proposal. If @longdesc points to another page, then an advice to use @aria-describedby "instead", becomes quite complicated - it would have to involve advice about rewriting the page. Another thing that we need to work out, if @longdesc becomes either fully conforming or obsolete&conforming, is how it fits into the ARIA map: Should an <img> with a @longdesc imply a certain @role, for instance? And isn't it possible that ARIA @role could come @longdesc to the rescue? Take Mark Pilgrim's comment in his longdesc-lottery article, about the fact that Josh's client (in the user experience test of @longdesc) "didn't know that longdesc even existed". Well, most users, what do they know about how web pages works? The page must be quite lousy if it makes the user think about why and how it works. Many users have some concept about links, but do they know that JavaScript can make things works like links? Perhaps @role can be used to make sure that an <img> with @longdesc is perceived - for example - as a link or an image link, by AT users? I offer, as an idea, the following, which validates when against the HTML4 ARIA DTD (http://www.w3.org/TR/wai-aria/appendices#html_dtd): <img role="img link" src="statistics" alt="The curve goes up" longdesc="longdesc.html" >. With HTML5, we have the option to also require that @longdesc always is used together with a certain @role. Or to require that @longdesc implies a certain @role value. As Ian said: @role is - or could be - a godsend. I've also filed bugs for the things that needs to be dealth with, if _this_ proposal, _or_ the proposal to make @longdesc fully conforming, goes through: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10015 (longdesc URL checking) http://www.w3.org/Bugs/Public/show_bug.cgi?id=10016 (longdesc and @role (ARIA)) http://www.w3.org/Bugs/Public/show_bug.cgi?id=10017 (longdesc and @aria-describedby (ARIA)) |
| Michael Puls II | I object to this. A warning isn't strong enough. Longdesc should not be used. It's an obsolete, unused feature. |
| Tantek Çelik | I have strong objections to adopting this change. Any variety of keeping longdesc sends the wrong signal to web designers/developers. Because it is so broken (see http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc ) we must thoroughly reject it. |
| Debi Orton | This seems counter-intuitive to me. Either an attribute is conforming or non-conforming. What would be the purpose of providing a warning about a conforming attribute? I feel it would only confuse the developer population. |
| Theresa O'Connor | For the same reasons as my answer to (2) above, I object to any endorsement of longdesc="", even with a mandatory warning attached. |
| Ben Boyle | |
| Henri Sivonen | Longdesc has been shown to be a failure. This point has been made in the HTML WG numerous time and in many ways, but there is one particularly convincing email I'd like to highlight for the chairs: http://lists.w3.org/Archives/Public/public-html/2007Sep/0350.html I object to making longdesc conforming, because doing so would make Web authors continue to put effort into supporting the failed feature, which would be effort and attention away from accessibility features that aren't such failures. Misdirecting author effort to something that doesn't work is bad for accessibility, since effort only helps when it's directed into something that works. |
| Tab Atkins Jr. | I strongly object to this change proposal. A study referenced in the no-change proposal claims that over 99% of actual @longdesc usage is fundamentally incorrect. Making pages that use @longdesc in such a broken manner validate will not help blind users and others who might benefit from a long description. When a feature is almost universally misused and is in practice ignored by precisely the users it is aimed for (many screenreaders ignore @longdesc entirely, and many users with screenreaders that don't ignore @longdesc ignore @longdesc manually anyway), allowing it to validate helps no one and only serves to prop up bad, useless practices. |
| Jonas Sicking | I object to this change proposal for much the same reasons as I object to the "Change Proposal to restore longdesc as a fully conforming attribute". However given that the rationales are different change objection point 3 to: 3. The proposal provides two rationales for adding longdesc: 3a) "[some extra accessibility minded sites] may be relying on longdesc to improve the experience, and it would be disruptive to immediately make such content nonconforming". First of all no data is used to back this statement up. Yes, it may be the case, but as far as I can see in the change proposal, it appears to be a unsubstantiated guess and thus not a good basis for spec writing. Second, making such content non-conforming "immediately" isn't very disruptive as implementations aren't requested to be changed "immediately". The spec doesn't make any changes as far as implementation requirements goes compared to HTML4. My interpretation of this argument is that instead of phasing things out by going from conforming to deprecated to removed, it is asking for the deprecation process to be going from conforming to conforming-with-warning to deprecated to removed. However this is a process not used anywhere else as far as I know, and no rationale is given for why an exception should be used here. 3b) "Some laws, regulations and organizational policies may refer to longdesc by name". However no examples are given and as far as I can tell looking at the change proposal, this is just an unsubstantiated guess and thus not appropriate to base spec writing decisions on. |
| Aryeh Gregor | |
| John Foliot | |
| David Singer | |
| Sam Johnston | Refer to my "Objections to the Change Proposal to restore longdesc as a fully conforming attribute". In the event that we decide to make longdesc conforming I would prefer it was with a warning than without. |
| Laura Carlson | SUMMARY I strongly object to warning for the presence of a longdesc. A warning for a proper longdesc is simply wrong. People should not be reprimanded for doing the right thing. A longdesc provides for rich, expressive documentation of a visual image. It is used when other techniques are insufficient to embody the visual qualities of an image. The aim is to use any length of description necessary to impart the details of the graphic. If the information contained in an image is important to meaning (i.e. some important content would be lost to the visually impaired or blind if the image was removed) and no other technique works, longdesc should be used. Sometimes this content won't fit on the same page or is redundant for sighted users. So when people are doing it right, don't warn them. Applaud them. Tighten the language to foster improved use. Provide validator errors and warnings for genuine syntax mistakes. Encourage native user agent support for exposing longdesc to all users. ERRORS AND WARNINGS FOR SYNTAX MISTAKES Warnings or errors should be used for author mistakes in the language rules of longdesc. If the validator flagged such things as the value of a longdesc being a text string and not a URI, it would create a teachable moment. A moment of great opportunity: a time to educate, to make people aware, and to get action, to get people to actually fix their mistake. Errors are not a negative reflection on developers, but rather a critical pedagogical feedback tool. W3C HTML4 validator has done worlds more than the HTML4 specification for increasing the quality of HTML documents on the web. Using validator errors and warnings is a golden opportunity to educate the author about proper use of longdesc. I fully support warnings and errors for syntax mistakes. IMPROVING LONGDESC If the attribute needs improving, let us improve it. Bugs have been filed in this effort. For instance since the longdesc attribute's value is the URI of the description and sometimes developers can get this wrong, an error or warning for any other type of a value other than a URI would be appropriate and beneficial. Check syntax to ensure that it is a URI. This is just a small part of Leif 's syntax checking bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10015 Longdesc as "hidden meta-data" is a fallacy. [1] As Gregory Rosmaita has often stated, the term "hidden meta-data" [2] is pejorative, and not an accurate description of attributes such as longdesc. Rather the term should be "discoverable meta-data", which means it doesn't matter if it is displayed visually or not, but in a way the user can access it in accordance with that user's individual preferences. A bug has been filed for user agents to natively possess the option to reveal the presence of longdesc to all users. This would provide a practical method for developers who want a tool to check longdesc and keep it up to date. It would also allow the longdesc attribute to keep its purpose in aiding those with disabilities and others. Giving everyone access to longdesc content would afford universal design. Bug 10019: "Native user agent support for exposing longdesc to all users" has been filed. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10019 Gregory has brainstormed strategies to support longdesc natively in a User Agent. http://www.w3.org/html/wg/wiki/Talk:ChangeProposals/longdesc#Strategies_for_Exposing_LONGDESC Bugs regarding longdesc and aria have also been raised. http://www.w3.org/Bugs/Public/show_bug.cgi?id=10016 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10017 CONCLUSION: Tighten the language to foster improved use. Provide validator errors and warnings for genuine syntax mistakes. Encourage native user agent support for exposing longdesc to all users. These types of actions will promote better use of a useful accessibility feature. When longdesc is written correctly and points to the URI of the description, it should be fully conforming. No warnings. Telling an author, "it is WRONG to use longdesc" is unacceptable. -- [1] Germane to the "hidden meta-data" fallacy is the fact that the Web is not a visual medium. It never has been. It's an electronic communication medium, both audio and visual, both print and screen etc. Even though the majority of users have vision and use visual means to access content doesn't make the web a visual medium. It is multi-modal. Perhaps some web developers concentrate on a particular media type more than another. And perhaps on many web sites, sighted, dexterous, able-bodied users outnumber users with a disability. But the strengths of the web, which makes it unique as a medium of communication, is that it isn't limited to a single output. That is the beauty. What it comes down to is the ability to of a user to access information. A focus on the user stems from an understanding of why people are coming to a web site: Information. HTML5 should provide features to access information regardless of the methods users use to access it. As Jeff Jaffe said, "There is little dispute that we should work towards a Web for All." http://www.w3.org/QA/2010/06/the_mission_of_w3c.html [2] http://lists.w3.org/Archives/Public/public-html/2010Jan/0583.html -- Question: Maciej wrote this proposal. Will he rescue himself from deciding this issue? |
| Jens Oliver Meiert | |
| Gez Lemon | Providing a long description is a helpful feature, so it doesn't make sense to warn people they are doing something wrong when they are not. |
| Andrew Wilson | |
| Lachlan Hunt | Refer to my objections under "Objections to the Change Proposal to restore longdesc as a fully conforming attribute". |
| Joshue O'Connor | I object to this approach as it creates confusion/dissonance. More so, if the validator flags a warning but cannot suggest a suitable alternative. |
| Denis Boudreau | I strongly object to a validator warning when the presence of a @longdesc is detected. Providing an accessibility feature in an HTML document should never be considered reprehensible. If it is written correctly and points to the URI of the description then it should be treated as perfectly conforming. |
| Ojan Vafai | I object to this proposal for the same reasons as making it fully conforming. Giving it a validator warning really does little in the real world to change what web developers do. |
| Monika Trebo | This makes no sense to me. Either an attribute is conforming -- in this case it would be rather strange to warn a developer that she is using a conforming attribute, or it is non-conforming -- in which case a warning is justified. |
| Benjamin Hawkes-Lewis | I object to this proposal for essentially the same reason (discouragement of native features in favour of ARIA dependence) as I object to "the Change Proposal to keep longdesc non-conforming". |
More details on responses
- Chaals Nevile: last responded on 24, June 2010 at 22:14 (UTC)
- Leif Halvard Silli: last responded on 25, June 2010 at 22:45 (UTC)
- Michael Puls II: last responded on 26, June 2010 at 21:20 (UTC)
- Tantek Çelik: last responded on 27, June 2010 at 01:06 (UTC)
- Debi Orton: last responded on 27, June 2010 at 14:47 (UTC)
- Theresa O'Connor: last responded on 27, June 2010 at 19:39 (UTC)
- Ben Boyle: last responded on 28, June 2010 at 14:14 (UTC)
- Henri Sivonen: last responded on 28, June 2010 at 14:15 (UTC)
- Tab Atkins Jr.: last responded on 28, June 2010 at 17:30 (UTC)
- Jonas Sicking: last responded on 28, June 2010 at 17:33 (UTC)
- Aryeh Gregor: last responded on 28, June 2010 at 21:04 (UTC)
- John Foliot: last responded on 29, June 2010 at 18:12 (UTC)
- David Singer: last responded on 29, June 2010 at 22:48 (UTC)
- Sam Johnston: last responded on 30, June 2010 at 10:45 (UTC)
- Laura Carlson: last responded on 30, June 2010 at 13:39 (UTC)
- Jens Oliver Meiert: last responded on 30, June 2010 at 15:48 (UTC)
- Gez Lemon: last responded on 30, June 2010 at 16:16 (UTC)
- Andrew Wilson: last responded on 30, June 2010 at 17:34 (UTC)
- Lachlan Hunt: last responded on 30, June 2010 at 23:01 (UTC)
- Joshue O'Connor: last responded on 2, July 2010 at 13:27 (UTC)
- Denis Boudreau: last responded on 2, July 2010 at 13:55 (UTC)
- Ojan Vafai: last responded on 3, July 2010 at 00:11 (UTC)
- Monika Trebo: last responded on 3, July 2010 at 03:50 (UTC)
- Benjamin Hawkes-Lewis: last responded on 15, July 2010 at 08:17 (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