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

I am interested in reopening the issue - this is my primary intent. I 
can register FO later, if needed.

Leif

Maciej Stachowiak, Tue, 19 Apr 2011 01:23:03 -0700:
> 
> 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 09:44:32 UTC