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

Hi Leif,

Just to be clear - is your intent to raise a formal objection, or to enter a request to reopen the issue? I'm asking because you used the phrase "formally object", but I see that you mentioned many new points of information, including direct responses to some of the types of new information mentioned in the decision under "Revisiting this Issue". Please clarify, and I'll make sure it gets recorded properly.

Regards,
Maciej

On Apr 18, 2011, at 11:53 PM, Leif Halvard Silli wrote:

> Maciej, and the other chairs,
> 
> I formally object to the generator exception as it stands.
> 
> 		Reasons for objecting:
> 
> - It is questionable whether the Decision takes in what the no-change 
> solution opted for. The very decision states: ]]The presence of <meta 
> name=generator> makes missing alt conforming.[[ Whereas the no-change 
> proposal, represented by the spec itself, states: ]] This case does not 
> represent a case where the document is conforming[[. These statements 
> contradicts each others.
> 
> - the Decision accepts as facts claims about the great user problems of 
> providing repeated/redundant alternative text. Clearly those are 
> problems, but needs to be dealt with in more detail. (I have observed 
> that VoiceOver repeat text even when there is no text to repeat, so 
> clearly repeating text is not always a problem for AT users.)
> 
> - the Decision does not count in ARIA, which in many cases can solve 
> the problems of repeated/redundant text. (There is not a single mention 
> of ARIA in the Decision's section on "generator" mechanism - see full 
> quote below.)
> 
> - the authoring generator developers' willingness to produce "placebo" 
> seems taken out of the air. If this was such a big problem as is 
> claimed, then we would have seen much more of it than we see. In fact, 
> it is a weakness in the Decision that it doesn't cite any documentation 
> for this claim. Were are those tools with those bogus values? (Note 
> again that we should measure against HTML5: HTML4's @alt requirements 
> are more simplistic and thus more prone to placebo authoring that those 
> of HTML5.)
> 
> - The Decision states that 'The use case of GUI tools that do not 
> prompt for alt seems well established'. It would be useful to know more 
> about concrete tools which behave like that rather than a mere "seems 
> well established". Which are they and how common are they, these tools?
> 
> - it is as an exception that in practise removes all alt requirements.
> 
> - it is an exception that takes as stating point that it is *always* 
> better to do nothing than to do too much. 
> 
> - HTML5 provides at least one, machine checkable use case where the 
> empty alt isn't conforming: when the img is the sole content of an 
> anchor element. And the removal of the empty alt does, in that case, 
> not make it any more conforming, since the presence of alt text in that 
> case is defined as a must. AT cannot ignore the link just because there 
> is a image with the empty alt inside. So why does the generator 
> exception also cover that case? Or what about <img role=presentation 
> src=* >: forbidden. But permitted, still, as long as the page has the 
> generator string?! (I could be wrong on this, but there is nothing that 
> states that it isn't so.)
> 
> - the quality control issue: The validation service users must be 
> provided info about the very fact that the page is validated according 
> to a less-than-state-of-the-art version of HTML. Note that even one of 
> the Decision's sited objections in support of the generator exception 
> alluded to this: "(or at least phrase the error in a way to indicate 
> that the authoring tool is not to blame)." [the Decision gives the 
> impression that this supports the *not* having the exception, however 
> this must be a typo or a misreading from the chairs]
> 
> - we could have something like a generator exception, but then it 
> should be acknowledged, visible and clear. We can have 
> versioned/2-level HTML, but then it should be explicit.
> 
> - this is, in fact, a form of secret (to the users) versioning of 
> HTML5. We have abandoned versioning.
> 
> - When the img is the sole content of a link, then VoiceOver does use 
> the @title attribute as link text - but it also reads the URL. THus is 
> reads both URL and @title. It is only when the @alt attribute is 
> non-empty that VoiceOver only reads the @alt. This is an argument 
> against that presence of @title should always make a img conforming. 
> 
> - according to other parts of HTML5, the lack of @alt is supposed to be 
> a signal that the image is important content. E.g. <img> inside a 
> <figure> is one such example. The generator exception puts that under 
> doubt as it e.g. means that the author gets no info about whether the 
> image has a useful label - of any kind - or not. (E.g. sometimes the 
> @alt *should* be empty, to avoid that UAs try to repair the lack of 
> @alt and because the image is presentational.)
> 
> - there seems to be a underlying thinking here that being told about 
> errors has harmed the web. this assumption should be backed up. 
> Mechanical thinking certainly can harm the Web.
> 
> - it has heavy taste of "consumer html" versus "pro html". 
> 
> - unjust competition: unless "consumer html" is clearly stamped as 
> getting "consumer validation", then it will lead to unjust competition 
> between those that opt for "pro" versus those that opt for "consumer" 
> html.
> 
> - less of competition: the generator exception, as long as there is no 
> requirement to signal that the page is validated to a lower standard, 
> stifles authoring tool vendors competition. Tool vendors should compete 
> about the best and most intuitive implementation of hard demands.
> 
> - the decision assumes that the problem always is one the author's 
> side. Well, it isn't. Word processors generates HTML. But few of them 
> support the concept of alt text. This is not author's fault.
> 
> - Tying lower validation bar to generator identification string seems 
> like a bad strategy - it should be two orthogonal issues.
> 
> - unsubstantiated claims about the need for the exception. On whose 
> behalf is these exception asked for?
> 
> - Web developers who create CMS-solutions for others, will insert 
> "generator" in their tools - as long as they know about that 
> opportunity (and they will learn ...).
> 
> - this decision assumes that demand for being stamped as "valid" will 
> increase compared with status today. Or why else increase the 
> opportunity to become valid? Is that the case? I thought that many in 
> HTML5 was critical of the "validate, validate, validate" slogans. This 
> decision must assume that the slogan will continue to carry weight. 
> (Either that, or it assumes that validity is so unimportant that it 
> doesn't need to be taken very seriously.)
> 
> Specific comments to selected parts of the Decision:
> 
>>>    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.
> 
> The structure of the img element was decided in the verbiage survey, 
> and it does indeed not operate with a generator exception:
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0452
> The claim about circular thinking seems like cliche thinking: having 
> clear rules means that the author knows what bar to meet. The generator 
> exception, because it is not a demand in HTML5 that validation service 
> users must be told about the lower bar, this will cause authors to 
> think that he/she has met the state-of-the-art validation bar. 
> 
> It has been said that the validator should be a authoring tool. Well, 
> it fails to be a authoring tool if there is an generator exception (as 
> long as the author can't opt out of the exception or at least be made 
> aware of it.)
> 
>>>    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.
> 
> Here the chairs argue against better knowledge: the Decision cites many 
> claims that the lack of the generator exception would cause a lot of 
> bad things: insertion of placebo alts et cetera. 
> 
> (That said, a kind of generator exception *could* perhaps improve 
> things if it weren't a silent validation issue but a explicit lower-bar 
> validation thing.)
> 
>>> A list was provided of example <meta generator> values, and from this
>>> a conclusion was drawn that a tremendous amount of Web content would
>>> make use of the generator exemption.
> 
> What does 'make use of' mean? Make use of for identification? Or for 
> validation? Tying lower validation bar to generator identification 
> string seems like a bad strategy - they should be orthogonal issues. 
> Usually the generator string has been perceived as a kind of PR by 
> which the vendor can signal "look what tool that generated this 
> exceptional page!". But this decision turns the generator string into a 
> feature with the following message: "sorry, but our tool is bad - it is 
> just a generator - we are validated according to a lower bar". 
> 
>>> 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.
> 
> It is unclear where the chair finds this clear definition in HTML5. 
> Spec says this about the generator string represents: "string that 
> identifies one of the software packages used to generate the document. 
> This value must not be used on hand-authored pages."
> 
> What is the definition of a hand-authored page? When I tweak my 
> generated page by hand, does it then become hand authored? Should I 
> then remove the generator string? Do I even, as a hand author, remember 
> to think of the fact that there is a "generator" string? Why doesn't 
> MediaWIKI constitute hand authored pages? After all, we edit them by 
> hand, them wiki pages? 
> 
> Till now there has been no rules for the use of the generator string. 
> Hardly anyone has perceived it as anything but a kind of PR for the 
> authoring tool.
> 
> Why, btw, should I as a hand author have higher requirements? Are all 
> hand authors professionals? Or is it, perhaps, the goal to make hand 
> authors give up an use a vendor made generator tools instead?
> 
>>> 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 list is much longer than the one Laura provided: Wordpress, 
> MediaWiki, Drupal, DocBook, TextPattern. TextMate, the famous Mac text 
> editor, is also able to save code as HTML - thus it generates, does it 
> therefore need an exception? TextMate also has various WYSWIWYG (like) 
> extension(s). SubEthaEdit can also save page as HTML. Other text 
> editors probably have similar features. Have these tools asked for 
> lower bars? Can't they speak for themselves if they need them? Does 
> JDiff, which also inserts generator string, need an exception?
> 
> The irony, considering the lowered validation bar: <meta 
> name="generator" content="HTML tidy">
> 
> All the above info has been found with http://code.Google.com and by 
> looking at the home pages of the different packaged and through 
> knowledge of the tools. It is simple to find more.
> 
>>> 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.
> 
> The fact that the generator mechanism is a blank permission to break 
> any rule that the spec otherwise has, is such a concrete evidence. E.g. 
> that it makes it permitted to not provide @alt text even if the image 
> is the sole content of a link. And even if the image has 
> role=presentation.
> 
>>> 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
> 
> It has also been disputed for as long, or longer.
> 
>>> This should be enough time to see at least anecdotal evidence of the
>>> claimed problem.
> 
> While a somewhat fair point, ARIA has only been in the spec for a short 
> time. And this issue is much affected by ARIA: aria-hidden="true" can 
> be used to get rid of the duplication problem that this issue is 
> supposed to solve. Also, the generator exception seems to make it 
> permitted have no alt together with role=presentation. THere were  ARIA 
> in the spec when the exception was specced.
> 
>>> 
>>>    The only benefit is that most tool vendors will automatically
>>>    adhere to HTML5, as very few adhere to existing standards. The
>>>    exception is a way to codify and bless bad tools.
>>> 
>>> No evidence was provided that the other claimed benefits
>>> (e.g. avoiding the creation of perverse incentives to include bogus
>>> alt) would not materialize, thus, this claim based on "the only
>>> benefit" was taken as a weak objection.
> 
> It isn't even clear that these tools want these "benefits".
> 
>>> * Examples of authors mistakenly or deliberately omitting alt when
>>>  they might have otherwise, due to the generator mechanism exception.
> 
> It is not possible to test this today. There are no validator that 
> implements this, AFAICT. 
> 
> But one piece of evidence immediately popped up: Aryeh at once came up 
> with a MediaWiki example as example of need for the exception. 
> http://www.w3.org/mid/BANLkTi=_yMhSQRfoeQi7vXGeNRSYK_p1Mw@mail.gmail.com
> 
> However, contrary to what Aryeh thought, when evaluating the issue, 
> HTML5 says that alt text is a must - as os there is no generator 
> string. HTML5 describes how MediaWiki could automatically handle it - 
> but the generator exception makes it valid without that, so why try? 
> HTML5 offers ARIA (e.g. aria-hidden) which could be used so solve the 
> redundancy problems that is said to have been the cause of MediaWiki's 
> current solution - but instead, big Wikipedia gets an exception because 
> it use the generator string. Clearly, this is is not much incentive to 
> improvement.
> 
> If HTML5 defines more sensible rules for @alt text - such as it is 
> often claimed, then why introduce a string by which authors/generators 
> - unknowingly - can just go free from the sensible new rules?
> 
> Many generators are quite specialized. Perhaps they output standardized 
> pages were images wrapped in a link are used as buttons. E.g. 
> GraphicConverter, a well known graphic tool for mac creates image 
> albums that way. Does it need an exception, just because it uses the 
> generator string? Many generator vendors are small. For many of the 
> generator vendors, generating HTML is just a side product. They are 
> hardly more HTML savvy than many of their customers.  GraphicConvert 
> can pick alt content etc from the meta layers (xmp etc) of images. This 
> is the *opposite* of skimping on alternative text. If I validate such a 
> page, I won't be told of the errors, because GraphicConvert inserts the 
> generator string.
> 
> The generator exception takes as assumption that all the error stems 
> from the author. But clearly, this i not the case. A word processor 
> that doesn't give option to provide alt text for images does not 
> generate @alt text when spitting the image out. Whose fault is this? As 
> long as the word processor doesn't provide the option, then it i snot 
> the author's fault. Today there are very clear differences in quality 
> with regard to HTML output from word processors. Some live and breath 
> HTML more than others.
> 
>>> * Evidence that a great number of authoring tools are making wide use
>>>  of the generator exemption, and that this interferes with proper
>>>  inclusion of alt. (A list of possible generator values was provided
>>>  in a Change Proposal, but there was no explanation of where it came
>>>  from. Testing of content generators or direct statements of intent
>>>  from implementors would provide sufficient evidence.)
> 
> * The list asked for here is simple to provide. (See above, for a 
> start.)
> * What kind of test of content generators is it meant? Should we test 
> the content generators - after having removed the generator string 
> first - in a yet to be written validator, and see if it meets the bar? 
> * What kind of intent from content generator is it meant? Who is going 
> to become the missionary which tells these generator developers about 
> this two-levels validation thing, in the first place? Should we ask for 
> confirmation that they, the toolmakers, will check their pages 
> *without* the generator string, before they send them tools to us, 
> their uses. Only _then_ will they add the generator string? Should we 
> also ask them if they will make sure that we, the authors, can easily 
> remove the information about the generator, if we want meet higher 
> validation bars? What about competition between Web developers - some 
> which will use the generator while other won't, and they all validate 
> the same? My clients are satisfied because I made a generator for them 
> with this string inside, while the other developer's clients curse 
> their web developer because their pages do  not validate?
> 
> THe issue should be turned the other way: show use those "generator 
> developers" which have asked for this exception.
> 
> IN short: but for the list of existing generator strings, this is not a 
> realistic example of evidence. When it comes to UA vendors, yes, 
> unfortunately, there are only very few that really matters - literally 
> (inside HTMLwg). But in the authoring tool business, there are no clear 
> vendors to ask. Very few authoring tool vendors have in fact spoken in 
> the poll. Most of the arguments about the trouble of not having the 
> exception, have come from persons who, on behalf of others, claim there 
> are problems. Usually, the chairs do not give much weight to second 
> hand claims.
> 
>>> * A demonstrated trend towards more authoring tools fully supporting
>>>  ATAG2, including the requirement to prompt for textual equivalents
>>>  for images.
> 
> Perhaps the chairs, who in this decision claim to know what HTML5's 
> definition of "generator" (not) is, provide us with the tools to check?
> 
> End of formal objection.
> 
> Leif Halvard Silli
> 
> 
> 
> Maciej Stachowiak, Mon, 18 Apr 2011 13:33:00 -0700:
> 
> [ the generator exception part of the decion: ]
> 
>> == Should it be permitted to omit alt when the generator mechanism is 
>> present? ==
>> 
>> 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. 
>> 
>> 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. 
>> 
>> Some disputed the validity of the use case. For example, it was argued
>> that:
>> 
>>    Application developers should follow ATAG http://www.w3.org/TR/ATAG20/ 
>> 
>> However, it's clear that there are tools which do not follow ATAG in
>> this respect, and no evidence was provided that this would change.
>> 
>> A more detailed form of this argument was also made:
>> 
>>    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.
>> 
>> This argument is based on what tools *should* do, but in practice
>> often don't. Since no evidence was provided that common practice is
>> changing, this was taken to be a weak objection.
>> 
>> Another commenter makes the case more explicitly:
>> 
>>    Unfortunately, despite what the specification says, users will
>>    consider an authoring tool non-conforming (buggy) if the documents
>>    it outputs are not flagged as conforming by validators. Therefore
>>    we need a way for validators and authoring tools to coordinate so
>>    that validators will not criticise conforming authoring tools when
>>    a problem (in this case missing alternative text) is the user's
>>    fault and not the author tool's. The simplest solution here is to
>>    reuse the existing document-wide flag that indicates that a
>>    document was created by an authoring tool, and have conformance
>>    checkers silently ignore the missing alternative text in that
>>    situation (or at least phrase the error in a way to indicate that
>>    the authoring tool is not to blame).
>> 
>> Once again, this argument didn't give specific examples of the claimed
>> bad incentive, so it was relatively weak. It is noteworthy however
>> that several respondents took this incentive structure as a given, and
>> none denied that it exists.
>> 
>> 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.
>> 
>> Some of the objections based on validity could also, in theory, be
>> interpreted as objections based on redundancy. In particular, arguing
>> that authoring tools should just generate invalid content seems to
>> argue that producing invalid content is sufficient to address the use
>> case. However, since the question is one of conformance for authors
>> and authoring tools, generating invalid markup does not seem to be a
>> full alternative solution to the use case.
>> 
>> Related to redundancy, it was also argued that if alt may be omitted
>> when the generator mechanism is used, then the email and private
>> communication exemption would be rendered largely redundant. In fact,
>> this was the strongest objection to the email and private
>> communications exception. As a result, accepting the generator
>> exemption would allow us to reject another exemption. This constitutes
>> an additional moderately strong objection.
>> 
>> Thus, overall, the objection based on use cases for the generator
>> mechanism was taken to be a medium objection. It's validity was
>> disputed, but these objections were outweighed by those that argued
>> for its validity. It's non-redundancy was also disputed, but such
>> objections were found to be weak. Thus, overall, the bar for
>> establishing negative consequences is intermediate between high and low.
>> 
>> 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, 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.
>> 
>> A list was provided of example <meta 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> An argument was made that the sole benefit of the generator mechanism
>> exemption would be one that may not be desirable:
>> 
>>    The only benefit is that most tool vendors will automatically
>>    adhere to HTML5, as very few adhere to existing standards. The
>>    exception is a way to codify and bless bad tools.
>> 
>> No evidence was provided that the other claimed benefits
>> (e.g. avoiding the creation of perverse incentives to include bogus
>> alt) would not materialize, thus, this claim based on "the only
>> benefit" was taken as a weak objection.
>> 
>> A further objection based on the blind photographer use case was
>> entered; however, that use case was not claimed for this particular
>> mechanism. That objection was instead applied to mechanisms where it
>> is relevant (title and figcaption), and was given no weight for this
>> question.
>> 
>> 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.
> 
>> *** Decision of the Working Group ***
>> 
>> Therefore, the HTML Working Group hereby decides that:
> 
>>   * The presence of <meta name=generator> makes missing alt conforming.
> 
>>   * The presence of title makes missing alt conforming.
> 
>> The two Change Proposals closest to these results are those identified
>> as Requirement Set 1 and Requirement Set 4:
>> 
>>    http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html
>>    http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707
> 
>> On the generator mechanism and the title attribute, Requirement Set 1
>> aligns with the WG decision:
>> 
>>    http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html
> 
>> Thus, overall, the WG adopts the Requirement Set 1 proposal with
>> regards to aria-labelledby, role=presentation, <meta name=generator>,
>> title and figcaption; but Requirement Set 4 with regards to the email
>> exception.
>> 
>> == Next Steps ==
>> 
>> Bug 8646 is to be REOPENED and marked as WGDecision.
> 
> 
>> == Revisiting this Issue ==
>> 
>> This issue can be reopened if new information come up. Examples of
>> possible relevant new information include:
>> 
>> * Use cases that specifically require the use of aria-labelledby with
>>  alt omitted.
>> 
>> * Use cases that specifically require the use of role=presentation
>>  with alt omitted.
>> 
>> * Examples of authors mistakenly or deliberately omitting alt when
>>  they might have otherwise, due to the generator mechanism exception.
>> 
>> * Evidence that a great number of authoring tools are making wide use
>>  of the generator exemption, and that this interferes with proper
>>  inclusion of alt. (A list of possible generator values was provided
>>  in a Change Proposal, but there was no explanation of where it came
>>  from. Testing of content generators or direct statements of intent
>>  from implementors would provide sufficient evidence.)
>> 
>> * A demonstrated trend towards more authoring tools fully supporting
>>  ATAG2, including the requirement to prompt for textual equivalents
>>  for images.
>> 
>> * Examples of actual users who hand-author HTML emails incorporating
>>  images, and would find it overly burdensome to include alt.
>> 
>> * Examples of other uses for the private communication exemption that
>>  are not covered by other exemptions.
>> 
>> * Evidence that the number of implementations exposing title in an
>>  accessible way is decreasing, or that some existing implementations
>>  are unwilling or unable to expose it in an accessible way.
>> 
>> * Evidence that implementations are unwilling or unable to expose the
>>  figcaption association to assistive technologies.
>> 
>> 
>> === Arguments not considered ==
>> 
>>    However, we should not do this as an attribute on each <img>
>>    element, since doing that would make it far more likely that
>>    authors will abuse the mechanism to shut up validators raising
>>    completely valid problems. Therefore we should limit this
>>    mechanism to page-wide "generator" meta tags.
>> 
>> No proposal was made to make the generator mechanism per element, so
>> this was disregarded.
>> 
>>    If any generated or missing mechanism is included in HTML5, it
>>    should only be included at the element level where it could be
>>    dealt with on an image-by-image case with a detection method such
>>    as a generated or missing attribute, rather than at the document
>>    level.
>> 
>> Disregarded for the same reason.
>> 
>> Additionally, some arguments were presented that a generator mechanism
>> either should or shouldn't be at the element level rather than the
>> document level. But since no Change Proposal actually proposed this,
>> arguments for or against this position were disregarded.
> 
>>    The feature to silence validators for authoring tools could be
>>    misused by authors who want to use a validator but don't want to
>>    give alternative text, but if that occurs (which seems unlikely)
>>    it is easy to resolve by changing the validator requirements to
>>    still clearly announce that the document is invalid while saying
>>    it's not the authoring tool's fault.
>> 
>> This argues in favor of a mitigation that is not part of any Change
>> Proposal.
>

Received on Tuesday, 19 April 2011 08:23:37 UTC