Warning:
This wiki has been archived and is now read-only.

ChangeProposals/Issue31cMetaGeneratorUpdated

From HTML WG Wiki
Jump to: navigation, search

Re-updated Re-open Request and Change Proposal on Meta Generator

  • The table of contents immediately follows the Summary.
  • Authors: Judy Brewer, Mike Smith
  • Contributors: Laura Carlson, Janina Sajka
  • Status: Ready for review

Summary

This change proposal:

  • provides background on prior discussions regarding meta name="generator";
  • identifies new rationales and information on why the meta generator exception is a bad idea;
  • updates recent new information regarding deficiencies in specification of the "generator" value;
  • identifies contradictions between the meta generator exception and the HTML5 design principles;
  • describes problems in weighting of evidence for and against the "generator exception";
  • provides details and describes the impact of the proposed changes.

A requirement for alternative text on images in HTML had existed for fifteen years in order to help ensure accessibility of Web content for people with disabilities. The current HTML5 specification introduces exceptions that change that requirement.

In particular, the draft specification currently uses the following language to define the "generator" value for meta name:

The value must be a free-form string that identifies one of the software packages used to generate the document. The value must not be used on hand-authored pages.

Note especially that the spec introduces the new language "the value must not be used on hand-authored pages". This change proposal (CP) argues in part that the above specification of the "generator" value is based on assumptions which are not supported by any evidence and are at odds with actual real-world authoring practices, and contains language that is ambiguous in that it leaves to speculation what is meant by the term "hand-authored". Taken together, those deficiencies greatly weaken any arguments in favor of the viability of the meta generator exception, which depends on this new definition of the generator being sound, and the assumptions behind it being sound.

As far as the part of the spec which actually states the meta generator exception, the following part of the spec introduces that, by defining conformance-checker constraints with regard to the alt attribute on the img element:

A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies:

  • The img element is in a figure element that satisfies the conditions described [in a previous section of the specification].
  • The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text — validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.)

The HTML Co-Chairs have previously issued an HTML Working Group decision in support of that exception to allow missing alt to be evaluated as conformant for any pages which include the string <meta name="generator" />. Generator is a value that is automatically inserted by a variety of types of authoring and content management tools to indicate the tools that were used in creating a page or processing content on the page; this often results in multiple generator tags being inserted into and retained in a page as it is processed through a sequence of tools.

This conformance exception for pages that contain the "generator" value for meta name exempts images on a large portion of pages on the web from an accessibility requirement that is essential to effective use of the web by users with visual impairments. This CP argues that among the reasons the meta generator exception should be removed is that trying to fix a problem by introducing a new document-global-switch is a bad idea, and that it inadvertently and retroactively introduces new, undocumented, magic semantics.

This CP also re-analyzes the Co-Chairs' previous decisions in favor of the <meta name="generator" /> exception and against the requirement for alternative text, identifying factual and logical inaccuracies. It describes the harm that is done by the generator exception, and proposes removing the generator conformance exception in order to address these problems.

This CP is currently being put forward simply as a request for the issue to be reopened so that the group can have the opportunity to consider the new information it provides. We believe it presents more than sufficient weight of new information to merit having the issue reopened so that the HTML Working Group can provide their reconsideration of the topic.

Background of "generator exception" discussion

This change proposal is an updated re-open request for a CP on the <meta name="generator"> exception for alternative text, with an extensive discussion history going back several years. Key steps have included:


Rationale

This section provides detailed rationale for the proposal to drop the meta-generator exception.

Fixing something bad by introducing a document-global switch is a Bad Idea (new)

This section provides new information that was not presented in any previous CPs.

In many years of collective experience with Web language-standards development, among the things we've learned and that are now generally accepted is that trying to fix a problem by introducing a new document-global switch is a bad idea.

Consider the precedent of quirks modes and the behavior of switching into it based on the presence or absence of a doctype and the nature of the doctype. It was a "seemed like a good idea at the time" design decision that is now universally understood to have been a serious mistake with bad consequences that author-developers and all of us are now stuck with, forever.

Introducing any new document-global switches is something that should be avoided, and something that should never be done at all unless there is prevailing agreement that it's absolutely necessary. But that is not at all the case with meta generator.

Further, the badness of this particular Bad Idea is even further compounded if it takes an already existing element and retroactively turns it into a document-global switch -- especially an element like meta generator, which previously had no effect on processing behavior in any application conformance class defined by the spec, and which previously had obvious, clearly understandable, very simple semantics. The existing spec text that makes meta generator a document-global switch has the consequence of changing its semantics in a opaque, non-obvious-to-authors way, as well as assigning it new behavioral effects in a key class of applications (validators) in a way that authors are never going to be alerted to.

