- 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