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

Hi Maciej,

Thanks for the evaluation. I have, since roughly summer last year, been 
comforted by the fact that Steve and the A11Y group has worked o this 
issue - they submitted their re-open requests just before you published 
your evaluation. Without going in detail about my faulty logic, I now 
realize that I therefore ought to have withdrawn my reopen-request, to 
show my support for their forthcoming - and now published - reopen 
request. I hope that my lack of action does not impact negatively on 
your evaluation of the new request.

regards,
Leif H Silli

Maciej Stachowiak, Thu, 09 Feb 2012 17:27:18 -0800:
> 
> 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 16:27:49 UTC