"Legacy use" of meta generator is never likely to be supplanted by use conforming to the current spec text (new)

This section provides new information that was not presented in any previous CPs.

Arguments in favor of the meta-generator exception appear to assume that the current way that tools use meta generator -- due to the new constraints the spec introduces -- is going to become "legacy use". That "legacy use" argument about meta generator seems to assume that at least one of the following things is going to happen:

  • It assumes that tools which currently emit meta generator in a way that violates the current spec are going to be updated, to stop emitting it from now on.
  • It assumes that users of tools which currently emit meta generator in a way that violates the current spec are going to switch to using whatever option the tool provides for suppressing meta generator (e.g., to start using the tidy-mark=no option with Tidy).
  • It assumes that authors of what the current spec calls "hand-authored" documents that contain meta generator (e.g., because it was put into the doc by some other tool before the author switched to "hand authoring" it) will take time to manually remove the meta generator instances from their documents. This assumes that the authors are aware of this spec constraint to begin with; that is, that they are aware that the spec has redefined meta generator as a document-global switch, and retroactively assigned new magic semantics to all documents containing meta generator.

At this point, no evidence has been presented by anyone to support the assumption that any of those things is actually going to happen in practice on any kind of scale.

On the other hand, we do have evidence to suggest that most or are all of those are in fact not going to happen in practice. That evidence includes the following:

  • We know there are many widely-used tools that currently emit meta generator but which are no longer actively maintained. The non-HTML5 version of Tidy is one example; there has not been a new release of that since 2009, and there has been no active work on it since. Yet that is still the main version that most users have, and the version that's going to be the most widely used for a long time to come.

Furthermore, we have no evidence to suggest that authors are, on any kind of scale, going to start manually removing meta generator instances from their documents. It seems in fact very unlikely that they will, because without users having read the HTML5 spec, they have no way to discover the fact their documents now may all contain a document-global switch with new magic semantics that they're possibly now violating.

Consider the problem the current spec language introduces with respect to validator behavior. The purpose of the validator is to help authors find and fix errors in their documents that they otherwise would not be aware of. A key problem with the meta generator exception is that it provides no way to make authors aware of this particular spec constraint. The requirement silently changes the behavior of the validator in a way that most authors are never going to realize and never be made be aware of. The end result is that many users are no longer being alerted to a very important case of errors in their documents that they would otherwise be informed about and would fix.

A spec constraint that validators are unlikely to inform users about is fundamentally flawed. It is a spec constraint ("meta generator must not be used on hand-authored pages") that's neither possible to check programatically, nor possible for validator users to evaluate and assess on a given document in isolation from any knowledge of how it might have been authored; and the effects of the generator exception will result in confusion from the results of validation of output of legacy tools.

Inadvertently and retroactively introducing new, undocumented, magic semantics (minor update)

Update: We note that the chairs have recognized that the argument put forward in this section "is new information, as surprisingness to authors was not previously raised", which gives it weight toward re-opening of the decision The rest of the language of this section remains the same as it was in the previously submitted CP.

The effect of the generator exception is that it inadvertently assigns additional new semantics to meta generator -- magic semantics that are not clearly documented in the spec and not obvious to implementors and users of the spec. Specifically, the generator exception has the effect of making meta generator provide the new meaning, "I do not want conformance checkers to emit error messages about missing alternative text for any img elements in this document." And it unilaterally and retroactively assigns that additional meaning to all existing documents that contain meta generator, not just to newly created documents.

If I am implementing, for example, an HTML editing application based on the spec, it is not clear to me from reading the spec that having my editing application add a meta generator element means that for every single document any author creates with my application, conformance checkers are never going to emit error messages about missing alternative text for img elements.

And as a document author, it is not at all clear to me from reading the spec that if I keep a meta generator element that has been added by any tool in the production or evaluation process, anywhere in any document, it means that I am choosing to completely opt out of having conformance checkers emit any error messages about missing alternative text for any img elements in the document. Among other things, the result is a significantly reduced ability for me to identify potential errors which I otherwise would have been alerted to; I lose an important capability due to meta generator having surprise magic semantics that are not clearly inferable from the spec.

