- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 24 Apr 2011 20:44:42 +0100
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: Maciej Stachowiak <mjs@apple.com>, Laura Carlson <laura.lee.carlson@gmail.com>, HTMLWG WG <public-html@w3.org>
On Wed, Apr 20, 2011 at 6:00 AM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > 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. Suggestions follow. > CHANGE PROPOSAL (1st edit): > > A common treatment of all images without @alt. Omittance > without explicit permission is treated as 'invalidateable'. "Invalidateable" is sometimes (perhaps usually?) used to mean "capable of being proven invalid". For example: http://mail-archives.apache.org/mod_mbox/httpd-users/200212.mbox/%3C20021227220217.GB22507@maremma.ch%3E I suggest using a different, clearer word or phrase. If you mean "not capable of being proven valid" I suggest "non-machine-checkable". Compare usage: https://encrypted.google.com/search?hl=en&q="non-machine-checkable" If you mean "not validated", I suggest "not checked". > 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] I recommend incorporating a sufficient analysis of the problems introduced by passing over absent text equivalents in silence into the CP rather than referring readers to a footnote. > Instead we need a single system for every validator > service user. I'm not sure that we need this, but I think the current editor's draft allows this and this CP does not change this. Perhaps you need to elaborate. > DETAILS: > > [ This section should probably be replaced by exact spec text. ] Yep. :) > 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 ?] For the purposes of appraising conformance, how do you test whether a UA has or has not generated repair text? Would this prevent UAs being configured to hide images without provided text equivalents from users? (IIRC this is a common configuration for aural/braille renderings.) > c) ALT text repair text proposal: > * The repair text should be: alt="Image." Why the full stop after "Image"? This seems inconsistent with other UA-generated text (such as "Submit" for submit buttons). It sounds like you want to make this a SHOULD-level requirement. Is your intention to discourage UAs from substituting other repair text? For example, a UA might use repair text generated from other markup such as @src, @aria-label or @title, image metadata, crowd sourcing, OCR, or image recognition. I recommend collaborating with the UAAG authors to ensure that HTML5 and UAAG2 are consistent: http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110406/ Since users deserve the best available repair text, I'd strongly suggest making "Image." simply an example implementation rather than a conformance suggestion. (FWIW I'd likely object to a SHOULD level requirement along these lines.) > * 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.) Browser chrome text (e.g. default labels for input type="submit") generally reflects the system locale. HTML5 does not make conformance suggestions about this, so I don't see why we need to stipulate this. > * AT treatment of a such generated alt="Image." may vary. > [This may need to be fleshed out.] Are you talking about establishing a conformance requirement for AT? AT is not currently a distinct conformance class for HTML5: http://dev.w3.org/html5/spec/infrastructure.html#conformance-classes It is not realistic to make UAs and AT different conformance classes as "The distinction between mainstream user agents and assistive technologies is not absolute." http://www.w3.org/TR/wai-aria/terms#def_at HTML5 is the spec for the syntax, parsing, and semantics of HTML and associated APIs. It's not obvious that it's also the right place to lay down, requirements about how clients of system accessibility APIs should or should not consume them. Also, how would classic UAs such as Firefox and classic AT such as NVDA implement this particular requirement? In terms of (say) the Windows accessibility APIs, how could a user agent distinguish a repaired text equivalent of "Image." from an author-provided text equivalent of "Image." (for an image of the text "Image.") such that API clients could have differing behavior for the two cases? > 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 sounds useless to me, especially as you later describe its potential misuse as a risk. How do you think this would help users, authors, or implementors? Given introducing new CSS features is the provenance of the CSS WG, does your CP strictly require this feature? i.e. Do we have a hard dependency on another WG here? > 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: Might be better to say "conformance checker" if you're referring to that conformance class: http://dev.w3.org/html5/spec/infrastructure.html#conformance-classes > 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. "Required to generate repair text equivalents" (or something similar) might be a more accurate rubric, unless you're proposing UAs add an @alt attribute to the DOM. > 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. Buttons too. http://dev.w3.org/html5/spec/embedded-content-1.html#a-link-or-button-containing-nothing-but-the-image > e) any other machine checkable situation for which the > validator would be able to give accurate advice etc. I'm not sure of the intent of Category e, but it seems too vague to be a testable conformance requirement. > 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. Given we don't have conformance requirements around how source code is displayed, I don't see the need to make explicit allowances. Also, as a user of conformance checkers, I think the suggested UI would be counter-intuitive. I expect to see source code when a tool displays source code or a parsed syntax tree when it displays a parsed syntax tree, not source code or syntax tree /plus/ various higher-level interpretations, such as text inserted as part of browser chrome. > 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. What does this mean? > IMPACT: > > Positive effects. > 1) solves the problem the generator exception was meant to solve This does not sound like a change from the current draft, so it's not really an "effect". > 2) treats all validation users the same, authoring tools & authors I'm not sure a tool is correctly referred to as a "user". > 3) avoids having to define/guess what "hand-authored pages" means What are the two competing interpretations of this phrase that would make a practical difference to users, authors, or implementors? > 4) can still be used as solution to the "e-mail exception" [snip] > 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 Better to rephrase Positive Effects 4, 6 and 7 in terms of benefits to users, authors, or implementors. > Negative effects. > 1) It is still a change compared with HTML4. Better to rephrase this negative effect in terms of costs to users, authors, or implementors. > 2) Some may prefer more direct error messages. This is not a cost compared to the current editor's draft. Perhaps move to "Risks" section? > 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.) Note these do not seem like new risks introduced by this CP? > 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. Is this a subset of Risk 2? > 5) too complicated for validator developers? Listing and counting images without text equivalents doesn't sound more complicated than other conformance checker requirements, but I'm not an implementor. > 6) too complicated validation reports? (Solvable through validation > service design.) If it's solvable, then I suggest including that design as an example implementation in your suggested spec text. If it's not solvable, then this should be listed as a Negative Effect. -- Benjamin Hawkes-Lewis
Received on Sunday, 24 April 2011 19:45:12 UTC