W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

[text] updated draft of clarification on alt validation

From: Judy Brewer <jbrewer@w3.org>
Date: Fri, 29 Apr 2011 02:20:02 -0400
Message-Id: <E1QFh6V-0000Ve-C5@maggie.w3.org>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
UPDATED DRAFT...
- this version plugs in updated sections that 
people were working on since our text 
alternatives sub-group meeting on Monday 25 
April. (role=presentation: Rich and John; 
generator: Leif and John; title: Rich, Steve; figcaption: Geoff and Judy).
- it also notes some questions pending;
- please identify additional questions or points as needed;
- please let me know if I've missed any input;
- we'll be discussing the latest version of this 
draft in our meeting on Monday 2 May; comments also welcome on the list.

The summary of who was working on what as of the 
end of Monday 25 April meeting is available here
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0289.html

Please check your sections below to make sure 
that I've grabbed the latest version of the text 
you're proposing, and whether I've embedded any questions.


[UPDATED DRAFT]

With regard to the HTML Working Group Co-Chairs' 
decisions, described in the following email:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html

...which discussed the following issues with 
regard to validity requirements for alt:

>There is a basic disagreement in the group on the validity
>requirements for alt.  The result was two issues, six change
>proposals, and a straw poll for objections:
>
>http://www.w3.org/html/wg/tracker/issues/31
>http://www.w3.org/html/wg/tracker/issues/80
>http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html
>http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126
>http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706
>http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707
>http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100510
>http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504
>http://www.w3.org/2002/09/wbs/40318/issue-31-80-validation-objection-poll/results

...and which arrived at the following six conclusions:

>Therefore, the HTML Working Group hereby decides that:
>
>    * The presence of aria-labelledby does not make missing alt conforming.
>    * The presence of role=presentation does not make missing alt conforming.
>    * The presence of <meta name=generator> makes missing alt conforming.
>    * Use of private communications does not, in 
> itself, make missing alt conforming.
>    * The presence of title makes missing alt conforming.
>    * The presence of figcaption makes missing alt conforming.

...we provide the following clarifications on the 
four decisions among these that we find 
problematic. Please let us know of additional 
clarification questions on the following information if needed.


== On the Co-Chairs' decision on role=presentation ==

>* The presence of role=presentation does not make missing alt conforming.

The default semantics for and image with alt="" 
is role="presentation". The accessibility API 
mapping is such that, when alt="", the <img> 
element is removed from the accessibility API 
tree to improve assistive technology performance 
as well as browser performance in that the 
browser is not maintaining accessible objects for 
these presentational elements. Applications, such 
as those from IBM, have used role="presentation" 
to remove these objects from the accessibility 
tree as HTML4 does not have the same mapping as 
we have specified for HTML 5. So, not allowing 
alt="" and role="presentation" to be used 
interchangeably violates consistency with the 
default HTML 5 semantics and is inconsistent with the ARIA specification.

[the text above is from Rich and John as indicated in Rich's email
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0322.html ]

[note Leif's subsequent question, to which I 
can't find a reply; Rich or John can you 
elaborate your answer to address Leif's 
questions, or indicate your reply if I've missed it?
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0330.html ]

[Rich and John, can you look back at Maciej's 
decision on role=presentation and check that you 
have addressed all of the relevant arguments in 
that section, or add to your reply if needed?
http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html ]


== On the Co-Chairs' decision on meta name=generator ==

>    * The presence of <meta name=generator> makes missing alt conforming.

[inserting comments from Leif]

In regards to the generator decision we would 
first of all comment the two kinds of evidence 
which the chairs suggested as reasons to reopen the decision:

1. EVIDENCE: DELIBERATELY OMITTING ALT DUE TO GENERATOR EXCEPTION
    HTML5's description of how [1] "markup generators should examine the
link target to determine the title of the target, or the URL of the
target, and use information obtained in this manner as the alternative
text", seem like a reasonable feature to expect from quality authoring
tools, even when - because an img element is sole content of a link -
the link text is supposed to be @alt text.¬ [2] If generator vendors
stop to expect that their tools can do this, and instead point to their
"bad users" as justification for why they need a generator exception,
then we believe we have evidence to suggest that the exception does a
disservice for accessibility. We read  Aryeh's presentation to the
HTMLwg of WikiMEDIA bug 368 (in his reply to Maciej/the Decision) as a
strong hint that such negative effects of the generator exception are
likely to be seen. [3]

