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

On Feb 10, 2012, at 8:27 AM, Leif Halvard Silli wrote:

> 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.

Indeed, the new reopen request will be considered separately, and will not be impacted negatively by this other, older request.

Regards,
Maciej

> 
> 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 18:59:48 UTC