Moreover, assigning this new "do not emit error messages about missing alternative text for any img elements in this documents" meaning to meta generator results in retroactively changing the processing behavior of an entire conformance class for all existing documents that have ever been created on the Web which contain meta generator instances. That is, prior to HTML5, the meaning of meta generator in those documents was simply that it was a stamp to indicate which applications were used to create the document. But now, an additional meaning that the original creators of those documents never intended is unilaterally and retroactively being assigned to those documents, with one of the consequences being that the documents will now be handled by conformance checkers in a way that is very different from that way in which they were handled previously. In that sense, it "breaks" existing content.

The meta generator exception is therefore actively harmful and should not be part of the specification.

Fatal ambiguity in the specification (minor update)

Update: We note that a bug has been opened for this problem -- https://www.w3.org/Bugs/Public/show_bug.cgi?id=17438 -- and that the chairs have recognized that "Pointing out the ambiguity [described in this section] is a new point and arguably new information", which gives it weight toward re-opening of the decision. The rest of the language in this section remains the same as it was in the previously submitted CP.

The specification introduces the authoring-conformance constraint that a meta generator element must not be used on "hand-authored" pages. However, it does not define what a "hand-authored" page is, and the definition of that term is not obvious. That lack of a clear definition for "hand-authored" is thus a fatal ambiguity in the spec -- fatal in the sense that it entirely undermines the implicit rationale that the spec uses for excepting certain documents from the requirement to provide alternative text for images, which is based completely on the assumption of the possibility of clearly making a distinction between a supposedly "hand-authored" page and a supposedly non-"hand-authored" page.

It is not at all clear whether a "hand-authored page" is intended to mean, for example, a document that was created in a text editor without using any post-processing tools at all, or whether it can mean a page that was at some point created with an automated tool of some sort, but subsequently was edited exclusively in a text editor or other tool.

It is also worth noting -- regardless of what the ambiguous term "hand-authored" was intended to mean -- that given a document in isolation from its author, it is impossible to know whether that document was "hand-authored" or authored in some other way. So conformance-checking tools can never be expected to reliably detect whether a document was "hand-authored" or not.

Tool-mediated insertions of alternative text are ignored (minor update)

Update: We note that chairs did not address this section at all in their response to the previous CP. The rest of the language of this section remains the same.

A mistaken assumption that seems to be implicit in the current specification language regarding meta generator is that the authoring production process is binary: that a document is either generated in a completely automated fashion, or that it is completed authored by hand. That assumption does not match reality. The document production process often includes multiple steps. For instance, documents may be first generated using some kind of automated tool, or some conversion process from another format (for example, from a word-processing application such as Microsoft Word or OpenOffice, etc.); then they may be processed through intermediate stages to address layout, format, animations, etc.; then they may be validated, cleaned or repaired using various tools. Any of the tools in this production chain may add generator tags, and, once added, these tags are generally not stripped out by other tools.

At most of these stages, most types of authoring or processing tools allow tool-mediated adjusting of content. Some of these tools, such as Tidy (which adds a generator tag) allow hand-editing as well.

Steve Faulkner's change proposal provides data on a variety of tools which, as relevant evidence to establishing the range of production processes, allow tool-mediated editing of content. Some of the tools listed also allow hand-editing.

The "generator exception" obviates the intent of the Validator (updated)

Update: We note that the chairs most recent response stated that this section "presents an argument based on presumed benefits and instead of citing actual benefits". This section has now been updated in an attempt to address that response.

In an earlier response, the Co-Chairs asserted that because the "generator exception" did not assert benefits relative to the Validator, such benefits were immaterial to the decision:

Another objection argues that the generator mechanism fails to have certain benefits:

The generator mechanism does not improve user experience or the chances of accessible content being produced. It does not help authors catch mistakes. It does not help educate developers.

No one disputed this argument; but conversely, no one argued that generator has these benefits or should be allowed because of such benefits. With no concrete argument as to why the generator exception ought to have these benefits, this was taken to be a weak objection.

The W3C Validator service provides these benefits without regard to whether the generator mechanism claims such benefits. As the W3C Validator documentation states, "Validating Web documents is an important step which can dramatically help improving and ensuring their quality...". It provides a teachable moment, to whit: "Validation helps teach good practices". Additional information is available at HTML5 Should Help Facilitate Accessibility Awareness and Education.

In the presence of the generator exception, the validator suppresses error identification, and is thereby stripped of its educative benefits. If content developers are not aware that a problem (missing alternative text) exists, they are not notified about it, nor do they have the opportunity to rectify specific instances of missing alternative text. They are therefore deprived of the opportunity to learn about the general issue, and deprived of the opportunity to improve their content in the future.

