Bugzilla – Bug 9212
Change the Generator Mechanism for img from Document Level to Element Level
Last modified: 2012-09-14 03:05:43 UTC
SPEC SECTION: Image Guidance for conformance checkers 
The generated mechanism should only be included at the element level with a detection method like a "generated" attribute, rather than the document level.
If the generated option is left at document level, as in the current editor's draft, it would be too easy for authors just to tag the document "generated" and then forget to provide any text alternatives for images.
1. Author logs into the photo sharing site
2. Author uses the uploader feature to upload 50 pics of a vacation (XYZ0001.png, XYZ0002.png,..., XYZ0050.png) into an album the author calls "Paris 2009".
3. A prompt appears asking the author to write descriptive labels for each image to facilitate text searching and access by people with disabilities.
4. The author logs off without adding individual text alternatives.
5. The photo sharing site assigns the @alt strings "Photo 1 of 50 of album Paris 2009"
6. The author logs back in they still see "generated" indicators on the images and/or the album that reminds them that the images are still lacking descriptive labels.
7. The page will be HTML5_valid because it includes @alt
8. The feature will meet the proposed ATAG2 requirement because the "After authoring session ended" repair used contextual information not available to the user agent.
9. The page will NOT meet WCAG 2.0 because the text alternative does not serve the equivalent purpose.
Source: ATAG2 B.2.4 Assist authors to manage, edit, and reuse equivalent alternatives for non-text objects - Jan Richards. 
OUTCOMES OF FIXING THE BUG:
Outcomes of creating a "generator" attribute include:
* Enables tools to programmatically determine  where text alternatives are needed and allow for future improvement. It would provide a practical method of detection and handling.
* Identifies/stamps any metadata repair as indeed a metadata repair. This makes it clear it is a machine-generated patch-job and not a human-generated text alternative. The two aren't the same and shouldn't be confused or on purpose or otherwise.
* Is harmony with proposed Authoring Tool Accessibility Guideline (ATAG) 2.0 B.2.4. 
* Is in accord with Accessibility Coordination Group's "Consensus Resolutions on Text alternatives in HTML 5". .
HTML5 ISSUE AND CHANGE PROPOSAL:
This is associated with HTML TRACKER ISSUE-31
Change Proposal: Replace img Guidance for Conformance Checkers:
Requesting expedited processing of this bug on behalf of the WG.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
Change Description: no spec change
Quite contrary to the assertion above, I think making it possible for individual images to be tagged as "don't validate me" makes it far easier for authors to neglect their responsibility than using meta generator. The thing about meta generator is that authors don't want to claim that they used a tool if they didn't, as a subconscious matter of pride. However, they have no problem using an attribute whose purpose they don't really understand but with which the validator silently stops pointing out their bugs. It's exactly that kind of cargo-cult authoring that we need to address here.
Consider, for instance, an author who used to use a WYSIWYG tool, and now copies some stuff from the output of that tool to an HTML page they are writing. If we used an attribute, they wouldn't get a validator warning. However, if we trigger this based on meta generator, then they'll copy the <img> tags over and now they WILL get validator warnings. This therefore leads to a more accessible Web overall, IMHO.
The "generated example" given above is IMHO one of the worst possible outcomes we could get. The site shouldn't generate bogus alt texts. Authors won't know what "generated" means. Validators will fail to point out the problem. It's basically the worst possible outcome for accessibility.
Adding TrackerIssue keyword as this bug is part of Issue 31
A Change Proposals have been written:
The bug triage sub-team believes the HTML A11Y TF should take up this bug. Additional notes may follow in a separate comment.
The suggestion is to change the 'generated' mechanism - comes from a worry that authors will abuse it and not bother to generate alternate text for individual images when doing bulk uploads etc, and that the current spec allows them to do this. Hixie then claims that the current spec trusts that authors wouldn't abuse the current model (as a matter of pride). He does make a good point about using current 'batch' tools to push large amounts of content, that will generate validator warnings in the current spec status but wouldn't if more granular detection methods were used. To me it seems that both use cases are valid and should somehow be accommodated. Authors are used to a more granular way of working with content (such as adding alternate text to individual images) but the method of bulk uploads etc is gaining traction. Therefore both use cases should be supported.
Also are there APIs that can detect the tool being used and therefore provide a document level generator mechanism, when suitable and an element level mechanism otherwise? To me it seems that whatever is the most prevalent use case should be the default, which I suggest is the more granular method - so HTML 5 should support Element Level generator mechanism by default.
Decision to remove generator exception:
Note: Bug 9212 will continue to be marked as TrackerIssue and Issue 206 will
remain open even after this change is applied. This means that bug 9212
could conceivable be reopened once again.
...preparing to apply WG decision
Change made. Diff is viewable here: https://github.com/w3c/html/commit/151feec6e34378f13edd279a0c9f7392016dfd24
Per the change proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/Issue31cMetaGeneratorUpdated
... removes text related to the meta-generator in section 184.108.40.206 ("The value must not be used on hand-authored pages") and in section 220.127.116.11.13 ("[...] validators are required to not show an error in this case [...]")
In the spirit of this change, but not explicitly called out in the Change Proposal, I also removed the Note in section 18.104.22.168, which references that "generator" causes conformance checkers to silently ignore certain errors... and which contained the link to the list in 22.214.171.124.13 since it no longer applies after this change.
Per agreement noted below, ISSUE 206 will remain open.
*** Bug 17117 has been marked as a duplicate of this bug. ***