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

Change proposals for ISSUE-31 and ISSUE-80

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 15 Jul 2010 17:57:07 +0000 (UTC)
To: public-html@w3.org
Message-ID: <Pine.LNX.4.64.1007151755460.24444@ps20323.dreamhostps.com>

ISSUE-31 AND ISSUE-80
=====================

SUMMARY

Require that authors include alternative text for images. Provide
detailed instructions and examples for doing so to all readers of the
HTML specification.

RATIONALE

1. REQUIREMENTS: The HTML specification should include a full and
complete a description of the requirements that authors must fulfill
to provide alternative text for images, because:

 * The HTML specification is the logical place to define the HTML 
   language.

 * The HTML specification is where one finds all the other descriptions of 
   requirements that apply to authors of HTML documents.

 * Defining the requirements that apply to HTML's <img> element's alt="" 
   attribute in the same specification as the requirements for the <img> 
   element's src="" attribute makes it more likely that authors reading 
   the requirements for src="" will see the requirements for alt="".

 * Having the information in the HTML specification will lead to the most 
   usable and most fully expanded text possible for this topic.

 * Having the requirements for alt="" attributes inline right at the 
   definition of the <img> element and the alt="" attribute will most 
   effectively reflect the importance of the the provision of text 
   alternatives.

The requirements should be the most rigorous set of requirements we
can provide to ensure the most accessible results are achieved if they
are followed. Naturally such requirements are not machine-checkable
with the state of the art; as with any constraints placed on correct
usage of semantic markup, we have to rely on interpretation. This is
not new, however; it has long been established, for instance, that
presentational images that are not relevant in a non-visual medium
should have the empty string as alternative text, but requiring this
is not machine-checkable -- there's no way for a machine to know that
the image really is presentational. Nonetheless, we should require
this so that users get the most accessible results when the author
follows the specification.

