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

Yes, we will consider your submission. Thank you for providing additional info.

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 Wednesday, 20 April 2011 05:42:55 UTC