So while the survey comments specifically raised the question of generator benefits, by extension they also raise the important question of Validator benefits, and how not to inadvertently undermine them.

Regardless, the problem with the effect of the meta generator exception on validator behavior is not really about presumed benefits. The problem is that it is detrimental because it reduces the ability of authors to find and fix errors in their documents that they otherwise would not be aware of (the fundamental purpose of the validator) -- because it defines a new document conformance requirement that the validator has no way to make authors aware of, with the result being that many users of the validator are no longer being alerted to errors in their documents that they would otherwise be informed about and would fix. Validator users are not benefitted when the validator fails to inform them about errors in their documents that violate document-conformance constraints in the specification.

The issue of the meta generator exception being detrimental for users of the validator should have been evaluated as a strong objection, rather than a weak argument.

The "generator exception" results in inequitable rendering of graphical content (updated)

Update: We note that the chairs have recognized that the argument put forward in this section "represents a notable improvement" and that it is "likely not a point that is in dispute," however, that the HTML Co-Chairs seek additional evidence. Please note updated discussion below.

In their April 2011 decision, the HTML Co-Chairs incorrectly asserted that arguments regarding structural integrity against the generator exception were circular and gave these no weight:

Another objection was that the generator exemption breaks the structure of the img element:

Requiring a set of programmatically determinable valid options helps ensure that images have complete structure. Complete structure of the <img> element requires both src and text alternatives.

This claim seems to be based on a circular argument. Omitting alt should not be allowed, because that would make the img element have incomplete structure, because img requires alt. Thus, the objection fails to make its case and was given no weight.

This argument is not circular. For web content to be independent of presentation, both the src attribute and the alt attribute are necessary for images.

  • Omit the src attribute, and sighted users have no content;
  • Omit text alternatives, and non-sighted users have no content.

For a sighted user, if there is no src element, then no content is rendered, and therefore it is a document error. For a blind user, if no content is rendered, then there is likewise a document error; without alt content, the img element is not representing anything to that user. It is inequitable for a document to represent something to a sighted user but not to a non-sighted user.

Without both a src attribute and a text alternative the img element is incomplete, as further discussed in Laura Carlson's change proposal on conformance checking.

The most recent HTML Co-Chairs' response on this point acknowledges a notable improvement in this rationale:

This replaces prior statement of "complete structure" and represents a notable improvement; that being said this is (a) merely an assertion provided without evidence (citing the actual problems caused with existing tools would be helpful), and (b) likely is not a point that is in dispute.

Regardless of whether a point is in dispute or not, if there is a notable improvement in a rationale, it seems appropriate to consider that as relevant information for this re-open request, so that the working group may have the opportunity to consider this rationale.

As to the request for evidence, such as problems with existing tools, there appears to be a misunderstanding. We have not raised concerns regarding tool behavior; the concern we raised is with regard to equitability of presentation of web content for users with disabilities who require different modes of presentation.

This is a rationale with regard to principle, not tool behavior.

The argument against the "generator exception," regarding structural integrity of the <img> element, should have been evaluated as a strong objection rather than to have been given no weight.

The "generator exception" breaks harmonization with other standards and guidelines (updated)

In their decision, the Co-Chairs suggested that the disharmonization with standards and guidelines introduced by an HTML5 "generator" exception is a failure of other standards and guidelines to update, and therefore they weighted this objection to the generator exception low:

Yet another objection was based on standards and guidelines:

The generator mechanism breaks standards and guidelines requiring text equivalents on an individual element basis.

Many specific standards and guidelines were listed. However, these guidelines were generally created before the generator mechanism exemption was invented, so it's not clear if the disagreement indicates a problem, or just failure to update. Thus, this was taken to be a weak objection.

This disagreement indicates a problem that cannot be solved as the HTML Co-Chairs seem to suggest by updating numerous other standards and guidelines, but that must rather be solved by removing the "generator" exception in HTML5 that has introduced this disharmonization.

The problem introduced by the "generator" exception is major with regard to standards harmonization, in that accessibility standards require alternative text for images, but the "generator" exception makes this requirement meaningless on the large number of web pages that have a "generator" tag inserted. In exempting a large percentage of pages on the web from the requirement to provide alternative text for images, people with visual disabilities are not provided equitable access to web content--equitable access that could have readily been provided by following the provisions of these standards and guidelines.