[1] 
http://dev.w3.org/html5/spec/embedded-content-1#guidance-for-markup-generators
[2] 
http://dev.w3.org/html5/spec/embedded-content-1#a-link-or-button-containing-nothing-but-the-image
[3] http://lists.w3.org/Archives/Public/public-html/2011Apr/0459

2. EVIDENCE: LIST OF AUTHORING TOOLS (MIS)USING THE META GENERATOR
    Evidence that authoring tools are making use of the generator
exemption, and that this interferes with proper inclusion of alt is
hard to provide before Last Call, amongst other reasons because the
HTML5 validator doesn't support the generator exception (yet). [The
HTML5 validator does not seem to check @alt in any way whatsoever.] The
rule thus has not managed to make impact yet. However, there is an
endless list of authoring tools which do make use of the generator
string. And both tool vendors and authors using their tools would be
certain to get lots of gotcha experiences if the generator string lures
them to think the page is valid when it isn't. We point to the
following messages for documentation of some of those tools. [4][5][6]

[4] The list in the original change proposal from Laura
[5] http://lists.w3.org/Archives/Public/public-html/2011Apr/0474
[6] http://lists.w3.org/Archives/Public/public-html/2011Apr/0580.html


3. EVIDENCE: LACK OF ALT CHECKING IS HARMING
    Additionally, since the HTML5 validators does not currently perform
any validation of whether alt is present at all or of how it is used,
it makes sense to try to evaluate if HTML5 pages currently use less or
more @alt than HTML4 pages ddo. Spending a few minutes at the HTML5
gallery, [7] it did not take many pages to find code which omitted
@alt. See reference [8] to [20] below - which equals 12 of 60 pages
looked at.  Just to single out the worst: Reference [8] has 20 img
elements but not a single @alt. Ref [15] has 9 img elements and not a
single alt. Ref [16] has 8 (of 9) images with no alt. Ref [16] has 6 of
6 images without @alt.) Other pages: the HTML5boilerplate.com¬ [21] has
no alt on its HTML5 badge ...  As does http://html5readiness.com/ [22].
[23] and [24] are to tutorials which forgets @alt. (We have tried to
avoid counting lack of @alt inside <figure>.)

|7] http://html5gallery.com/page/2/
[8] http://mat-t.com/
[9] http://www.tweetoon.co.uk/#footer
[10] http://www.aviary.com/html5builder
[11] http://www.dielinke-europa.eu/
[12] http://blackbull.in/
[13] http://wantist.com/
[14] http://ffpbooth.com/
[15] http://www.kubimedia.com/
[16] http://jeffaquino.com/
[17] http://www.jswidget.com/
[18] http://www.dooity.com/
[19] http://www.pelanidea.com/
[20] http://onenyne.com/
[21] http://html5readiness.com/
[22] HTML5boilerplate.com
[23] http://tutorialzine.com/2010/02/html5-css3-website-template/
[24]
http://net.tutsplus.com/tutorials/html-css-techniques/html-5-and-css-3-the-techniques-youll-soon-be-using/

In addition to the asked evidence, we will also make the following
points about why the generator exception should be reexamined:

A: A REINTRODUCTION OF VERSIONING.
    The meta@name=generator exception has a direct parallel in the
generator exception for WYSIWYG editors present in HTML5 in the January
2008 draft, [1] which Karl Dubost and many wg members acknowledged as a
form of versioning. [2][3] When it comes to "real" versioning, then it
has been banned from HTML5 - at the latest in a Decision in December
2010. [4] A generator exception for img elements remains a form of
versioning. Thus to operate with this exception, breaks an important
design goal behind HTML5.

[1] http://www.w3.org/TR/2008/WD-html5-20080122/#wysiwyg
[1] http://lists.w3.org/Archives/Public/public-html/2007Aug/0290
[2] http://www.w3.org/QA/2007/05/html_and_version_mechanisms
[4] http://lists.w3.org/Archives/Public/public-html/2010Dec/0135

B: TWO TIER DOCUMENT QUALITY.
    The HTML5 editor in 2007 described the WYSIWYG generator exception
