- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 17 Aug 2009 10:11:34 +0300
- To: HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
On Aug 17, 2009, at 00:11, Leif Halvard Silli wrote: > I agree that it should not insert role="presentation" by default. > However, since we both agree with Consensus in that <img> without > @role defaults to role="img", it could insert role="img". What problem would this solve? > Tools do not need to ask "Do you want to insert an <img>?" They > could offer choice between IMG@role=presentation and normal IMG. > Tools should not bug users about lack of alternative text unless the > <img> has a non-presentational role ... What kind of markup and UI do you envision for the case where in a future HTML5-compliant version of Dreamweaver, the user creates a new document (File: New), drags an image file to the document from the Finder and saves the document? > We should treat lack of @alt and empty alt="" as semantically > identical. That's not how existing client software behaves. Previously, it has been stated on the list that it takes a long time to upgrade the software. > The Consensus Documents goes in that direction when it states that > it doesn't mater if an <IMG> with role="presentation" has an empty > alt="" or no alt at all. But it goes slightly in the opposite > direction when it recommends that validators should say that an > <IMG> with an empty alt="" but not @role should automatically get a > role="presentation". My biggest concern with the proposed normative warning is that role=presentation wouldn't be the path of least resistance for dismissing the warning. Putting a space in the value of alt would be. On Aug 17, 2009, at 02:25, Maciej Stachowiak wrote: > If you're saying that authoring tools should produce missing (not > empty) alt, without any of the alternatives suggested by HTML5 such > as @title or <legend>, and that this should be conforming, then I > believe you disagree with the current state of the HTML5 spec. Yes. I pointed out in my previous email that I disagree with the current state of the HTML 5 spec. (I believe Hixie knew this, but for all-round productivity reasons I didn't make a big deal about it on this mailing list while the alt discussion was otherwise dormant.) The reason I disagree with it is that I haven't seen a credible expectation of how a Dreamweaver-like product should implement the requirements of HTML5 as drafted without failing to conform to ATAG 2 as drafted (or vice versa). Anyway, I think discussing what should be conforming before coming to consensus on desirable authoring tool behavior will rathole this thread. Therefore, instead of discussing my conclusions, I'd like to state my premises and invite anyone who disagrees with any of my premises to come forward. If it turns out that one of my premises is wrong, my conclusion is most likely wrong. Here are my premises: * "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.) * "After the end of an authoring session, the authoring tool does not attempt to repair alternative content for non-text content using text content that is equally available to user agents (e.g., the filename is not used)." (Quoted from ATAG 2) * Autogenerated alt="image", alt="" and alt=" " violate the ATAG 2 language quoted in the previous point. * Autogenerated alt="photo" might be spun not to violate it but practically isn't materially different from alt="image". * Autogenerated role=presentation doesn't violate the ATAG 2 point literally but does in spirit. * An HTML authoring tool should conform to both HTML 5 and ATAG 2. * In a GUI editor, the user should be able to insert and delete images and section/figure headers/captions/legends independently of each other, because gluing them together would violate long-standing GUI behavior expectations. * Most authors don't respond to prompts in a meaningful way. (Contrast with ATAG 2 B.1.3 applicability notes.) * Dreamweaver and BlueGriffon-type products, Microsoft Word and OpenOffice.org-type products (when exporting HTML) and Flickr and Brightkite-type services are legitimate classes of services and products that are within scope for HTML 5 and ATAG 2. Does anyone disagree with any of these points? On Aug 17, 2009, at 02:45, Maciej Stachowiak wrote: > (To be specific, I think the best option in this case that would be > conforming to the current draft would be to put a title attribute on > the image, giving the best information the authoring tool has > available, even if it is a low-value description like "Photo 1 of > 15".) The "1 of 15" part should be aria-posinset=1 aria-setsize=15. For the remaining "Photo" part, see above. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 17 August 2009 07:12:18 UTC