Re: Change proposals for ISSUE-31 and ISSUE-80

Can I suggest a couple of changes to this change proposal?

Could we drop the following two exceptions for when @alt is required
from the spec:

* The conformance checker has been configured to assume that the
document is an e-mail or document intended for a specific person who
is known to be able to view images.

* The document has a meta element with a name attribute whose value is
an ASCII case-insensitive match for the string "generator". (This case
does not represent a case where the document is conforming, only that
the generator could not determine appropriate alternative text —
validators are required to not show an error in this case to
discourage markup generators from including bogus alternative text
purely in an attempt to silence validators.)

I do understand the idea behind both these exceptions, but I think
that in reality neither of them will work out very well.

For the first one, a especially configured validator, is anyone really
planning on writing such a validator? If not, it seems like a entirely
theoretical exception. Additionally, I don't see why anyone wouldn't
be free to add any types of configurations to their validator. For
example someone might write a validator that *requires* that RDFa
attributes are added to all <table>s with a particular RDFa vocabulary
in order to ensure that the data can be machine read. We have similar
options in Firefox which break all sorts of specs, for example almost
every greasemonkey script ever written, but I don't think that needs
to be sanctioned by those specs.

For the second one, it seems like the intention here is to avoid
useless @alt attributes being inserted in various documents that are
automatically generated. However this will only help if those
generators are aware if this rule, which I suspect most won't be.
Additionally, it introduces the risk that people will add such a meta
element just to silence warnings about missing @alt attributes. It's
hard enough to see that the added benefit is greater than the added
risk, that I think we should remove this exception.

I have two additional goals with these removals. First of all I think
@alt is the most (or even only) successful bolt-on accessibility
attribute in the history of HTML. And like old proverb goes: if it
ain't broken, don't fix it. I.e. given the success of @alt, I think we
should be extremely careful about messing around with it. For this
reason I'd like to make the number of changes to @alt as small as

For this reason I'd even be fine with removing the other two
exceptions and thus align HTML5 with HTML4. However for now I'll stick
to arguing for the removal of the two, at least seemingly to me, least
useful exceptions.

/ Jonas

On Thu, Jul 15, 2010 at 10:57 AM, Ian Hickson <> wrote:
> =====================
> Require that authors include alternative text for images. Provide
> detailed instructions and examples for doing so to all readers of the
> HTML specification.
> 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.
>  --
> 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.
> Change nothing. The specification includes detailed requirements and
> examples already, and those requirements already reflect the values
> described above.
> * 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.
> None.
> None.
> * 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
>       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 19 July 2010 09:15:59 UTC