- From: Ramón Corominas <rcorominas@technosite.es>
- Date: Thu, 28 Nov 2013 13:59:59 +0100
- CC: WCAG WG <w3c-wai-gl@w3.org>
Hi again. What I find difficult to understand is this apparently high interest in reviewing the specific failure that makes reference to the most basic and well-known accessibility feature. Yes, there may be other ways to provide the information that also work under certain controlled circumstances. But why this interest in putting images without @alt? Those that know about @aria-label will for sure know @alt, so why add confusion telling the world that @alt is not important? In fact, most failures may be reviewed with this critical perspective to find "failures in the failures". For example, I have re-read just some of the first...: F3: Failure of SC 1.1.1 due to using CSS to include images that convey important information It depends on the platform/browser. Background images don't disappear on Mac (no high-contrast mode), and there are many ways to provide alternatives that can be read by screen readers and have accessibility support on all platforms. Even on Windows we could use some kind of trick to detect high-contrast mode and provide alternatives for low-vision users. Therefore, this is not always a failure and should be removed. F4: Failure of SC 2.2.2 due to using text-decoration:blink without a mechanism to stop it in less than five seconds AND F7: Failure of SC 2.2.2 due to an object or applet, such as Java or Flash, that has blinking content without a mechanism to pause the content that blinks for more than five seconds They should at least be rewritten to avoid the words "stop" or "pause", or better to include also the possiibility of hidding the offending content, since it could conform if there is a mechanism to hide it, or if the content simply disappears before 5 seconds (a blinking warning, for example). That said, text-decoration: blink should die! F9: Failure of SC 3.2.5 due to changing the context when the user removes focus from a form element The content could conform if a mechanism is available to turn off the change of context. F13: Failure of SC 1.1.1 and 1.4.1 due to having a text alternative that does not include information that is conveyed by color differences in the image It needs at least a re-wording to ensure applicability. With the current wording the content could meet SC 1.4.1 if the graphic uses other means to convey the information (for example, including also numbers with percentages in addition to colours), and it could also meet SC 1.1.1 if the image fits in one of the exceptions (text, sensory...). It is also curious that this failure seems to target colour blindness, but if we consider that text alternatives could be provided by @aria-label the content would still be inaccessible to colour-blind people. Yes, it as a failure and not a "reversed" sufficient technique, but it is curious. The above are just a few examples of how we could re-read failures to find inconsistencies or exceptions. In my opinion, it is not the intention of the failures to be absolutely precise, but to provide guidance to people who are not accessibility experts. Developers that have a strong knowledge of accessibility specs and a deep understanding of accessibility barries will likely use @alt to provide alternatives. I cannot imagine a developer that understands @aria-label but is not aware of @alt, nor I can imagine a developer that knows @aria-level using <p aria-level="1"> instead of a real <h1>. And, if for some reason it is critical for them to use @aria-label and NOT to use @alt, this developers that have accessibility skills will do it anyway regardless of F65, firstly because they will know that failures are non-normative, and secondly because they know that they are still meeting the accessibility criteria. Cheers, Ramón. Stefan wrote: > In my opinion, (to say it again) successful and comprehensive mapping to > a given platform accessibility API based on clear and transparent rules > is the key, no matter what Assistive Technology does with it afterwards. > Given that, (platform-dependent) automatic testing of APIs (not only > markup) can exclude the effect of current AT implementations (as “prove > of concept” that support works) and serve as a solid base. > > > > “Successful” means, for instance, that e.g. in the windows MSAA world > both accessible Name and accessible Description for images can be > obtained by using the appropriate host language AND ARIA metadata > attributes. Yes there are possible contradictions, clashes etc. and > therefore necessary precedence rules to be taken into account to yield a > successful and reasonable mapping, but it is not a “black or white” > discussion. > > > > In this sense, > > > > <img src="../images/giraffe.jpg" aria-labelledby="123"/> > > <p id="123"> Giraffe grazing on tree branches</p> > > > > serves as a perfect replacement for **alt** since both will be mapped to > the same accessible Name property by the user agent. In addition, > visible text is associated in a meaningful and reasonable way with the > image. > > > > Furthermore, it needs to be decided FINALLY on an API level what has to > have precedence: accessible Name or accessible Description. If the > former, then > > > > <img src="../images/giraffe.jpg" title="Giraffe grazing on tree branches"/> > > > > would violate this (no *alt* and therefore no accessible Name mapping). > If there is no precedence, then example is fine. It can be that such > decisions have been already made. *If so, they have not hit the > developers mind* since I often hear from “rebel-minded” developers that > giving a title is perfect enough. I know that this is wrong regarding > the neglected status of the **alt** attribute but I cannot say that they > are completely wrong since they DID something for accessibility. So > following the idea of James Craig, yes, a markup rule validation but not > an accessibility validation. Same holds true for the aria-label usage in > these cases. > > > > The most important task is to extract the use cases where both host > language AND ARIA metadata attributes work together in a supplementary > standard-conformant and meaningful way and recommend them. This includes > also usage examples of e.g. **aria-label** in all cases where no **alt** > attribute is defined for the element. Of course this task should include > bad usage examples, too. I see efforts addressing exactly this already > underway (e.g. for labelling of landmarks, which is a good example). > > > > Finally, I don’t understand why screen readers still do not make full > usage of ARIA attributes in all their modes (Virtual or not). I also > cannot comprehend that these tools do not follow a minimum common rule > set how to pick up an concatenate the API and DOM info on a given platform. > > > > In my opinion, they should serve people’s needs by extracting (as > configurable default) as much info as possible from a given context. > > > > Example discussions for contradicting content like for > > > > <img src="../images/giraffe.jpg" alt="Giraffe grazing on tree branches" > aria-label=”A nice giraffe”/> > > > > would be obsolete if there would be a requirement in a W3C spec for > screen readers to gather ALL info no matter which mode they are and not > rely on API mapping alone (which would be “Giraffe grazing on tree > branches” according to alt precedence mapping rules). This is no big > issue for them since they already always query the DOM nodes in > parallel. Personalization of speech output must refine the behavior > here, but the default should be really “include all info provided for > this particular context”. > > > > - Stefan > > > > > > > > *From:* Michael Cooper [mailto:cooper@w3.org] > *Sent:* Mittwoch, 27. November 2013 21:03 > *To:* David MacDonald; 'Janina Sajka'; 'HTML Accessibility Task Force'; > WCAG WG; public-comments-wcag20@w3.org > *Cc:* 'Gregg Vanderheiden'; kirsten@can-adapt.com > *Subject:* Clarification of WCAG intent and meaning of techniques [Re: > WCAG considering amending F65 to NOT fail missing ALT text if title or > aria-label is present] > > > > I thought it would be helpful to clarify what the WCAG Working Group is > considering and its reasons for asking the question that started this > thread. > > To recap background on the structure of WCAG 2.0 and its supporting > materials: The Web Content Accessibility Guidelines 2.0 defines > normative requirements for accessible content. This means that an author > wishing to claim conformance to WCAG 2.0 must ensure their content meets > the Success Criteria. The WCAG 2.0 Success Criteria are abstract, > though, so they are supported by informative resources including the > WCAG 2.0 Techniques. Informative resources provide interpretive guidance > from the WCAG Working Group, and Techniques suggest how the Success > Criteria might be met in particular technologies. But these are only > informative suggestions, and it is possible to meet or fail to meet the > Success Criteria without matching the patterns suggested in the techniques. > > The same is true of Failure Techniques. These describe authoring > practices that might cause a page to fail the Success Criteria. But > these, too, are informative, and it is possible to fail the Success > Criteria in other ways, or to use patterns that match a failure > technique but do not in fact cause the page to fail because another > technique was used that caused the page to pass. In fact, as time > passes, the Working Group has become more and more concerned that some > of the failure techniques no longer describe situations that always > fail, due to changes in technology. The group is now trying to identify > and update some of these techniques. > > This brings me to the technique at question in this thread, "F65: > Failure of Success Criterion 1.1.1 due to omitting the alt > attribute...". This technique says it is a failure of WCAG 2.0 if the > alt attribute is omitted on certain elements, because text alternatives > would not be available. Since the time that technique was written, new > approaches to associating text alternatives have become available, for > instance aria-label and aria-labelledby among others. While there are > concerns about how widely implemented these are and if they fully > fulfill the role of alt, it seemed to the Working Group that it would be > worth updating the failure to reflect new technology, so it would not > indicate that content fails when it may not. > > There are many considerations to making a change like this. Although > failure techniques are only informative, the goal is to make them as > accurate as possible to the technologies of the time. But as we all > know, there is not consensus in the accessibility community about > whether newer technologies are an acceptable replacement for alt, for > both technical and strategic reasons. The WCAG WG did not want to make a > change to the technique that is not in line with the consensus of the > HTML Accessibility Task Force which has worked most closely within W3C > on this issue. This is the reason that the group brought the question to > this forum. > > The purpose of all this background is to clarify the intentions and > plans of the WCAG Working Group. The goal is to coordinate and make sure > the group takes an action that is accepted in the accessibility > community, rather than make one decision within the WCAG Working Group > that it knows might not be accepted by many other stakeholders. The > group wants to understand the variety of perspectives and does not > intend to make a hasty or one-sided change. It seems, though that some > update to the failure technique is needed, although it could turn out > after this exploration that the consensus is not to change the > technique. Even after the group makes a proposed change, if any, to the > technique, there will be further rounds of review - in context of a > draft of the technique at that point. And in the end, the technique is > still non-normative - other organizations are free to disagree with it > and follow other approaches to meet WCAG 2.0. > > I hope this helps people understand the intent of the message that > started this thread and what the WCAG Working Group does and does not > plan to do. > > Michael > > On 22/11/2013 6:27 PM, David MacDonald wrote: > > On behalf of the WCAG working group, I have an action item to solicit > > responses from the wider community regarding a proposed amendment to WCAG > > failure technique F65 regarding missing ALT. Currently; if an <img> element > > is missing from an ALT attribute the page fails WCAG SC 1.1.1 Level A. Some > > are proposing that we allow authors to use the aria-label, aria-labelledby, > > and title attributes INSTEAD of ALT. > > > > So under the amended failure technique NONE of the following would fail > > WCAG: > > > > <img src="../images/giraffe.jpg" title="Giraffe grazing on tree branches"/> > > > > <img src="../images/giraffe.jpg" aria-label="Giraffe grazing on tree > > branches"/> > > > > <img src="../images/giraffe.jpg" aria-labelledby="123"/> > > <p id="123"> Giraffe grazing on tree branches</p> > > > > As you can imagine there are strong opinions all around on this so I > > suggested we get a sense of what other groups such as the HTML5 A11y TF and > > PF think. > > > > Those in favour of the change provide the following rational: > > > > --These alternatives on the img element work in assistive technology > > --The aria spec says these attributes should get an accessible NAME in the > > API > > http://www.w3.org/TR/wai-aria/roles#textalternativecomputation > > --They say it's easy to teach beginner programmers to just always use an > > aria label on everything, rather than requiring a label on form fields and > > alt on images > > --They feel as a failure F65 is very strong if fails a page for missing ALT, > > especially if other things work, and they would like to soften it to allow > > other things that work. > > --html 5 allows a <figure><legend> combination instead of alt, so they feel > > WCAG will have to change F65 anyway to allow a figure with a legend, and > > that helps open the door to this discussion > > > > Those in favour of the status quo (which fails missing alt text) provide the > > following rational: > > > > --aria-label, labelledby and title, are not really suitable attributes for > > img alternative text because they implies a label or title, rather than an > > alternate text, so it is not a semantic equivalent > > --title is not well supported > > --some feel that the aria spec is not in any way suggesting these as > > replacements to ALT. > > --aria instructs authors to use native html where possible, and they could > > not come up with viable use cases of omitting alt text > > --there are hundreds of millions of dollars invested in current evaluation > > tools, and methodologies, and this would represent a major departure from > > one of the most basic accessibility convention, that is almost as old as the > > web and is the "rock star" of accessibility > > --it could cost a lot of money to change guidance to developers etc..., and > > muddy the waters on a very efficient current evaluation mechanism > > --when the figure/legend is supported by AT we can amend F65 but that is a > > different issue and the semantics of this construct are OK for text > > alternatives, rather than the label/labelledby/title options > > --it may cause some confidence problems to WCAG legislation, because it > > represents a strong loosening to a fundamental Success Criteria, an > > unnecessary change that doesn't help the cause of accessibility, but just > > complicates things > > --ALT is better supported and the text appears when images are turned off. > > --initial twitter feedback from the community is strongly against changing > > this failure > > > > > > There are probably other reasons on both sides which we hope to hear ... but > > these should start it off. Please give your opinions and reasons. > > > > Current technique here: > > http://www.w3.org/TR/WCAG-TECHS/F65.html > > Proposed failure here (see test procedure) >
Received on Thursday, 28 November 2013 13:01:12 UTC