The date that the guidelines and standards were created--whether before, during or after creation of the generator exemption--has no bearing on the validity of the user requirement for alt, as had been suggested by the HTML Co-Chairs. User needs for alternative text as captured in provisions of web standards and guidelines do not somehow become irrelevant because of a standard that does not follow the provisions of existing standards and guidelines. The existence of people with visual disabilities, and the need to accommodate them on the web, have not disappeared in the intervening years, and it is in order to address these user needs for alternative text for images on the web that provisions for alternative text exist in the Web Content Accessibility Guidelines (WCAG) 2.0 and other accessibility standards.

This assertion also presumes that other accessibility standards and guidelines would now agree with the generator exception, though the opposite is a far more likely conclusion; other standard developers are well aware of automated authoring tools, and simply do not agree that alt is unnecessary or expendable when a tool is involved, and therefore accommodate the need for provision of alternative text. Again contrary to the HTML Co-Chairs' assertions above, content management systems (CMS) existed long before the completion of accessibility guidelines, including WCAG 2.0, containing provisions for alternative text. The HTML Co-Chairs are mistaken in their assumption that these standards did not consider the implications of CMS. Additionally, even accessibility guidelines and standards currently under development continue to recognize the need for and utility of alternative text in order to address accessibility requirements for web users with visual impairments.

To suggest that the problem of standards breakage (standards fragmentation), resulting from the generator exception, is a failure of standards and guidelines to update is to suggest that users' needs are shaped by a technical standard rather than vice versa. People with different disabilities experience a wide range of functional requirements which are highly addressable in a digital environment such as the web. The means to addressing these functional requirements are by specification of accessibility provisions such as alternative text for images. Exempting the great extent of web content from conformance-checking for alternative text, just because that content happens to include a generator tag put there as an authoring tool product mark, does indeed create standards harmonization because it would mean that documents created with HTML5 could no longer be validated in a way that would indicate whether they conformed to WCAG 2.0, another W3C specification.

The most recent HTML Co-Chairs' response on this point reflects several continuing points of confusion:

If there is evidence on which the other standards have been based that needs to be brought forward, then do so. Simply citing a difference and making an assertion as to which is in error is not sufficient. Also from the original decision: + it's clear that there are tools which do not follow ATAG in this respect, and no evidence was provided that this would change.

The primary standard which the generator exception is creating disharmonization with is the Web Content Accessibility Guidelines (WCAG) 2.0, which establishes the user requirement for alternative text. By nullifying the requirement for alternative text on a large category of web pages, the draft HTML5 specification interferes with the ability of authors to conform to WCAG 2.0. It does so by preventing validators from ascertaining whether alternative text has been provided on any page that happens to create a generator tag -- which, over time, will become the majority of pages on the web.

WCAG 2.0 is already required for public websites in many countries, and will be increasingly over time. If web content cannot be validated for appropriate presence of alternative text for images, it would not be possible to reliably demonstrate that HTML5 content conforms to WCAG 2.0 with regard to one of the most basic user requirements encoded in accessibility standards.

The relevant evidence regarding the need for alternative text on which accessibility standards are based is that there still are and will continue to be web users who are blind and partially-sighted, and who need to know what is in the images in web content, regardless of whether there's a generator tag somewhere in the page that they are using. Contrary to the HTML Co-Chairs' assertion, this isn't an assertion that this or that standard is wrong; it's based on an understanding that different standards have different scopes, and that the scope of an accessibility standard is to describe what is necessary for the technology covered by that standard to be accessible.

Whether or not there are any authoring tools that do not conform to ATAG 2.0, a draft specification that is not even a Recommendation, is irrelevant to the user requirements represented in WCAG 2.0; there remains a consistent end-user need for availability of alternative text in web content.

The argument against the <meta name="generator"> exception, regarding failure to harmonize with standards and guidelines, should have been evaluated as a very strong rather than a weak objection.

The "generator exception" inappropriately gives authoring tool conformance considerations precedence over end-user requirements (updated)

In their decision, the Co-Chairs asserted multiple rationales for retaining the generator exception based on the inconvenience that might otherwise result for authoring tool conformance:

At least one Change Proposal argued that when a page is created by an automated content generation tool, and that tool indicates this using <meta name=generator>, it should be permitted to omit the alt attribute.

It was argued that there was a valid use case for the generator exemption, namely automated content generators which cannot produce alt themselves and for various reasons cannot or will not demand alt from the user. The following objection, though entered for role=presentation, directly argues one such use case:

Consider a GUI authoring tool used by end-users, not professional Web developers or content authors. Such tools generate <img> elements, but it is not always appropriate for such tools to pause and demand alt text from the user before continuing.