Finally, we should ensure that we provide the most robust, creditable,
usable and useful set of text alternative requirements possible. We
can only do this by providing detailed requirements to cover every
eventuality, from describing how to handle groups of images that work
together to form a single picture, to how to provide alt="" text in
special cases like CAPTCHAs or how photo upload sites like Flickr can
write conforming documents even in cases that can't be fully
accessible (such as when the site is unaware of an image's contents),
to how to handle simple icons or logos, with everything in between

The HTML specification should also include detailed examples of these
requirements, because including examples near the text they are
illustrating is the most optimal way of explaining those requirements.

2. EQUALITY: There are certain edge cases where a page producer must
reference an image without knowing what the image is. Such a producer
cannot, by definition, provide a textual alternative to the image:
they do not know what the image is.

One example of this would be a blind photographer who has taken a
hundred photos during a vacation, without keeping track of any
information as to when or where each photo was taken. Faced with these
one hundred JPEG images and the desire to write an HTML Web page that
exposes those images, the photographer has no ability to provide
alternative text.

We therefore need a mechanism by which the photographer can provide
such photos. The photos would still need identifying -- that is, the
photographs would still have titles or captions -- but they would not
have any alternative text. There are two mechanisms in HTML for
providing titles or captions for an image: the title="" attribute,
which acts on a per-image basis, and the <figcaption> element, which
acts on a per-<figure> basis.

The alternative would be to discriminate against the blind
photographer, which would be a step backward. Disallowing the
photographer the opportunity to expose these images with no
alternative text would be a very real debasing of the web's inclusive
world-wide goals. Making sure we handle this case is considered
important at the highest levels -- for example, the United Nations
Convention on the Rights of Persons with Disabilities, in Article 9,
requires signatory states to ensure to persons with disabilities
access, on an equal basis with others, to information and
communications technologies and systems. Indeed, maybe more
importantly and with more relevance to this working group, our own
design principles say that features should be designed for universal
access.

3. PRIVATE USE: In some cases, extremely complex images may be sent
from one user to another as part of a private HTML document or HTML
e-mail. Such images may be so complex that writing useful alternative
text would be a significant endeavour of its own, tantamount to
recasting the entire image as text. Ordinarily, that work would be
worth the effort, since not all users are able to see the images; the
specification should in fact require that work ordinarily. However, we
would be ignored (and likely ridiculed) if we required people to write
such text in the case of private HTML documents or HTML e-mails
amongst users who know each other and are aware of each other's
abilities (both technical and physical) to access visual
images. Therefore we should have an exception in the requirements for
this specific case. Having said that, we should encourage even such
edge cases to provide full alternative text, in the event that the
documents or e-mails are sent on to other users who are not able to
access visual images.

Now, we do not want conformance checkers to "allow" anyone to omit
alternative text just in case they are in this situation, so we should
further constrain conformance checkers to not allow this unless they
have been specifically configured. If we fail to do this, we would
undermine the entire attempt at making pages more accessible by
requiring alternative text for images in the normal case.

4. AUTHORING TOOLS: As Gez Lemon has stated:

| When an authoring tool doesn't have anything useful to put in for
| the alt text, the tool shouldn't put anything in. A good authoring
| tool will check for missing alt text and offer to assist the user in
| repairing the content. If an author is adamant they're not going to
| provide alt text, there is no requirement that says the authoring
| tool should provide it in place of the author. In fact, it's just
| the opposite, as the authoring tool could not possibly know the
| author's intent. In this scenario, the authoring tool should not
| include the alt attribute at all, and the resulting markup should be
| considered invalid. It should be considered invalid because it is
| inaccessible, and not perceivable by some people. If the tool allows
| alt text to be provided, then the tool would be considered compliant
| (on this particular issue), even though the resulting markup would
| not be compliant, as the user chose not to make the content
| compliant.
 -- http://juicystudio.com/article/html5-alt-text-authoring-tools.php

Unfortunately, despite what the specification says, users will
consider an authoring tool non-conforming (buggy) if the documents it
outputs are not flagged as conforming by validators. Therefore we need
a way for validators and authoring tools to coordinate so that
validators will not criticise conforming authoring tools when a
problem (in this case missing alternative text) is the user's fault
and not the author tool's. The simplest solution here is to reuse the
existing document-wide flag that indicates that a document was created
by an authoring tool, and have conformance checkers silently ignore
the missing alternative text in that situation (or at least phrase the
error in a way to indicate that the authoring tool is not to blame),
despite the document not being valid.

5. TEACHABLE MOMENTS: HTML4 made the alt="" attribute required, but
didn't provide anything useful in the way of information beyond
that. In HTML5, we have an opportunity to dramatically improve on the
status quo, providing a dramatic increase in the educational value of
the specification and thus a dramatic increase in the accessibility of
the Web as a whole. We can do this by requiring particular kinds of
alternative text, rather than simply saying "alt is required" and
letting authors guess as to the best value, something which we have
shown over the years with HTML4 to be a quite unsuccessful strategy.

6. DEFINITIONS: The <img> element intrinsically is intended to be used
for displaying visual images, whence the name of the element. The
specification previously claimed that the element was to display
content that had both a textual version and an image version, but
feedback indicated that this was not realistic: in practice, authors
use it to display images, and the alternative text is not a
first-class citizen in comparison; ignoring this in the interests of
political correctness is unrealistic. Thus, the specification should
define the <img> element as representing primarily an image.


DETAILS
Change nothing. The specification includes detailed requirements and
examples already, and those requirements already reflect the values
described above.

IMPACT

POSITIVE EFFECTS
* Having authoring advice will help advise authors.
* Having detailed conformance requirements will increase the
likelihood that authors will write good alternative text.
* Having detailed examples will increase the the likelihood that
authors will write good alternative text.
* Having conformance requirements independent of AT APIs will ensure
that authors are encouraged to write documents that are optimal even
for users that do not use ATs.
* Upholds the structural integrity of <img> element.
* Facilitates accessibility awareness and education.
* Having this text in the specification shows how important the
subject is to the working group.
* Having the requirements for alt="" attributes text in the same
specification as the <img> element and alt="" attribute are defined
improves the discoverability and usability of the information by
keeping it in the most obvious place for readers.
* Keeping the text as is minimises the impact on the editor's time,
freeing him up to work on bugs.
* Having this text in the core HTML specification enables subject
matter experts to have more input into the content and style of the
recommendations than if the content is split into multiple documents.
* Not having any mention of technologies from other layers, e.g. ARIA
or RDFa, prevents layering violations and avoids abusing annotation
technologies for core conformance.
* Having this text in the core HTML specification makes it easier for
changes to be made, since only one document need be edited when the
language changes.

NEGATIVE EFFECTS
None.

CONFORMANCE CLASS CHANGES
None.

RISKS
* We may have missed a use case. However, that's easy to resolve: we
can always add it later.
* The feature to silence validators for authoring tools could be
misused by authors who want to use a validator but don't want to give
alternative text, but if that occurs (which seems unlikely) it is easy
to resolve by changing the validator requirements to still clearly
announce that the document is invalid while saying it's not the
authoring tool's fault.
* The current text might use too much jargon or have unclear
formatting. However, that's easy to resolve in response to bugs.
* It is possible that some user agents do not support all the features
of HTML, for example some ATs do not yet make the 1990s-era title=""
attribute easy to access, and many browsers do not yet support
<figcaption>. Authors using HTML features before they are widely
implemented are always at risk of their pages not being fully
accessible to their readers; this is well-understood by authors and
authors have to make a trade-off between targetting newer UAs and
using newer features, and targetting more users and using older
features. However, this should not be used as a reason to prevent
progress; if certain UAs continue to not support features despite them
having been widely accepted, those UAs should be criticised for being
non-conforming rather than the entire technology being held back.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 15 July 2010 17:57:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:10 GMT