WCAG Comments February 2014

This is an archive of past comments.
EOWG use WCAG review for new comments.

alt issue

Background:

The WCAG Working Group is still discussing appropriate ways to provide text alternatives for images -- specifically, is it OK to not provide an alt attribute and instead use ARIA attributes? We particularly request feedback on this issue and related techniques such as F65. See the examples and details at: ARIA10: Using aria-labelledby to provide a text alternative for non-text content]
WCAG list discussion and reply

Discussion

EOWG perspectives on this issues:

summary - comment {name}
Too early to replace alt by ariadescribedby - I have read most of the discussion you point to and I would like that EO argues as a comment that allowing not using alt tags and replacing it by arialabelledby is not good for outreach.
1. Developers will omit to use alt tag.
2. Validation tools have been programmed to test alt tag and that will cause to have to change them.
3. Support of ARIA is not widespread. You need as a blind user to have latest browser and screen reader versions. Moreover, ARIA is mostly for screen readers and keyboard users but not for other types of disabilities. So this may lead to criticism that WCAG 2.0 becomes again dependent on one technology and like WCAG 1 deals more with the interests of blind users but not the needs of other users with other types of disabilities. I would like to cite one of the messages reacting to this topic:
  "Are text equivalents only for screen readers? I must honestly admit that I don't know how many voice recognition applications are able to interpret and interact with ARIA attributes (or
  to which level of support). I also don't know many tools used by people with cognitive disabilities that convert text into easy-to-read or similar versions. I don't know if certain people with motor disabilities prefer to disable images and resize text because they have a bigger area to click. I don't know if people with low vision could prefer to disable
  icons because they find them difficult to see or understand, or because they are not resized when the user increases the text size."
In his clarification message, Michael Cooper explains the background of the working group questions. I understand from this explanation, that the techniques and failures are only informative. But I am afraid that people see they are not obliged to use alt attribute because there is arialabelledby and don't use it anymore. {Sylvie, 10 February}
OK with ARIA10. modify F65? - I note that ARIA10 says, "Applicability: Technologies that support Accessible Rich Internet Applications (WAI-ARIA)." I wonder if "F65: Failure of Success Criterion 1.1.1" could be changed something along the lines of: "failure... due to omitting the alt attribute on img... unless provided by aria-labelledby in situations where WAI-ARIA is accessibility supported"? (would want a shorter title probably) Not sure of pros and cons to that approach...{Shawn}
- avoid "until user agents..." - agree that we should remind people about the required pre-condition of accessibility support for *all* accessibility features (not only when using this particular attribute) but I'm concerned to that the suggested phrasing would create a temporal dependency like the famous "until user agents..." construct. also, it is until technique ARIA10 is sufficiently accessibility supported (in the particular context), as opposed to WAI-ARIA as a whole being accessibility supported (by feature rather than by technology).
- to the first point: I'm not understanding how it is different from the current accessibility support dependency, nor what the drawbacks are...
  second point taken, so it would be something like: "failure... due to omitting the alt attribute on img... unless provided by aria-labelledby in [situations|contexts] where aria-labelledby is accessibility supported" {Shawn}

I like the idea of enabling WAI-ARIA. But we have to be careful, as Sylvie says, of providing a 'novel' approach for developers to use 'fancy' solutions over tried and true methods based on HTML. As Steve Faulkner et al state in Using WAI-ARIA in HTML "If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.". Thus it is more than simply looking at 'accessibility supported' - it's also a case of KISS (Keep It Simple Stupid). If we document this type of use of WAI-ARIA, how do we stop it being used inappropriately? {Andrew}
Is there a way within the Technique to emphasize THIS point? That using native HTML techniques is the first stop and that in the case of something as basic as an image, it is in fact the preference? I tend to agree that if aria-labelledby is perceived as inter-changable with the HTML alt attribute, the latter is likely to be omitted in places where it is useful/needed. {Sharron}
aria-labelledby is not interchangeable with alt attribute - I strongly agree with Sharron's point above. {Paul, Feb 13}
Risky to drop requirement of alt tag if valid aria-labelledby is present - I can see how technically aria-labeledby provides an alternative to the alt attribute. However, because the AT support for WAI-ARIA is not universal (as I understand it) and because so much education and outreach has been conducted promoting the use of alt for images, I would be hesitant to undermine the alt attribute requirement for images. It seems aria-labeledby should be reserved for long descriptions.{Howard, 13 February, 2014}
When necessary, aria-labelledby should be SUPPLEMENTAL to the alt attribute - The note indicates that when aria-labelledby is used with an alt attribute, the values must match or validation errors will occur. It seems to me that using aria-labelledby should only be used in those special cases where it's actually required to fulfill specific functionality, and only then in addition to the alt attribute. {Paul, Feb 13}
Keep it simple - Rules with exceptions are much more difficult to follow than simple ones. This applies to web authors, authoring tools, validation and evaluation tools, as well as assistive technologies, their settings and their users. An enormous and consistent effort has gone into educating authors, that all images require alt attributes, there is a real risk that changing that rule will result in confusion and higher instances of inaccessible images. Implementing the WAI-ARIA 10 technique will require code manipulation, I don't understand what use case would permit this but not permit a change or insertion of an appropriate alt attribute. {Bim Feb 14}