Whether or not authoring tools prompt for alternative text at any given stage of document production process is immaterial. Even authoring tools that fail to prompt for missing alternative text nevertheless may permit the introduction of alternative text for images, or else can be used with other production tools that do provide that capability; so content authors are not prevented from creating appropriate alternative text. And even the Authoring Tool Accessibility Guidelines (ATAG), which address support for production of accessible content, do not recommend intrusive prompting. But regardless, whether or not an author was prompted for alt does not change the fact that the end-user requires it, and that the generator exception will interfere with determining whether of not the resulting document contains it.

Several objectors cited this use case, and further pointed out that if content generators are forced to generate nonconforming markup to satisfy this use case, they may instead enter bogus alt values, which would merely exacerbate the problem:

If an authoring tool or other generator does not have sufficient information to include either alternative text or a caption, there is nothing the tool can do. If we say that in those cases the authoring tool would be non-conforming if it didn't provide alternative text or a caption, then the tool will just provide bogus (placebo) alt="" attribute values, which just makes the problem non-machine-detectable instead. To address this, therefore, we should allow generator tools to include images without alternative text or captions if absolutely necessary.

Also:

I object to treating the absence of the alt attribute as a validation error when the generator mechanism is used, because if it is treated as an error in that case, generator developers are incented to generate bogus values in order to make their products emit markup that doesn't trigger errors. (There are always generator developers who want to make the output of their programs validate.)

The use case of GUI tools that do not prompt for alt seems well established.

While there may indeed may be authors who irresponsibly choose to enter bogus alternative text, knowingly violating the intended use of alternative text as an accessibility accommodation, this is not a reason to codify their bad practices by removing validation alerts for missing alternative text for content authors who would prefer to do the right thing and provide alternative text for images. Nor is this assertion even evidence-backed, as the Co-Chairs acknowledge in their most recent rejection of re-open requests of this issue...

the claim of negative consequences to disallowing this use case was somewhat weakened by the lack of concrete evidence that bogus values have been used in the past or would be used in the future"

...which acknowledged that no concrete evidence has been presented that bogus values had or would be used.

The lines of reasoning included here imply that considerations of authoring tool conformance should take precedence over end-user requirements for accessible web content. Given that alternative text is essential to understanding graphical web content for some web users, the proposed justification for the omission of alternative text based on conformance convenience for authoring tools, and validation convenience for content authors, is an inadequate counter-consideration to the needs of end-users for accessible content.

After examining a variety of arguments regarding the convenience of the generator exception for assessing conformance of authoring tools, without consideration of the experience of the end-users who require alt as an accessibility accommodation for graphical web content, the HTML Co-Chairs asserted that:

After considering all these arguments, it seems established that there is a valid use case for allowing the alt attribute to be omitted when the generator mechanism is specified. This use case makes for a moderately strong objection. However, the claim of negative consequences to disallowing this use case was somewhat weakened by the lack of concrete evidence that bogus values have been used in the past or would be used in the future. So overall, this makes for a medium objection.

Given multiple problems with the arguments above, the omission of alternative text in the presence of one or more generator tags has by no means been established as a valid case.

Regardless, to give it weight over end-user and author requirements is contrary to the Priority of Constituencies principle in the HTML5 Design Principles, which states:

3.2 Priority of Constituencies: In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

These objections to the removal of the generator exception should have been no weight, when juxtaposed with the end-user requirements to have alternative text for images, and authors inconvenience caused by conformance-checking for production of accessible content that is interrupted by the presence of a generator tag.

Harmful consequences of the generator exception include harm to web authors and to web content users with disabilities (updated)

In their decision, the Co-Chairs mentioned survey comments that asserted harm from the omission of alt:

Some argued that omitting alt and using the generator mechanism had harmful consequences:

Hence, the generator mechanism should not have any bearing on the @alt requirements as the generator string/mechanism has no bearing on the attributes of the <img> or the context in which the img appears in. The negative effects of omission of an empty or non-empty @alt are in no way made up for by the presence of the generator mechanism.

This statement in itself lacks specifics...

The HTML Co-Chairs asserted that this statement lacks specifics. Breaking the statement down into specifics, this means that the harmful impact of missing alt, for web users who have visual impairments, is in no way made up for by the speculative benefit to authoring tools by the generator exception. When people with disabilities encounter accessibility barriers on websites, they may be unable to carry out essential activities in their lives, such as pursuing education, employment, health care, recreation, and so forth. When web content that omitted alternative texts doesn't trigger conformance errors because there was a generator tag on the page, this does nothing to fulfill the function that alternative text would have. Requirements for alternative text for accessibility support, and convenience of error-free conformance reports if the generator exception is sustained, are not tradeable one for the other. The presence of generator tags in web content does not provide a functional replacement for information about images that should have been provided by alternative text; neither does the presence of generator tags in web content serve as a replacement for sight.

