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

Thank for the update. I have recorded this Change Proposal for both issues on the issue status page:

http://dev.w3.org/html5/status/issue-status.html#ISSUE-031
http://dev.w3.org/html5/status/issue-status.html#ISSUE-080

Regards,
Maciej

On Jul 15, 2010, at 10:57 AM, Ian Hickson wrote:

> 
> 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 Wednesday, 21 July 2010 22:06:40 UTC