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

response to counter proposal for ISSUE-31 AND ISSUE-80

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Fri, 16 Jul 2010 01:56:19 +0200
Message-ID: <AANLkTimGPfcYDCSRGaZvRl_UYrCDfjsvXIHQpNdSkHtm@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>, HTMLWG WG <public-html@w3.org>
Cc: Sam Ruby <rubys@intertwingly.net>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>
 The following is a reponse to sections of the counter proposal I think are
relevant to the  *Change Proposal: Remove specific alternate text
requirements for various specific cases of img and replace with reference to
external document.*<http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209>:
, if the chairs advise I can add the text below to the change proposal.

quoted text is from

  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.

* Editorial point we are not defining HTML, we are defining HTML5

There is nothing inherently prefereable in having all requirements in a
monolothic document. No reasonable justification is provided for this
Nowhere is it decreed the HTML5 requirements cannot be defined in a family
of documents.

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

It is not intended that the "HTML5: techniques for the provision of useful
text alternatives" will be something other than part of the family of
documents that makes up the HTML5 specification.

 * 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="".
> Providing a clearly described link to a a seperate document that defines
the requirements for alt makes it no less likely that authors who are
interested in the information will follow the link to read the document. It
is also much better for authors who search for information on the alt
requirments in HTML5 using a search engine:

For authors who search for html5 alt text information on google for example,
they can easily find the 'HTML5: Techniques for providing useful text
alternatives' even though it has been publsihed a  short time (months)
compared to the alt related text in HTML5 (years).

1. search for "HTML5 alt text" or "HTML5 alt attribute"

The alt spec is 4th in the results, just below the W3C HTML5 spec (result
points to http://dev.w3.org/html5/spec/Overview.html)
If they follow the link to the HTML5 spec they then have to locate the link
to the alt section amongst 3397 other links on the overview page. With the
alt spec they follow the link from the google result page and arrive
straight at the document containing the information they searched for.

2. search for "text alternatives"
2nd result

The main HTML5 spec does not appear on the first or second pages page

3. search for "HTML5 alt"
first result

4. search for"html5 alt conformance"
first result

The main HTML5 spec does not appear on the first or second pages of results

5. search for "html5 alt requirements"

Third result,

A link to the whatwg spec (which is not HTML5) is 6th result, again it
points to the overview page of the whatwg spec, not the specific section
dealing with alt, so the user has to find the releveant section from the
3617 links on the page, that is if they are able to actually load the page
in their browser without it crashing or locking up. With the alt spec they
follow the link from the google result page and arrive straight at the
document containing the information they searched for, the document loads
quickly and does not crash the browser.

Point being that for discoverability purposes, the creation of a seperate
document has already improved the discoverability and ease of access to the
HTML5 conformance requirements and guidance for the use of alt.

  * Having the information in the HTML specification will lead to the most
>  usable and most fully expanded text possible for this topic.
> How can this claim be made, what magic is involved when information is
placed in the monolithic HTML5 spec that makes it "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.

It can equally be argued that having a a seperate document specifying the
provision of text alternatives in HTML5 will most effectively reflect the
importance. (also see google results above).

 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.
> So what is the point you are trying to make? that the requirements in the
HTML5: techniques document are any less rigorous?

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

Yes, agreed and the HTML5: techniques document is intended to provide this,
if there are use cases missing please file a bug.

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.

The HTML5 alt techniques document does this.

I have not responded to the other arguments as I think they cover issues
related to the other change proposals this counter proposal is a response
to. if the chairs think it any of the other sections of the counter proposal
are relevant, I will be happy to provide further responses.

Received on Thursday, 15 July 2010 23:57:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:21 UTC