- From: <bugzilla@jessica.w3.org>
- Date: Sat, 13 Aug 2011 10:26:50 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13651 --- Comment #13 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-13 10:26:48 UTC --- (In reply to comment #12) > So it is your counter-opinion then that alternative text in excess of 50 words > is not harmful, is not a poor user-experience for screen reader users, and > satisfies the needs of non-sighted users appropriately? Concision in all text is better. > Perhaps you have evidence that supports that contrary opinion? A claim that 50 words is good and 51 words is bad would be nonsensical, since words are not equal. Some words convey more information than other words. Some languages need fewer words to convey the same information, because they combine words to make new words or use inflection in place of parts of speech. Some words have more syllables than other words, so users will have to listen longer. Some words have more characters than other words, so users will have to braille longer. You cannot draw strong correlations between the information conveyed by a word, its number of syllables, and its number of characters. So word count is not a reliable limit on information density, listening time, or braille time, all of which one would aim to minimize for a short text alternative. Previous literature, included that cited by the bug report, makes a wide variety of recommendations about @alt text length, few of them consistent with a 50 word threshold: * http://www.cs.tut.fi/~jkorpela/html/alt.html (50 characters, based on @alt display problems) * http://www.washington.edu/accessit/print.html?ID=1257 (125 characters, based on a bug in JAWS 6) * http://joeclark.org/book/sashay/serialization/Chapter06.html (1,024 characters, based on @alt display problems) * http://www.w3.org/WAI/GL/WCAG20/tests/test3.html (100 words, or higher if the human checker judges it appropriate) * http://itl.uconn.edu/idd/wai/html/multimedia.html (50 words) * http://www.accessibletech.org/access_articles/webinfo/altAttribute.php (151 characters, primarily based on @alt display problems) * http://www.ok.gov/abletech/IT_Accessibility/webtips.html (around 100 characters) * http://www.w3.org/TR/html-alt-techniques/#m5 (75-100 characters or 1-2 sentences) * http://lists.w3.org/Archives/Public/public-html-a11y/2011Aug/0011.html (250 or 300 characters) In the absence of positive evidence otherwise, we can see that 50 words is an arbitrary choice not a magic metric that divides helpful from harmful text alternatives. > > there's a wide chasm between a bug reporter understanding a user > > perspective and us actually solving users' problems, especially when we have > > such extremely limited influence over the system with which the user has > > problems. > > First, this is not a "system" issue, this is an authoring and conformance > issue: regardless of which browser or screen reading technology you may be > using, a textual alternative for an image should be "brief" and succinct. By "system" I did not mean the user's individual hardware and software setup, but rather the ecosystem that constitutes the Web, the people who consume and produce content on the Web, the tools they use to do so, and the people that develop those tools. > > Restrictions on authors (especially those requiring them to do additional work) > > should be proven to be truly necessary and plausibly effective. > > Conformance reports of success or failure (a method of positive and negative > reinforcement) can have highly effective results - it is in fact the root of > most education curriculum (Pass or Fail) and behavior modification. > http://en.wikipedia.org/wiki/Behavior_modification > > It is in fact this very behavior and methodology that the HTML5 spec is seeking > to use when it obsoletes existing elements > (http://www.w3.org/TR/html5/obsolete.html) - by making "bad" author behavior > trigger a conformance error, the spec seeks to modify such author behavior. Author conformance requirements are primarily intended to help authors use markup that does what they want it to, not as some sort of ,control mechanism: http://dev.w3.org/html5/spec/introduction.html#conformance-requirements-for-authors > The Draft Specification seeks to make changes to an existing requirement for > the @alt attribute, in the process breaking backward compatibility. A 50 word limit on <figcaption> would not fix backwards compatibility of new content with old user agents. > Thus the onus is on the change proponents to prove that this change does not cause > 'harm'. The HTML WG process does not require the existing draft to prove its differences from HTML4 do not cause harm. > We have had a decade of user experience that has suggested and supports the > fact that non-sighted users want and need (when appropriate) both short and > longer textual content with regard to images, and the WebAIM survey of 2009 > suggests that fewer than 15% or respondents wanted a verbose (long) textual alt > for images. > http://webaim.org/projects/screenreadersurvey2/#images Is this the "demonstrations" by a "host of affected users" you were referring to? Although questionable, this suggestive evidence would still have strengthened the original bug report. It's a shame it was not provided up front. > > > Suggesting that perhaps someday some screen reader might afford the end user > > > the opportunity to undo bad authoring practice is Utopian at best and fosters > > > the creation of problematic content today. > > > > Requiring authors to generate more metacrap should be our last resort, not our > > first: > > I find referring to text alternative to images that non-sighted users cannot > see as "meta-crap" highly offensive and insensitive. If you have such little > regard for the real needs of real users that you can cavalierly dismiss this > need as "meta-crap" then frankly you don't have any real understanding of the > issue and continued debate here is likely pointless. You misunderstand the link. When they're accurate, hidden text alternatives and other metadata are a good thing. Requiring people to add metadata guarantees you will get some bad metadata (metacrap). Where data is really needed, a solution is to make machines generate data - where possible. Sometimes it's inevitable that we need people to add metadata. We should try and work out if this is one of those situations or not. It looks to me like it might be a situation where we can at least let machines generate the data some of the time, so we should investigate that possibility before trying to solve it by making more work for authors through a conformance requirement. That approach that will fail a lot of the time, and thus fail to address the systemic problem. For example, @alt is missing on only two out of ten <img> elements, despite being required by HTML4. (Never mind that many @alt values are entirely incorrect.) http://dev.opera.com/articles/view/mama-images-elements-and-formats/#img > > I'd restate the problem raised by this bug as follows: users can discover, > > find, or retrieve relevant content (e.g. by reviewing a document, or reviewing > > a list, or by skipping from graphic to graphic) more conveniently if short > > titles label images rather than longer text, even if that text serves an > > equivalent purpose to the image or provides additional information. > > It is at the point where it is providing that "additional information" that > authors can inadvertently introduce negative user-experiences. Once again, this > comes down to understanding the difference between a functional alternative and > a detailed description of an image (but then, for someone who considers this > all meta-crap, I'm not too surprised you don't get it) "Functional alternative" is not WCAG terminology, but assuming by this you mean text that serves an equivalent purpose (which is WCAG terminology), then such text may be longer than 50 words. The Understanding document for the equivalent purpose success criterion, while merely advisory, is quite explicit here when it says "If a short description can not serve the same purpose and present the same information as the non-text content (e.g., a chart or diagram)". http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html If, in such a case, a short text alternative *itself* was considered to serve an equivalent purpose, then authors could meet the success criterion by providing a short text alternative and the effect of the criterion wouldn't match its intent "to make information conveyed by non-text content accessible through the use of a text alternative". This was in fact the case with HTML4 conformance where @alt was required but text that served an equivalent purpose was not. (That HTML5 does require that there be available text that conveys the same information as images, in accordance with that intent, is a virtue of the current draft, even if the ways it proposes this text be made available are controversial.) > > How can > > user agents present a short title for images when <figcaption> isn't one and no > > alternative mechanism for labelling the image has been used? (Have I missed > > anything?) > > Except that it is not a "How" question any longer, it's an "if" statement: "If" > text inside of <figcaption> is too verbose to act as a functional replacement > for @alt (and it has been conceded that in many instances figcaption can be a > functional replacement), then it should be considered non-conformant unless > @alt text is also provided. The question is not if figcaption can be a possible > stand-in for @alt, but rather when does it cease to be so? I'm describing an end-user problem, not some point of conformance that it is hoped will indirectly address that problem. If we avoid conflating problems and solutions, we stand a better chance of picking an optimal solution. > As well, in both instances they are summations of existing text, and not > functional alternatives to images, so you are comparing potatoes to oranges. Adding a 50-word limit on <figcaption> before requiring an @alt doesn't do anything to ensure images have text that serves an equivalent purpose. The point of this bug is to provide a short text alternative not text serving an equivalent purpose. Given that we have mechanisms to extract the first sentence from text, it seems a machine can easily provide some short text given a long <figcaption> and authors have the tools to override such machine-provided text. Such text is liable to be a figure title in both cases, since otherwise it would not work as a good label when the document is being navigated non-linearly - which is the only purpose of the short text in this case. (Since users consuming the document linearly will have already heard the whole <figcaption>, an additional @alt that duplicates information in the <figcaption> will be a brief annoyance.) > > How is suggesting that such techniques could be expanded to captions more > > "Utopian" than (say) suggesting popular browsers could expose @longdesc via a > > button on their main toolbar? > > Because we are talking about authored content, not user interaction or browser > behavior. Some user needs can be met by user agents without additional authorial effort. Maybe this is one of them. So I still don't understand your notion that this is Utopian. > > > If you don't like 50, provide another number. 60? 80? 250? 8,439? For > > > conformance checking, what is the number that you would propose to page > > > authors? And why? > > > > Neither HTML nor WCAG2 Recommendations constrain labels for UI components or > > content sections with arbitrary word counts. > > Both HTML and WCAG require "testable" conformance: > Currently in HTML 4/XHTML1 we have a requirement that all images have @alt, and > that @alt be either empty (alt="" silences screen readers, and is functionally > equivalent to aria-role="presentation") or contain a text string. Those are > testable criteria that validators and other testing tools can apply, whilst > having your human being verify that the text alternative is *appropriate* is > also required for true accessibility. > > This is not any different. Machine-testable is only a subset of "testable". We do not need to adopt bad machine-testable conformance criteria in lieu of better human-testable conformance criteria. > Once again, if you have a better proposal on how to ensure a testable criteria > that ensures that figcaption as a REPLACEMENT FOR (and not supplementary to) > @alt is not too verbose can be constructed, please do speak up. _If_ it's agreed that end-users need short text alternatives (a requirement that is *additional* to WCAG2), then we can require that if the image has a programmatically associated text alternative and the first sentence of that alternative would not be suitable as a short text alternative, the author must use a mechanism to supply a short text alternative. Conformance checkers to present images with their short text alternative and long text alternative, allowing humans to test the text alternatives are appropriate. A test suite for the accessibility API mapping suggestions might verify that the short text alternative (whether implied or explicit) is exposed as accName or an equivalent feature in another language. It would be a good idea for the mapping document to specify how to extract a first sentence to promote interoperability. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Saturday, 13 August 2011 10:26:52 UTC