Machine Image Processing

Proposed Solution

PF should provide the guidance to the HTML5 WG that we previously agreed upon in the Text Alternative Proposal. If the wording of the Text Alternative Proposal is deemed deficient, the following two points should be added to it:

Any alt value that did not originate from a person constitutes a misuse of alt and should be flagged as an error. This explicitly forbids the use of alt for machine placeholder text or to provide machine processing information.
There MUST be a means of adding human parseable terse descriptors using alt or aria-labelledby. Tools like Flickr should aim for ATAG and WCAG compliance. Ideally, the author should be prompted to provide terse descriptors at load-time or pre-load, but definitely MUST provide a facility to attach terse descriptors to each image post-load.

Use @role for machine processing

Have image gallery tools (e.g. Flickr) default to images remaining invisible to the public until:

Text alternatives are provided by the author or
A conscious decision has been made by the author to deliberately publish them without text alternatives.

If option 2 is chosen tools would insert <img @role="img"> which is invalid per Resolutions regarding short alternatives.

Outcomes

This solution would:

provide a means for conscious author deliberation (also educational opportunity/teachable moment)
provide a method for error detection and handling
enable accessibility tools and validators to quickly pinpoint where @role="img" has been used and allow for future improvement of the text alternative

Rationale

When an authoring tool doesn't have anything useful to put in for the alt text, the tool shouldn't put anything in. A good authoring tool will check for missing alt text and offer to assist the user in repairing the content. If an author is adamant they're not going to provide alt text, there is no requirement that says the authoring tool should provide it in place of the author. In fact, it's just the opposite, as the authoring tool could not possibly know the author's intent. In this scenario, the authoring tool should not include the alt attribute at all, and the resulting markup should be considered invalid. It should be considered invalid because it is inaccessible, and not perceivable by some people. If the tool allows alt text to be provided, then the tool would be considered compliant (on this particular issue), even though the resulting markup would not be compliant, as the user chose not to make the content compliant.
An author obviously has a responsibility in using an authoring tool. It is unreasonable to state that the output from authoring tools should always be considered valid, regardless of input or lack of thereof.
Machine-generated patch-jobs and text alternatives originating from a person are not equivalent. The two aren't the same and shouldn't be confused or on purpose or otherwise.
The Authoring Tool Accessibility Guidelines 2.0, which apply explicitly to sites like Flickr, require that such sites prompt authors for that content. If they prompted for and stored that content from the user, they’d be able to insert meaningful alt text where it is required.
It is desirable for a tool to help educate an author to write accessible content.
In HTML5 an author can provide an address with the address element that isn't a contact address, which would NOT be considered conforming.
Flickr image pages currently have over 50 validity errors, and that's just HTML 4.01 Transitional. Why should the HTML5 make supposedly narrow exceptions to the spec to be more lax about validation when the sites themselves aren't even trying today?

Related Resources

Alternative Text Code Examples