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

Hi Leif,

The Chairs have reviewed your reopen request. This Change Proposal does not contain explicitly identified new information, and the Rationale in particular does not seem to contain new information at all. If you would still like to pursue this reopen request, you can update the Change Proposal to explicitly identify new information and resubmit it. At that point, we will evaluate whether the new information likely would have been enough to materially affect the decision.

Regards,
Maciej

On Apr 19, 2011, at 10:00 PM, Leif Halvard Silli wrote:

> 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 Friday, 10 February 2012 01:29:30 UTC