- From: Judy Brewer <jbrewer@w3.org>
- Date: Fri, 29 Apr 2011 02:20:02 -0400
- 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 UTC