as a "solution for handling ... two tiers of document quality", but
nevertheless, in the same letter, he also promised to drop the entire
WYSIWYG generator flag. [5] However, the current generator exception is
a direct continuation and broadening of the very same flag. Authoring
tools vendors are not going to be willing to stamp their own code as
substandard, let alone use their own product names as a sub-quality
marks. Especially not when some authoring tools consciously refer to
themselves as HTML generators and claim that this means that "code is
clean and standards compliant all the time". [5a]

[5] http://lists.w3.org/Archives/Public/public-html/2007Aug/0186
[5a] http://www.softpress.com/kb/questions/87/

C: GENERATOR IS ALREADY IN USE FOR OTHER PURPOSES
    Authoring tools use the generator string as a kind of signal to
those who view source - to identify pages made by their product.
Softpress, an authoring vendor, documents in their KnowledgeBase that
they use it for debugging purposes. [6] The HTMLwg has many times
rejected to reinterpret legacy HTML features in incompatible ways -
this is why <figcaption> and <summary> was created and <dt> and <dd>
was rejected as child-elements of <figure> and <details>. A
reinterpretation of the meta@name=generator string appears very similar
to the predefined class names that the HTML5 draft had in 2007. Like
authors should be free to use class names as they wish, the generator
string should continue to be in the generator vendors' free domain.

[6] http://www.softpress.com/kb/questions/47/

D: DROPS ALL REQUIREMENTS ON THE FLOOR
    The generator exception drops all authoring requirements for @alt
text on the floor, even those which are machine checkable. For example
the requirement that an img element that is the sole content of a link
must have alt text that is suitable as link text. [7] HTML5 explains
how a generator (!) can pick link text from the title of the target
page and similar to get link text, thus there is a doable task
description. [8] Authors and tool vendors must be taught to make
choices - accessibility and code quality is not brought forward by
cultivating a spirit which says "if you aren't absolutely 100% certain,
then it is better you don't put anything inside the @alt".

[7]
http://dev.w3.org/html5/spec/embedded-content-1#a-link-or-button-containing-nothing-but-the-image
[8]
http://dev.w3.org/html5/spec/embedded-content-1#guidance-for-markup-generators

E: ALTERNATIVES TO THE GENERATOR EXCEPTION
    Leif has proposed a change proposal [9] which consider all img
elements without @alt as invalidatable while at the same time helping
authors to fix them. That CP also makes no distinction between
generators and other authoring tools. We are not locked to his
unfinished CP, but we find it a much better starting point than the
generator exception.

[9] http://lists.w3.org/Archives/Public/public-html/2011Apr/0480

[ Steve do you have additions to this from recent emails, or is this all set? ]


== On the Co-Chairs' decision on the presence of 
title making missing alt conforming ==

>* The presence of title makes missing alt conforming.

[ starting with the initial text from Rich]

Title has a completely different function from 
alt in HTML. Title is used to generate a tooltip, 
and is invisible when images are turned off. Alt 
does not generate a tooltip, and is visible when images are turned off.

If title is allowed as alternative text over alt 
it will break applications such as Yahoo! mail; 
it will also break a commonly-used feature, in 
less powerful mobile phones, where images are 
turned off to improve performance. If title were 
to be used in place of alt then when images are 
turned off in the browser, nothing meaningful will be shown in the browser.

Furthermore, having title take precedence over 
alt will result in tooltips being generated on 
decorative images and spacers, which would do 
tremendous harm to the user experience.

It should be noted that title is used as a last 
resort when other measures cannot be employed to 
compute the label or "name" of an object in the 
accessibility API mapping for browsers.

Please note the following demonstrations of 
failures resulting from the proposed approach:
http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/screenshots.html

[and now adding the following from Steve 
http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0321.html ]

figure/figcaption provides the opportunity to 
convey a clear semantic differention between a 
caption and a text alternative. Use of the title 
attribute does not. title maps to the accessible 
name property (in cases where no other accessible 
label is provided) in accessibility APIs while 
<figcaption> can be mapped to a caption role in accessibility APIs.

The 
<http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/>IAccessible2 
and 
<http://people.gnome.org/%7Ebillh/at-spi-idl/html/namespaceAccessibility.html#a216>AT-SPI 
accessibility API's have caption roles:
"ROLE_CAPTION The object contains descriptive 
information, usually textual, about another user 
interface element such as a table, chart, or image."