EOWG Comment to Submit

Suggestions for the specific comment wording to submit -- from an education and outreach perspective:

EOWG has the following concern about WCAG-WG's consideration of allowing the use of various aria attributes to provide text alternatives for images without the provision of an HTML alt attribute. The use cases cited do not seem compelling enough balanced against the risk of misunderstanding that could lead web authors to conclude that aria-labeledby, for example, could be used interchangably with the HTML alt attribute. Widespread adoption of a "new" technique could result in a lack of critical information for a significant number of users. The examples do not make the distinction clear about where the line is to be drawn between cases where it might be or might not be Sufficient. We believe this to be misleading from an education and outreach perspective. Since alt attributes display onscreen when images are disabled and aria attributes do not, the outcomes are not equivalent. The Introduction to ARIA is unambiguous about the fact that WAI-ARIA is meant to provide accessibility features to rich content that cannot otherwise be made accessible in HTML. Therefore, EOWG strongly urges WCAG-WG to make that distinction much more clear in the presentation of this Technique or to omit it from this Draft. While aria attributes are invaluable in providing text alternatives for interactive elements that have role and state attributes as well as the name description, it should not be suggested to be the equivalent of or a substitute for a basic alt attribute. {Sharron, Feb 13}
+1{Howard, 13-February}
+1{Paul, 13-February}
big, loud +1 with minor edits - "use cases do not seem compelling enough when balanced against ...."; the "s" in "sufficient" should be lowercase in the sentence ending in "might or might not be sufficient.";{Jan, 14-February}
+1 {Eric, 14-February}
Discussion in EOWG telecon minutes 14 Feb

Techniques

---

minor editorial: In ARIA Techniques, capitalize "W3C Recommendation" in

Accessibility Support for WAI-ARIA

Using technologies in an Accessibility Supported way is required for conformance claims. Read more about Accessibility Support. The WCAG Working Group plans to review which WAI-ARIA techniques are sufficient when Accessible Rich Internet Application specifications reach W3C recommendation status. ...
{Shawn}
[done] I skimmed the changes since last version and have no other comments on them {Shawn}
[done] I looked through teh diff-marked version and saw nothing else of concern (apart from the ARIA vs HTML approach already raised) {Andrew}
[done] Sylvie reviewed

Understanding

---

[EOWG please note whether you agree with this addition or have other thoughts on it] In Understanding Techniques for WCAG Success Criteria add a new section:

<h3>Techniques for Specific Technologies
Publication of techniques for a specific technology does not imply that the technology can be used in all cases to create accessible content that meets WCAG 2.0. Developers need to be aware of the limitations of specific technologies and ensure that they provide content in a way that is accessible to all potential users.
- fyi, we've been putting this in the announcements and blogs for some time. {Shawn}
- [EOWG ?] Should we suggest that this goes right under the Techniques are Informative section? Or at the end after the Using the Techniques section? Or somewhere else? {Shawn}
- Agree - can we put it in multiple place? Otherwise I'm in favour of up-front. {Andrew}
- Discussion in EOWG telecon minutes 14 Feb
[done] No other comments {Andrew}
[done] I skimmed the changes since last version and have no other comments on them {Shawn}
[done] Sylvie reviewed