- From: <bugzilla@jessica.w3.org>
- Date: Sun, 07 Aug 2011 20:47:20 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13651 --- Comment #11 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 2011-08-07 20:47:20 UTC --- (In reply to comment #10) > When it comes to understanding the requirements of users > with disabilities, many feel that the editor has an extremely poor track-record > of understanding and delivering acceptable solutions. So? We wouldn't want editors to prohibit accessibility techniques or drop accessibility features based on unsubstantiated performance problems because they don't know much about performance. > With regard to this bug, the research and evidence was done and presented. The bug report cites evidence that some captions are longer than 50 words, but only opines that this is harmful. > Are you going to suggest that the editor has more experience using screen > readers, and has a better understanding of that user perspective, than > someone who is clearly an experienced daily SR user? No. But 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. > > We shouldn't be trying to obtain and > > then disprove a negative proof, we should be trying to provide positive proof > > for problems up front. > > This is a conformance question, not a user agent issue and to meet a standard > of usable, accessible page content, overly verbose ALTERNATIVES to visual page > elements have negative consequences. If you or anyone else can prove this to be > wrong then please bring forth that proof. Restrictions on authors (especially those requiring them to do additional work) should be proven to be truly necessary and plausibly effective. > You might wish to argue that the number 50 is arbitrary, and that it should be > 40 or 60 - fine, bring forth that argument as well - however that line of > pursuit in no way dismisses the fact that at some point "too much" is indeed > too much: It suggests that "too much" might vary from case-to-case or user-to-user, so arbitrary limits are inappropriate. > WCAG, WAI, PF and a host of affected users have repeatedly advocated for, > requested, and demonstrated that users of Screen Readers (and not "AT", which > also encompasses solutions such as screen magnifiers, alternative switching > devices, speech to text technology, etc.) require both short *and* expanded > textual descriptions for complex images. Citations of demonstrations by the "host of affected users" that they require short and long alternatives would constitute revelant evidence. Please provide them. Descriptions of how they would be used would be especially pertinent. > 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: http://www.well.com/~doctorow/metacrap.htm 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. 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?) Janina's examples suggest that user agents could generate decent titles for images in <figure> based on the first sentence of their <figcaption>. User agents already solve similar problems this way elsewhere. For example: * Google use text from a webpage to generate a description for a webpage for presentation amidst search results. * JAWS reads the first sentence of each paragraph to provide a summary of a document. 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? In the rare case where authors provide better titles, the draft provides several features (@aria-label, <details>, and more controversially @alt and @title) that allow them to do so. This is similar to how authors can provide better descriptions for webpages using <meta name="description">. We don't need to require them to do so in every case. > Can you prove that an overly long text track does not as some point become > an onerous and unfriendly alternative to an image? By definition, "overly long text" is unfriendly to anyone. > > Where is the positive evidence that a 50-word text alternative is required but > > a 51-word text alternatives is intrinsically not "much more verbose than what > > is useful or appropriate" or "too distracting"? > > 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. Proposing a particular number as anything other than an informative guideline is silly and any number high enough not to be too arbitrary (say 500 words?) would be too high for Janina's examples. It's particularly absurd to impose length restrictions here when we don't have length restrictions on @alt itself. > > What is the rationale that such summarisation must be performed by adding text > > to "alt" rather than by using "aria-labelled" and "aria-describedby" to point > > at parts of the <figcaption>? > > While this is a good suggestion, how will conformance checkers know that this > *may* be appropriate? By consulting a human being: "All WCAG 2.0 Success Criteria are written as testable criteria for objectively determining if content satisfies them. Testing the Success Criteria would involve a combination of automated testing and human evaluation. The content should be tested by those who understand how people with different types of disabilities use the Web." http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html > Or are you now suggesting that when authors use figcaption as a replacement for > @alt that they must ALSO use one of either "aria-labelled" and/or > "aria-describedby"? No. -- 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 Sunday, 7 August 2011 20:47:27 UTC