It has also been suggested that a caption role be 
added to ARIA next. 
(<http://lists.w3.org/Archives/Public/wai-xtech/2011Apr/0007.html>http://lists.w3.org/Archives/Public/wai-xtech/2011Apr/0007.html)

The accessible support story for the title 
attribute has always been poor and there is no 
indication that this will change.
NO graphical browser provides device independent 
support for display of tooltips and the support 
has not improved over the last 6 years since I 
detailed issues with the title attribute in 2005 [4].
So far no browser vendor representatives have 
given a positive response to Steve's query [1] 
about whether this will change, but 2 stated there are no plans to [2].
Support for the display of title attribute 
content has decreased markedly over the last few 
years, none (to my knowledge) of the mobile or 
touch screen browsers developed provide access to 
it. I have recently published Information and 
guidance based on current known issues [3].

[1]<http://lists.w3.org/Archives/Public/public-html/2011Apr/0468.html>http://lists.w3.org/Archives/Public/public-html/2011Apr/0468.html
[2] http://lists.w3.org/Archives/Public/public-html/2011Apr/0490.html
<http://lists.w3.org/Archives/Public/public-html/2011Apr/0507.html>http://lists.w3.org/Archives/Public/public-html/2011Apr/0507.html
[3] http://www.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/
[4] 
<http://www.paciellogroup.com/resources/articles/WE05/>http://www.paciellogroup.com/resources/articles/WE05/

[Rich, Steve, does this text fully address any 
clarifications needed in response to Maciej's 
arguments in his discussion of title?
http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html ]


== On the Co-Chair's decision on the presence of figcaption ==

>* The presence of figcaption makes missing alt conform

*Figcaption is not an appropriate replacement for alt

[adding text from Geoff and Judy; last edits and any errors are Judy's]

Depending on the type of image and the type of 
publication, figure captions may be either 
concise or verbose. When information contained in 
figcaption is detailed and complicated, it may be 
more akin to that supplied by the current 
longdesc attribute.  alt, on the other hand, is 
normally brief and identifies the image rather 
than fully describing it, especially when the 
image is complex.  Permitting figcaption to take 
the place of alt in some situations may result in 
more information being delivered to the user than 
the user needs or wants. Instead, the user should 
be able to receive the long description via figcaption if they so choose.

figcaption may not fulfill the needs of assistive 
technology users, particularly blind or visually 
impaired users/screen-reader users. The 
convention for use of figure captions in 
publishing is to describe images that users _can_ 
see; in contrast, alt and longdesc attributes as 
used today in HTML identify and/or describe 
images that users _cannot_ see.  The two 
audiences are different, and as such require 
different approaches for image description. In 
scientific publications, for instance, 
information presented in figure captions will 
often state the scientific principles being 
illustrated, but not describe the illustration 
nor necessarily even identify the image, as the 
authors assume that the audience can identify and 
discern information that is presented visually. 
To adequately support the needs of blind or 
visually impaired users may require a level of 
verbosity that sighted users would object to if 
presented in a visible description via figcaption.

*Replacement of alt by figcaption breaks existing assistive technology support

No screen reader in use today supports 
figcaption. Popular screen readers today do 
support the reading of the alt attribute and, in 
some cases, the longdesc attribute.  Users are 
accustomed to locating image descriptions and 
identifiers via these two methods. If alt is 
omitted because a figcaption exists, how will a 
screen reader notify the user that a description 
exists in figcaption rather than alt? Supplying 
image descriptions via figcaption may confuse 
screen-reader users who are already used to 
finding descriptions via the alt or longdesc 
attributes.  A single Web page that contains four 
images with descriptions provided via alt or 
longdesc, and two images with descriptions 
provided via figcaption, presents a confusing 
situation for a screen reader user, and increased 
problems for assistive technology support.

Delivering a brief description or identifier via 
the alt attribute is an established, successful 
mechanism; making missing alt conforming in the 
presence of figcaption breaks a successful 
accessibility feature of HTML, and introduces an inappropriate alt substitute.


Please let us know if additional clarifications 
are needed, and thanks in advance for your re-consideration.

Regards,

....

--
Judy Brewer    +1.617.258.9741    http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C)
MIT/CSAIL Building 32-G526
32 Vassar Street
Cambridge, MA,  02139,  USA 
Received on Friday, 29 April 2011 06:23:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:36 GMT