- 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