- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Mon, 4 Feb 2008 13:04:43 -0500
- To: joshue.oconnor@cfit.ie
- Cc: wai-xtech@w3.org
** summary: You hit the nail on the head when suggested that @alt is not the only markup pattern we need. For HTML5 we need to look at how a variety of markup patterns can meet the functional requirement set out in WCAG2 that there be a textual alternate. The ARIA @labelledby attribute is one candidate. But there are also possibilities to identify the text alternate by algorithm. The SSML <audio> element has semantics that clearly make the text content of the element an alternative to the media object cited in the @src attribute. This pattern is replicated throughout XHTML2. Not to say that HTML5 is going to take up all features of XHTML2, just to say that there are multiple ways to skin a cat, and some of the plausible approaches are algorithmic. Compare with the @headers evolution discussion. The point that I was trying to make in talking about machinable stuff is that where a textual alternate is required, the association of the text and its non-text alternate needs to be clear in the markup semantics. The present draft falls short in the area of articulating what the algorithm is that links text and non-text in the cases where (a) a textual alternative is required and (b) they and we could agree that an empty @alt is OK, because of another text-content fragment that does the job. We need to know what the "alternate alternate" is when @alt is not doing the job. ** long form interleaved On 1 Feb 2008, at 5:44 AM, Joshue O Connor wrote: > > Al Gilman wrote: >> We need effective >> action across the board. > > As a suggestion, one way to do this may be to not mix issues even if > they may be related (where possible). Well, how separately one can treat related issues is an art that neither W3C nor WAI have mastered to any high degree, .. One of my FAQs is that "The people with the answers see the world through a more fine-grained reticle (system of sorting categories) than do the people with the questions." So ultimately we need to see how the questions get answered both in the large and in the small. > Re: > Conformance/error-checking/accessibility. > >> There are several other cases where the instructions in the HTML5 >> draft >> are that the @alt should be empty. These are similar to putting a >> null >> @alt on an image in an image link when the link @title is desired >> to be >> spoken. > > In the wild @title content is rarely outputted by screen readers. I must have the example wrong. I was trying to say that there is an existence proof where the accessibility techniques recommend @alt="" beyond the case of spacers and the like. Could it be in link content where the text content already in the link is right, without anything added for the icon? > >> I think that these cases need to be identified by machine-applicable >> selectors before the "no @alt" instruction can be acceptable. > > <Thinking out loud> Is there a need to successfully deal with @ALT > content for human users and then @ALT that is machine readable. Is > this > correct? If so, can the same attribute satisfy both these > requirements? > Or is there a need for @ALT x 2 or @ALT plus machine selector? How > would > this be generated, via some option in the authoring tool? Would the > machine readable selector satisfy the requirements for situations > where > there is no@ALT ? You are right there are different requirements in the different use cases. And my current thinking is that @alt doesn't meet all the requirements and would be awkward to try to stretch that attribute to meet them all. For example in HTML+ARIA we have @labelledby that lets us point by ID to something that can contain markup. Better for i18n, better in general than @alt that only can contain a text string, no markup. In the case of the link text, there is a fairly simple rule: The text content of the <a> element is well defined by the syntax. If this is the explanation you need the link content to provide for access, then it's OK if an icon marking the link hides from the text view, and doesn't add anything. This is a pattern that an accessibility checker or author prompting algorithm can readily apply. Note that this doesn't have to be the final answer for HTML5. WCAG2 allows link identification from the link element content to be "unique, given the context." Defining an algorithm for what text in the context of a link should be considered part of the orientation to the link destination -- if HTML5 wants to take that approach, we need to consider it. What I want is those case-diagnostic patterns spelled out, not just heuristic prose. Where the @alt is to be left empty by rule because there is peer content that is the text alternative, how does the AT find the text alternative that is there? There should be a way. That's what should be machinable. >> In other cases, where an image amplifies some text also in the page, >> the relationship of the image to the text must be machine >> recognizable. >> People with reading difficulties need the association to be machine- >> recognizable because they may be critically dependent on the image to >> grok the words. > > When you say "amplify" do you mean that the image is complementary > or is > used as an to aid comprehension? If so, then yes. > If not then I would argue that in many cases the relationship > really does not need to be > explicit for human consumption. What is "explicit for human consumption" is a presentation decision subject to "author proposes, user disposes." It is not available to the format from the author as settled fact. The point is that if the association is *useful* as an aid there are *some people* for whom the association is critical. Giving the author some slack, we will assume that meeting those people's needs may require some AT on the client side. But the association should be *explicit at the format (=machine) level so that it can be made overt to those users who *need* it as opposed to the rest of the users for whom it is a "nice to have." > The way images are used is often quite > arbitrary, even if they are used to aid comprehension and while an > image > can speak a thousand words and so on, a few well chosen words often > will > suffice. People think they stuff media objects in for no reason. It's just that it's harder to articulate the reason than it is to decide to do it. [historical flame on this point: http://lists.w3.org/Archives/Public/wai-tech-comments/2001Aug/ 0001.html ] > FWIW I would also suggest that the semantic relationship between an > image that "amplifies" text is different from what @ALT does. Yes, @alt doesn't meet all requirements. Nor should we try to make it. > Maybe > there is a need for an attribute that more explicitly states that > semantic difference? Rather like @ADD (for additional, or addendum) or > @SUPP ( for supplementary), etc. So far in WAI-ARIA we are sticking with @labelledby and @describedby which are roughly parallel to @alt and @longdesc but more broadly applicable. Getting into subtler distinctions by trying to apply SKOS to show the gradations in meaning-relationship turned into a non-terminating process. > >> Given the low level of strict conformance to W3C format >> specifications >> in the Web as she is spoke today, it is not clear how much of a prize >> it is to insist that a missing @alt in this case is a format error >> vs. just being an accessibility error (which it will be anyway). > > There seems to be two issues here. .. and they are? The goal is a Web populated with content PWD can use. At that level there is one issue. In terms of who does what where to make this happen, there are more than two options. Here there is only one issue. The HTML5 draft agrees already that critical content *should* have a text alternative. The problem is that the language in the draft is so vague. The alarmist interpretation would be that they want to overrule WCAG. I don't think so. It could also be taken to mean "although this is wrong, this is a defect that browsers will have to tolerate." >> We should regard the HTML WG desire to standardize recovery from >> defects >> as a positive step. Something that we should applaud and work with. >> >> Clearly, the absense of an @alt in the narrow case described above >> should not be cause for the browser to reject the whole document, as >> is the uncomfortable rule with many XML errors. > > Absolutely. Thanks. aside: I have an un-finished guideline about "me too" messages. I think it helps to have a second voice on record in agreement. Too many can get just contribute to inbox glut. But it's hard to articulate a netiquette principle that will get followed in the wild. Al > Cheers > > Josh > > > >
Received on Monday, 4 February 2008 18:19:21 UTC