- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 19 Apr 2011 11:44:00 +0200
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: HTMLWG WG <public-html@w3.org>
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