W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Re: Objection to generator decision (Re: Working Group Decision on ISSUE-31 / ISSUE-80 validation survey)

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 20 Apr 2011 07:00:07 +0200
To: Maciej Stachowiak <mjs@apple.com>
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, HTMLWG WG <public-html@w3.org>
Message-ID: <20110420070007169575.a235f6c8@xn--mlform-iua.no>
Hi Maciej,  my assumption is that the chairs now are considering the 
new info I provided. Do you need more detailed info? When could there 
be a reply?

Meanwhile, hereby follows the outline of a change proposal for the 
generator exception. Suggestions for how to improve are much wanted - 
send to this list or to list@html4all.org.

    CHANGE PROPOSAL (1st edit): 

    A common treatment of all images without @alt. Omittance
    without explicit permission is treated as 'invalidateable'.

SUMMARY: 

   1 Images with omitted @alt for which the validator cannot 
     determine a condition for which HTML5 has an explicit
     permission to omit the @alt, are classified as invalidatable
     w.r.t. alternative text rather than as invalid, except when
     the validator determines a situation for which HTML5 demands
     a specific @alt usage. As HTMl5 already says, documents with
     such IMG elements cannot be stamped as conforming.

   2 Validators are authoring tools. They should thus list/count 
     all IMG elements with omitted @alt, in following categorizes:

   a) those which do not fall into category b), c), d) or e)
      [Thus, for a), then omitted @alt is a de facto per-element
       signal that this element cannot be stamped a conforming.]
   b) those that are valid e.g. because they are the sole content
      inside a figure with figcaption. (In the figure case, then
      @alt represents the presence of the image = can be omitted.)
   c) those with role=presentation (should have empty alt)
   d) those that are the sole content of links (alt = link text)
   e) those that fall into any other machine checkable situation
      for which it can be given clear advice about what to replace
      the omitted alt with.

    NOTE: A basis of this CP is the fact that UAs will and should
     be encouraged to - or MUST - repair the lack of @alt
     even in cases when it is valid to not have an @alt. This, in
     turn, together with a view of the validator as an authoring 
     tool, is the basis for why validator should account for all
     images without @alt. 
    PS: To ask that UAs not generate @alt when it is valid to drop
     it = Accessibility decrease = Useless extra UA requirement.
    NOTE: Validator warns that images without @alt (probably) will
     have alt text being generated and that many images in category
     2a) above probably will hamper accessibility of the document.

   3 Introduction of <style>img::alt { content:"Image.";}</style>


RATIONALE:

This CP accepts as a fact that authors and authoring tools will 
continue to write invalid documents w.r.t. @alt and that this may need 
a more "soft" response than what is common for HTML4 validation. At the 
same time, authors who rely on the validator as a authoring tool, need 
to be made aware about the errors that prevent the document from being 
conforming. And therefore the generator string as a silent error 
suppressor is not useful and also introduces a range of additional 
problems. [1] Instead we need a single system for every validator 
service user. Additionally, HTML5 encourages @alt text to be generated 
when @alt is lacking, and this is something that authors need to be 
aware of even when - or if - it is valid to omit the @alt.

DETAILS:

[ This section should probably be replaced by exact spec text. ]

1) Clarification of how UAs should repair the lack of @alt:

   a)  for IMG with omitted alt, alt text should be generated
       even when the image is not required to have @alt attribute.
       E.g. this example *does* need that the @alt text is 
       repaired for the purpose of representation of the image:
       <figure><figcaption>Title</figcaption><img src=* ></figure>

   b) currently the spec only *encourages* such repair text. This
      CP suggests a MUST instead. [Comments w.r.t. MUST/SHOULD ?]

   c) ALT text repair text proposal:
       * The repair text should be: alt="Image."
       * The repair text should be localized.
       * The localization should be that of the UA and not
         that of the document/element. (Because the user might
         read a page that he/she don't understand the language
         of. It would also be too much to require UAs to support
         the several thousand possible translations of the string
         'Image.' That alt="Image." isn't localized to the 
         document language, is also a form of encouragement to the
         author to actually do provide a useful, localized text.)
       * AT treatment of a such generated alt="Image." may vary.
         [This may need to be fleshed out.]
         (I note that e.g. VoiceOver pronounces 'Image.' for most 
          non-presentational images that it detects, but that this
          is not @alt text but more an element classification. It
          may not make sense to say "Image: Image." Hence AT 
          should be free to not read such repair text.)
        * HTML5's warning that authors should not rely on
          such repair text should remain as is.
  
2) Introduction of a CSS selector for generating alt text:
      img::alt { content:"Image.";}
   This would allow the author to let the alt text vary per
   document language and things like that. This CSS should have
   no bearing on the validity of the image.

