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