To put this another way, in the Web Content Accessibility Guidelines (WCAG) 2.0, Guideline 1.1 is...

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language

and explained in the "Intent" section of Understanding WCAG 2.0 Guideline 1.1...

The purpose of this guideline is to ensure that all non-text content is also available in text. "Text" refers to electronic text, not an image of text. Electronic text has the unique advantage that it is presentation neutral. That is, it can be rendered visually, auditorily, tactilely, or by any combination. As a result, information rendered in electronic text can be presented in whatever form best meets the needs of the user. It can also be easily enlarged, spoken aloud so that it is easier for people with reading disabilities to understand, or rendered in whatever tactile form best meets the needs of a user.

The specifics for the statement about harm quoted above are that the presence of the generator tag in web content does not make up for what alternative text would have provided to a web user who is blind.

The HTML Co-Chairs also asserted that lists of authoring tools inserting the generator tag had no evidentiary value, dismissing the notion that a significant amount of web content would use the generator exception:

A list was provided of example <meta name=generator> values, and from this a conclusion was drawn that a tremendous amount of Web content would make use of the generator exemption. However, it's not clear where this list came from. It is not present in the spec, and does not seem to align with the spec's definition of a content generator. In particular, it includes many text editors which do not seem to qualify as automated markup generators. Was this list derived from the output of actual authoring tools? Was it found by looking at real Web content? In the absence of information about where this list came from, it was taken to have no evidentiary value.

The generator exception does not differentiate between content generators and authoring tools that insert a generator string. Authors of all documents with a <meta name=generator> string would remain ignorant that their document had any missing text alternatives. The HTML Co-Chairs were mistaken to disqualify the original evidence. It was derived from searching and from examining tools that automatically insert a meta generator string and their resulting content. Since this initial evidence was provided, a copious amount of further evidence of widespread use has been provided.

Other generator studies seem to indicate further usage of <meta name=generator>.

The HTML Co-Chairs also dismissed objections that a document-level generator option would make it easy for authors to forget to provide alternative text for images:

...but there were some concrete arguments supporting the case for negative consequences:

The generator mechanism facilitates the creation of inaccessible content.

No evidence was provided that more inaccessible content would be created if the generator exemption is allowed than otherwise. So this was taken to be a weak objection.

And, in a related argument, they rated an objection to the generator exception as moderately weak on the basis that there should have been sufficient time already for expanded evidence of harm from missing alt -- though it is unclear which authoring tools and validators, if any have already built in a generator exception for alternative text, and no time to accumulate statistical evidence of this presumed expanded harm.

Another objection was based on the possibility of authoring mistakes:

The generator mechanism is actively harmful to accessibility. If the generator option is left at document level, it would be far too easy for authors to have the software automatically insert "generator" and then forget to provide any text alternatives for images.

If supported by concrete evidence, this would have been a strong objection. This seems like a plausible authoring mistake which would have negative consequences. But it was weakened by lack of any specific evidence that this problem has actually occurred in practice. This provision has been in HTML WG Editor's Drafts and Working Drafts since September 3, 2009:

http://dev.w3.org/cvsweb/html5/spec/Overview.html?rev=1.2915

This should be enough time to see at least anecdotal evidence of the claimed problem. Even though normally lack of supporting evidence would render an objection weak, in this case, there is a plausible-sounding argument even in the absence of evidence, so the objection based on authoring mistakes is overall taken as moderately weak.

The HTML Co-Chairs appear to be arguing on the one hand that the generator mechanism is in sufficient use to merit an exception, while on the other hand dismissing objections to the generator exception by claiming that insufficient evidence was provided that the generator mechanism is in use. These arguments are contradictory.

The HTML Co-Chairs also appear to be arguing on the one hand that content authors would be bothered by validation failures in the event of missing alt, while on the other hand claiming insufficient evidence that the generator exception would undermine the creation of accessible content. These two arguments are especially contradictory.

Shawn Henry provides additional descriptions of how the generator exception will harm both authors and users:

In my role as WAI Education and Outreach Coordinator and previous roles of accessibility specialist and usability specialist, I have evaluated the accessibility of web content, performed usability studies with web content authors, and trained people how to make accessible web content for nearly 20 years. Missing alternative text is one of the most common web accessibility errors.

