- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 18 Aug 2009 09:21:32 +0300
- To: Jan Richards <jan.richards@utoronto.ca>
- Cc: HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
On Aug 17, 2009, at 19:46, Jan Richards wrote: > The CD (WAI CG Consensus Doc) resolution doesn't say @alt (or other > one of several listed alternatives) can't be omitted. It says the > IMG element is invalid if @alt isn't there. It is HTML5's > requirement of validity for conformance that makes this a problem. Doesn't that mean that the consensus resolution requests keeping it a problem? > In an attempt to find a way out of this problem, the CD includes the > following text: > "In order to address both the validity and human generation > concerns, we do not oppose the creation of 'autogenerated' and > 'missing' attributes where either one of these could be used to make > an image that does not have any human-generated text alternatives > valid. (Note: It is important that this marker is not included in > the alternative text string itself.)" Why is this affirmation necessary compared to @alt being absent? > When used, a "missing" signal (however this might be encoded - as > long as it is not in the @alt string) would communicate to the user > agent that the @alt value should not be trusted. What concretely is this envisioned to mean for user agent behavior? >>>> * "Authoring tools and markup generators must generate conforming >>>> documents." ("Authoring tools are exempt from the strict >>>> requirements of using elements only for their specified >>>> purpose, but only to the extent that authoring tools are not yet >>>> able to determine author intent." "In terms of conformance >>>> checking, an editor is therefore required to output documents >>>> that conform to the same extent that a conformance checker will >>>> verify.") (Quoted from HTML 5.) >>> >>> There's a problem here. Authoring tools often can't determine >>> author intent in @alt usage, so the exemption from the first >>> sentence would seem to apply. On the other hand, the second >>> sentence seems to say @alt is required for conformance to the >>> extent that it can automatically checked for (i.e., whether it >>> exists or not, rather than whether it has correctly recorded >>> author intent). >> Do you mean validators shouldn't flag the absence of @alt as an >> error, because the question whether alt should be present or not >> falls outside the realm of machine-checkable conformance criteria? >> I support making this interpretation explicit in HTML 5 and ATAG 2. >> At present, the language about @alt in the HTML 5 draft doesn't >> seem to provide for this interpretation, since the spec require at >> least one of several syntaxes to be present in every one of the >> exhaustively enumerated cases of possible author intent. The WAI CG >> consensus resolution didn't support this interpretation, either, as >> far as I can tell. > > Perhaps lack of @alt could still triggers some type of validity > warning, but the HTML5 conformance guidance to authoring tools > (which already talks about determining author intent) could state > that authoring tool output can still conform with these warnings if > the authoring tool was unable to determine author intent vis a vis > the value to use for alternative equivalents - if and only if the > authoring tool provided the author with the ability to demonstrate > their intent (e.g., by filling out the proper fields). > 3. it would then be left to ATAG 2.0 (still draft) to set > requirements for how authoring tools can do a good job at collecting > these alternative equivalents. The crux of my feedback on the CD is this: If the WAI requests that HTML 5 validators *by default* emit messages flagging pieces of markup in the output of an authoring tool when the authoring tool conforms to ATAG 2, authoring tool vendors will be faces with an either-or choice: conforming to ATAG 2 or getting a seemingly "clean" report from validators. Whenever authoring tool developers opt for the seemingly "clean" report, the WAI will have failed to fully meet the objectives that motivate ATAG 2 (in the scope of that authoring tool). Thus, the WAI will have better chances of getting ATAG 2 implemented widely and meeting the objectives that motivate ATAG 2 if authoring tool developers can both conform to ATAG 2 and get a seemingly clean validation report by default. As a validator developer, I would prefer not to undermine ATAG 2 by putting in default messages that will lead to authoring tool developers having to make that choice, since some developers will opt for the seemingly "clean" report over ATAG 2 compliance. (Validator.nu already has an optional Image Report feature that goes above and beyond what is requested in the CD.) > 4. and it would be left to WCAG 2.0 (W3C Recommendation) to > determine the accessibility level of a particular final piece of > content, regardless of the tool used and the author's circumstances. OK. >>>> * Autogenerated alt="image", alt="" and alt=" " violate the ATAG >>>> 2 language quoted in the previous point. >>> >>> Actually, alt="" would be fine to autogenerate if the authoring >>> tool could detect that the image was presentational (e.g., it was >>> a 1x1 white JPG with no link) >> I agree. I meant in the general case. (However, one might argue >> that the 1x1 case isn't important, since the client side could >> filter it just as easily.) > > Right, but that's perhaps the simplest case. That's why ATAG 2.0 B. > 2.4.3 (Let user agents repair) only applies to repairs using text > content that the user agent (and by extension the end user) as equal > access to. Repairs using image processing are always allowed. It's not obvious to a reader who hasn't been involved in ATAG 2 drafting that repairs using image processing are always meant to be allowed. I suggest noting this explicitly. >>>> * Most authors don't respond to prompts in a meaningful way. >>>> (Contrast with ATAG 2 B.1.3 applicability notes.) >>> >>> I won't disagree with the statement. But the "contrast" is >>> incorrect. The ATAG 2.0 use of the word "assume" should be read as >>> "ONLY WHEN" >>> "This guideline applies to the automated behavior specified by the >>> authoring tool developer [under the assumption that authors will/ >>> ONLY WHEN AUTHORS] respond properly to any prompts." >>> (http://www.w3.org/TR/2009/WD-ATAG20-20090521/) >> OK. I misunderstood what ATAG 2 meant. I suggest rewording the >> sentence using words "only when". > > Agreed. I will propose that change in ATAG 2.0. Thanks! -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 18 August 2009 06:22:20 UTC