W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Re: response to counter proposal for ISSUE-31 AND ISSUE-80

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Fri, 16 Jul 2010 04:13:53 -0500
Message-ID: <AANLkTinFtwvzC6bMTbJXjmEBE9L_IryUjKoigfTgv593@mail.gmail.com>
To: Steven Faulkner <faulkner.steve@gmail.com>
Cc: HTMLWG WG <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>
Contrary to its assertion, Ian's change proposal fails to require text
alternatives for images. It fails to provide a way for automatic
validators to programmatically detect the presence or absence of short
text alternatives on the <img> element because of its exemptions.

I strongly object to it for all of the reasons that were stated in the
other change proposals, but especially because:

A). It allows content that is not perceivable to some people. This is
exacerbated by specifying the generated mechanism [1] as well as
allowing a private communication and email exceptions [2]. The blind
photographer use case is a red herring. No matter if a person is
sighted or not, if that person does not provide a text alternative for
an image the <img> element is still incomplete and inaccessible to the
end user.

As for edge cases where page producers don't know what the image is,
the solution that WAI CG said that they would not object to [3] is:
create a "missing" attribute. Creating a "missing" attribute would
address the business concern of authoring tools wanting to validate to
HTML5, even if the author does not supply a text alternative. At least
a "missing" attribute would:

* Allow an image without a text alternative to be honestly labeled for
what it is: missing, incomplete, lacking substance.
* Provide a machine checkable mechanism to locate incomplete <img> and
enable tools to quickly discern where "missing" has been so mistakes
can be fixed.
* Support ethical accountability by promoting the development of
responsible tools and by advocating an effective enabling environment.
* Has possibilities for crowdsourcing.

B). It emasculates the vaildator as learning tool and renders it
completely worthless for teaching text alternatives [4] for anything
created with an authoring tool that inserts meta name="generator".
Millions authors use these types of tools. It is a tragically missed
opportunity to educate the authors about proper usage.

C). It promotes poor authoring tools. Flickr, Photobucket, and
etcetera are examples of incorrect software implementation that do not
follow ATAG. In contrast, XStandard is a correct implementation. It
prompts the user to identify if an image is decorative or not. The
user makes the decision. If they say the image is not decorative, and
in fact actual content, they must submit a text alternative before the
image can be saved.

D). It provides text alternative advice that directly conflicts with
WAI.  Steve's document follows WCAG's guidance. Whereas Ian's document
follows his own personal accessibility rules based on his own personal
perspective of accessibility. He gets some things very wrong, like his
CAPTCHA [5] and Webcam [6] advice. Steve has correct advice in his
document based on WCAG [2] [3]. WCAG WG is chartered to set
Accessibility guidelines and HTML WG is not; so HTML5 should be
careful to supply features that support WCAG and describe their use in
ways that conform to WCAG.


Sidebar: Will Maciej recuse himself from deciding this Issue 31? When
a chair has a direct "interest", previous expressed opinion for either
side, or when, they are so related or associated with either side that
it would appear that they cannot be impartial, it would seem to be
proper to withdraw from the decision. It appears an "interest"
(Mail.app) may have been the impetus for optional alt, the change in
definition, and the start of issue 31:

* "Mail.app and other mail clients don't put alt attributes on images
generated in email" - Maciej Stachowiak, April 11, 2007 [9].

* "I can only imagine it [alt] being useful as an advanced feature for
experts. Normal people won't understand why a mail program would
prompt them to type in some text about an image, that will then not be
visible to them or their recipient." - April 19, 2007.

* Ian cited Maciej's [11] email as the reason for the redefinition of
the image element from a Vlad Alexander type definition [12] to
optional alt in bug 9098 [13].

The Chairs have been asked to consider adding a section on Chair
recusal in deciding escalated issues in Bug 10084 [14].

Best Regards,

[1] http://tinyurl.com/383fthn
[2] http://tinyurl.com/267lmdr
[3] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
[4] http://tinyurl.com/366qtee
[5] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9216
[6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9215
[7] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9169
[8] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9174
[9] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010837.html
[10] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-April/010963.html
[11] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010837.html
[12] http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504
[13] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9098#c1
[14] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10084

Laura L. Carlson
Received on Friday, 16 July 2010 09:14:20 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:21 UTC