From usability studies of content authors, I have observed two key reasons for missing alt text: 1. the nature of web content prototyping, and 2. content authors using authoring tools without knowing markup. When designers and developers are creating prototypes, they often skip alt text, because the focus is on other aspects of the prototype and they expect to add it later. However, adding alt text is often missed in later development.

The other situation is people who are not markup-savvy, and often not accessibility-savvy, who are updating content using authoring tools. Unless the tool requires them to add alternative text, most will skip it.

In both cases, authoring tools need to require alt text, and support authors in providing appropriate alt text. If generator-tagged web content is exempted from checking for alt text, the tools that people rely on to create standards-compliant content will be useless in providing this support. The result will be less accessible content and more accessibility barriers for people who are blind and others who rely on alt text.

This evidence from usability observations of the workflow involving delayed alt-insertions following web content prototyping, and updating of web content by non-savvy web users who tend not to provide alternative text unless required, shows that the generator exception would reduce creation of alternative text by authors, increasing accessibility barriers for users.

These objections regarding harm to end-users with disabilities should have been evaluated as strong, not weak, objections to the generator exception, as they speak to the core issue of unmet user requirements resulting from exempting pages containing "generator" from the requirement to provide alternative text.

The weighting of objections against the "generator exception" is opaque (updated)

In the HTML Co-Chairs' April 2011 compound decision on Issue 31 and 80, they asserted that individual objections to the "generator" exception, on the whole, drew weaker objections than would removing the exception:

Overall, there were many claimed disadvantages that flow from the generator exception, ranging from weak to moderately weak. They were generally unsupported by details or concrete evidence. Even though the use case for omitting alt when the generator mechanism is used was disputed and only found to be a medium objection, it still outweighs these claimed disadvantages, as they were all found to be weak or moderately weak.

Thus, on the whole, the proposal to allow alt to be omitted when the generator mechanism is used was found to draw weaker objections, compared to the proposal to still require alt, even when the generator mechanism is used.

Within the "generator" portion of the HTML Co-Chairs' April 2011 compound decision on issues pertaining to alternative text, the Co-Chairs used six different levels of "weights" in evaluating the objections gathered in the survey: "strong," "moderately strong," "medium," "moderately weak," "weak," and "zero." These were presented without any definitions.

Further complicating the rating scheme, these levels were applied bidirectionally -- they were on the one hand applied to objections to the generator exception, and on the other hand, to objections to removing the generator exception, thus totaling twelve possible rankings for any argument, all without definition.

No point values were declared for any of the levels used in the decision, with the exception of "zero," making the individual weightings, as well as the aggregate scoring, unverifiable independently.

The opaque rating scheme made it difficult for interested stakeholders to follow, let alone to contest, the HTML Co-Chairs' rationale in maintaining the generator exception. It is difficult to accept the uniformly low weighting that was assigned to these numerous objections. Relevant arguments from the April 2011 decision were re-examined above, along with the weighting of those arguments, and have since been updated.

Details

Change [1], at 4.2.5.1

Remove:

The value must not be used on hand-authored pages.

Change [2] at 4.8.1.1.13

Remove:

The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text - validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.)

Impact

Positive Effects

  • Authors can more safely assume that when they use a validator it will appropriately check the conformance of the document, rather than some arbitrary subset of requirements.
  • The use of meta name=generator will not change in a way that is contrary to its current usage and effects.
  • Authors will be made aware that they have not provided a text alternative giving them the opportunity to fix their error and produce a conforming document.
  • Upholds the structural integrity of <img> element.
  • Enables automatic validators to programmatically detect occurrences of the presence or absence of text alternatives. Bug 9218.
  • Facilitates accessibility awareness and education.
  • Upholds the HTML section 3.2. "Priority of Constituencies" Design Principle.

Negative Effects

  • None

Conformance Class Changes

  • The meta generator exception is removed from section 4.8.1.1.13 Guidance for conformance checkers. (Refer to Change [2] in the Details section of this document.)

Risks

  1. There are no risks in doing the changes.
  2. Risks to not doing the changes include:
    1. unmet user requirements, in that individuals who have visual impairments or other needs for alternative text will not have equitable access to web content;
    2. HTML5 conformance evaluation for <meta name="generator"> will assert false conditions on authoring tool production processes;
    3. The HTML5 spec will be ambiguous with regard to the hand-authoring test for alternative text in the presence of the "generator" tag.
Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/Issue31cMetaGeneratorUpdated&oldid=13134"