3) Validators should count all IMG elements with omitted @alt 
   and list their numbers (or simply list them) as follows:

   a) all IMG elements that are lacking @alt and which
      also do not fall into category b), c), d) or e) below.

      * These images should simply be listed (or made account
        for by telling how many they are). The validator should
        not stamp them as an error. It should instead say that
        it did not perform the validation that was asked for with
        regard to @alt text = cannot stamp document as conforming.
        [This is meant to be in line with HTML5's current 
         statement that documents with the generator string
         are not conforming etc.]
        Validator should also state that user agents are 
        required to generate @alt text for these images.
        And it should also state that there is a high probability
        that the accessibility of the document is hampered 
        because of their lack of alt text. 

   b) all IMG elements that are valid but without @alt.

      * This is necessary because even when they are valid 
        without @alt, an @alt text will, nevertheless, be 
        generated. It is important that authors are made aware of
        this consequence of leaving the @alt out: the author may 
        not be satisfied with the auto-generated alt text - etc.

   c) all IMG elements with role=presentation. 

      * for these images, the validator requires that they get an
        @alt [whether that @alt MUST or SHOULD be empty, is a
        separate question]. This is in line with the current
        Decision on this issue.

   d) all IMG elements that are the sole content of a link

      * for these elements, the validator must require an
        alt text that is suitable as a link text. This is in
        line with what HTML5 currently says about such cases.

   e) any other machine checkable situation for which the
      validator would be able to give accurate advice etc.
   
4) Validators, themselves being HTML5-parsers, when they display
   the checked/parsed source, MAY display this generated alt
   text - preferably in a way which makes the author see that it
   is generated. May be the same colour can be used as is used to
   for "obsolete but conforming" features.

5) Even for documents where all IMG elements are machine checkable
   conforming there should be an encouragement to perform detailed
   image analysis to verify that the document really is conforming.

IMPACT:

	Positive effects.
1) solves the problem the generator exception was meant to solve
2) treats all validation users the same, authoring tools & authors
3) avoids having to define/guess what "hand-authored pages" means
4) can still be used as solution to the "e-mail exception"
5) offers "quick" validation for those in a hurry without
   leaving out the necessary info for those who need the details
6) avoids that there is is a condition (the generator exception)
   under which all the @alt text rules are dropped on the floor
7) incorporates HTML5's current notion of documents with the
   generator string as not conforming but instead says that
   this applies to any document where there is an omitted @alt
8) more pedagogical validator services. Example: An author
   inserts the follwoing code in a HTML5 validator: 
      <a href=link><img src=*></a>
   Validator then reports back that the img lacks an alt text that
   suitable as a link text. Thus the author has learned, without
   reading the spec, that an IMG which is sole content of a link,
   should have an @alt text which is suitable as link text.
   This is also in line with HTML5's notion that one should not
   insert alt text if one doesn't know what to put there: The lack
   of @alt then becomes a pretext for the validator to try to give
   advice about what to put there.
9) Author gets statistics about how many images in this and that
   category he/she has - this is helpful when trying to get
   down to zero invalidatable images.

	Negative effects.
1) It is still a change compared with HTML4.
2) Some may prefer more direct error messages.

CONFORMANCE CLASSES CHANGES

1) the special treatment of documents with the generator 
   string is dropped
2) validators are required to give detailed responses when 
   validating IMGs with omitted @alt
3) spec needs to classify which situations *are* machine checkable
   and which situation aren't. Otherwise, different validation
   services will not detect the same situations. NB: Important
   that the spec can be expanded, in case more machine checkable
   situations are detected.
4) how to stamp documents with invalidatable img elements must
   be specced rather well, to avoid possible misuses.
   Perfect balance is important.
5) more detailed spec + requirements w.r.t. @alt text repair
6) more detailed spec + requirements w.r.t. AT and repaired @alt
7) spec text with advice about how to use img::alt{}. Could e.g.
   say that it can useful whenever it is valid to drop the @alt.

RISKS

1) Risk that validator users do not understand the difference 
   between a document with invalidatable img elements and fully
   conforming documents. 
2) Risk that non-conforming documents are presented as conforming,
   against the presenter's better knowledge. (Misuse.)
3) Risk that img::alt{content:"Alt text";} is misused.
4) Perhaps authors will drop all @alt text and then run against 
   the validator, with the aim of only add @alt text for those img
   elements where validator requires them? Thus a kind of "satisfy
   the validator" behaviour.
5) too complicated for validator developers?
6) too complicated validation reports? (Solvable through validation
   service design.)

REFERENCES:
[1] Letter to the chairs with new info re/the generator exception
    http://lists.w3.org/Archives/Public/public-html/2011Apr/0466

End of CP (1st edit).

Leif Halvard Silli
Received on Wednesday, 20 April 2011 05:00:38 GMT

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