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

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