Re: [text] updated draft of clarification on alt validation

Hi Judy,

The figcaption exemption was agreed to by the WAI cg's response to text alternatives in HTML5 and there are use cases that conform to WCAG

One example is to identify a chart or graph that has an accompanying description

<figure>
<img src=chart>
<figcaption> chart 1</figcaption>
<p> chart 1 description </p>


Will comment more when I can get to a PC


Sent from my iPhone

On 29 Apr 2011, at 07:20, Judy Brewer <jbrewer@w3.org> wrote:

> 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 08:50:00 UTC