- From: <bugzilla@jessica.w3.org>
- Date: Wed, 10 Aug 2011 01:50:51 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13651 --- Comment #12 from John Foliot <jfoliot@stanford.edu> 2011-08-10 01:50:49 UTC --- (In reply to comment #11) > > 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. 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? Perhaps you have evidence that supports that contrary opinion? Please do share. > > > 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. 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. The @alt attribute is not for verbose descriptions, it is for textual alternatives to images, a fact reinforced by the fact that we have other methods and means for providing longer descriptions of images (such as aria-describedby, <details> and <summary> and @longdesc): "It is important to understand that a text alternative provided in the alt attribute is a replacement for the image, while a short text alternative in the alt attribute, accompanied by a programmatically associated longer text alternative, can be a description of the image..." http://dev.w3.org/html5/alt-techniques/#sec2 Spending any time at all with WCAG 2 Success Criteria will confirm that in numerous instances there is an articulated need for short alternatives as well as long text descriptions (but as well that they are functionally different): http://www.w3.org/TR/2010/NOTE-UNDERSTANDING-WCAG20-20101014/text-equiv-all.html http://www.w3.org/TR/WCAG20-HTML-TECHS/G95.html http://www.w3.org/TR/WCAG20-HTML-TECHS/G94.html http://www.w3.org/TR/WCAG20-HTML-TECHS/G74.html > > > > 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. 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. If you are in disagreement with this methodology, then I look forward to your alternative recommendation on how to affect such change. > > 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. I'm afraid you have this backwards. The Draft Specification seeks to make changes to an existing requirement for the @alt attribute, in the process breaking backward compatibility. Thus the onus is on the change proponents to prove that this change does 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 > > > 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. > > 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) > 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? > > Janina's examples suggest that user agents could generate decent titles for > images in <figure> based on the first sentence of their <figcaption>. It would be extremely helpful if you could demonstrate that you understand the difference between alternative text for images, image titles, summaries and descriptions, as in fact they are all quite different. > 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. That is a summary of the page, it is not a functional alternative to that page. > * JAWS reads the first sentence of each paragraph to provide a summary of a > document. Again, a summary of the paragraph/page, and not an alternative of that page. As well, in both instances they are summations of existing text, and not functional alternatives to images, so you are comparing potatoes to oranges. > > 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. Once again, do you even understand what the problem here is? > > 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: "WCAG 2.0 success criteria are written as testable statements that are not technology-specific." http://www.w3.org/TR/WCAG20/ "The HTML5 specification will not be considered finished before there are at least two complete implementations of the specification. A test suite will be used to measure completeness of the implementations. This approach differs from previous versions of HTML, where the final specification would typically be approved by a committee before being actually implemented. The goal of this change is to ensure that the specification is implementable, and usable by authors once it is finished." http://dev.w3.org/html5/html4-differences/#development-model If you have an alternative suggestion on how to make this testable please speak up. > 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 Except you snipped off the next section: "Testing and testable in the context refer to functional testing, that is verifying that the content functions as expected, or in this case, that it satisfies the Success Criteria. Although content may satisfy all Success Criteria, the content may not always be usable by people with a wide variety of disabilities. Therefore, usability testing is recommended, in addition to the required functional testing." 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. While an actual word count might seem arbitrary to you, we none-the-less have the following functional requirement: - Images require SHORT text alternatives. 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. Rejecting that there is a need here however is not acceptable. -- 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 Wednesday, 10 August 2011 01:50:53 UTC