Re: Working Group Decision on ISSUE-31 / ISSUE-80 validation survey - formal objection to the title being conforming

Hi maciej,

This is a formal objection to the decision in regards to allowing
title as conforming when alt is omitted.

regards
Stevef

On 18 April 2011 21:33, Maciej Stachowiak <mjs@apple.com> wrote:
>
> The decision follows.  The chairs made an effort to explicitly address
> all arguments presented in the Change Proposals on this topic in
> addition to arguments posted as objections in the poll.
>
> *** Question before the Working Group ***
>
> There is a basic disagreement in the group on the validity
> requirements for alt.  The result was two issues, six change
> proposals, and a straw poll for objections:
>
> http://www.w3.org/html/wg/tracker/issues/31
> http://www.w3.org/html/wg/tracker/issues/80
> http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html
> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126
> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706
> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707
> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100510
> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504
> http://www.w3.org/2002/09/wbs/40318/issue-31-80-validation-objection-poll/results
>
> Note: other aspects of these issues included other Change Proposals and
> led to separate polls.
>
> == Points in Dispute ==
>
> Six separate markup features were proposed as possible exemptions to
> the general requirement to specify an alt attribute. In other words,
> for each construct, there was a proposal that it is a conforming
> replacement for alt.
>
> Each proposal had separate pro and con arguments, but the structure of
> each dispute was broadly similar:
>
> * For each construct, some argued that there is a valid use case for
>  allowing this particular exemption, which cannot be satisfied in any
>  other way.
>
> * In many cases, the validity of proposed use cases was disputed. It
>  was argued that the use case is improper or should not be served.
>
> * In many cases, there were objections based on redundancy; it was
>  claimed that other mechanisms can serve the same use cases.
>
> * Notwithstanding use cases, many objections indicated that Omitting
>  alt may have negative consequences, and that tese could be worse
>  than the consequences of denying a use case.
>
> These lines of argument all have some validity. However, for the
> various proposed exemptions, the balance of the arguments was affected
> by the specific details of that exemption. The Chairs made an effort
> to evaluate the arguments in a consistent way.
>
> In particular, if strong objections establish a valid, non-redundant
> use case for omitting alt in a specific case, even after accounting
> for objections based on validity or redundancy, then the bar for
> negative consequences was fairly high. The negative consequences
> claimed would have to constitute stronger objections than objections
> based on failing to serve the use case.
>
> On the other hand, if no valid use cases were established for a
> particular case of omitting alt, or if there were strong objections
> based on validity or redundancy, then the bar for negative
> consequences was fairly low. Even relatively weak objections based on
> negative consequences could prevail in such a case.
>
> Examining the individual questions:
>
>
> == Should it be permitted to omit alt when an aria-labelledby attribute is specified? ==
>
> At least one Change Proposal argued that when the aria-labeldby
> attribute is specified, it should be permitted to omit the alt
> attribute.
>
> A Change Proposal argued that aria-labelledby has a valid
> use case:
>
>    For visual users an image can have an implied label due to
>    proximity and placement in relation to the image. The
>    aria-labelledby attribute provides a method to explicitly
>    associate a text alternative with an image, like the alt
>    attribute. The difference being that the text is available to all
>    by default facilitating universal design.
>
>    This technique would be especially useful for image galleries with
>    the developer adding the aria-labelledby attribute to the
>    template. Author adding a text alternative via a text field.
>
> No one disputed the need to serve these use cases.
>
> Thus, the need to serve these use cases was established as valid and
> could potentially make for a strong objection.
>
> However, one survey comment argued (paraphrasing) that it's not
> necessary to allow missing alt when aria-labelledby is also specified;
> authors already have options that satisfy these use cases.
>
> Furthermore, responses on other survey questions proposed figcaption
> to serve similar use cases.
>
> No one disputed the claims of redundancy. Thus, the arguments based on
> redundancy are a strong objection.
>
> Overall, then, while omitting alt when aria-labelledby is specified
> was found to have valid use cases, it was also found to be redundant
> with other constructs. Therefore, the bar for establishing negative
> consequences is low in this case.
>
> Attention then turns to whether there are negative consequences
> omitting alt when aria-labelledby is specified. One argument was that
> it's problematic to let ARIA affect the conformance of non-ARIA
> constructs:
>
>    The aria-labelledby="" attribute should be allowed, but should not
>    affect conformance criteria of non-ARIA content since ARIA is only
>    an annotation mechanism for accessibility APIs.
>
> And similarly:
>
>    Not having any mention of technologies from other layers,
>    e.g. ARIA or RDFa, prevents layering violations and avoids abusing
>    annotation technologies for core conformance.
>
> These objections lacked specifics on the harm that would be caused, so
> was relatively weak, but no one disputed them.
>
>    To permit the omission of @alt because there is @aria-labelledby,
>    is a permission to omit the @alt of a non-presentational image. I
>    believe there should never be permission to drop @alt on any
>    non-presentational image as it represents a complication of the
>    rules that authors have to cope with...
>
> This objection is moderate in strength. Complexity is a valid
> objection to features that have no valid, unique use cases.
>
> Although the objections based on negative consequences ranged from
> relatively weak to moderately strong, aria-labelledby was established
> to be redundant, and so the bar for negative consequences was low.
>
> Therefore, on balance, the proposal to still require alt when
> aria-labelledby is specified drew weaker objections, compared to the
> proposal to allow alt to be omitted when aria-labelledby is
> present. Specific problems of varying severity were identified.
> Combined with the fact that omitting alt when aria-labelledby is
> specified was found to be redundant for its use cases, this
> constitutes a strong objection.
>
>
> == Should it be permitted to omit alt when role=presentation is specified? ==
>
> At least one Change Proposal argued that when the role attribute is
> specified with a value of "presentation", it should be permitted to omit
> the alt attribute.
>
> The case for allowing role=presentation to replace alt was relatively
> limited:
>
>    Why allow role="presentation" to act as an alternative to alt="" ?
>
>    It is specified and implemented to do what alt="" is specified to
>    do.  It is non specific, it works on all elements.  As per the
>    rules specified in current spec pertaining to its use [24], the
>    use of role="presentation" is not dis-allowed on the img element
>    it is in fact stated that it is the only role that can be applied
>    to an img that has an alt=""...
>
> This was the only argument presented, and it does not seem to state a
> use case that specifically requires role=presentation instead of alt
> with an empty value. It argues that the role=presentation exemption
> *could* be allowed, but it doesn't make the case that it *should* be
> allowed, or that there is any problem caused by disallowing. Thus,
> this was taken to be a weak objection.
>
> Since no effective case was made that omitting alt when
> role=presentation is specified has a non-redundant, valid use case,
> the bar for establishing negative consequences was extremely low.
>
> A number of Change Proposal and survey comments objected to allowing
> alt to be left off when role=presentation is specified. One comment
> argued that this state is self-contradictory:
>
>    I object to allowing role="presentation" to be specified without
>    an alt="" attribute because it would allow a state that is
>    contradictory. Making a page self-contradictory is an authoring
>    mistake. Authoring conformance criteria should help authors catch
>    mistakes.
>
> This objection was moderately weak, as it lacks detail. Why is it
> self-contradictory to allow role="presentation" without an alt=""
> attribute, but apparently not self-contradictory to allow alt=""
> without role="presentation"? On the other hand, no one disputed this
> argument.
>
> Another comment objected to the role=presentation exemption on the
> basis of simplicity:
>
>    We should have a simple rule that img role requires a empty @alt
>    when the role is presentational, regardless of whether the
>    presentational role is explicit or implicit.
>
> And another objection along similar lines also argued for a simpler
> rule:
>
>    By permitting role=presentation as a full replacement for the empty
>    alt, we - for no good reason - takes away the focus on correct use
>    of @alt, and this - in a situation where @role can *help authors*
>    to use @alt as intended. By insisting that there must be an empty
>    alt even when there is a role=presentation, we are consequent with
>    regard to what has been the rule until now. We are stable.
>
> These objections are moderate in strength. Complexity is a valid
> objection to features that have no valid, unique use cases.
>
> Another objection (framed as a positive effect for a different
> proposal) made a point related to simplicity, namely that ARIA should
> not affect the non-ARIA validation rules:
>
>    Not having any mention of technologies from other layers,
>    e.g. ARIA or RDFa, prevents layering violations and avoids abusing
>    annotation technologies for core conformance.
>
> This was taken to be a weak objection in itself, since it presents no
> details of the claimed layering violations or abuse. However, the
> following comment provides more detail on the problems that could be
> created by such layering violations:
>
>    Lack of @alt in combination with role=presentation, in general
>    poses no issue to sighted users, unless the @src URL is rotten or
>    image display is not supported or temporarily disabled (during page
>    load). In that case, then user agents generates replacement text
>    such as [image] for the lacking alt. Sighted users are able to
>    live with this, although they may perceive the image to be an
>    important one rather than a presentational one, and if there are
>    many, it disturbs. Users may see the @alt text while the page
>    loads etc. Should validation ignore such issues? I don't think
>    so. By setting the role to "presentation", these problems are
>    hidden from users of ARIA supporting AT. And this fine. However
>    validators should help authors. More precisely they should help
>    them to care for also those user groups that are disturbed by the
>    lack of empty @alt on presentational images and also to avoid
>    visual annoyance that they themselves may care for. And it should
>    help authors to author consequent markup. And should therefore
>    complain about the lack of an empty @alt for images with
>    role=presentation.
>
> This is a moderately strong objection. It provides specific examples
> of the problems that could be created by specifying role=presentation
> without explicitly specifying empty alt="". This is somewhat weakened
> by the fact that these problems are mostly minor and only affect edge
> cases.
>
> Yet another objection argues:
>
>    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. Expecting
>    such a tool to generate role=presentation instead of its current
>    behavior (generating no alt attribute) results in unnecessarily
>    verbose markup for no additional benefit.
>
> This objection seems somewhat tangential to the point, but is taken as
> weak supporting evidence that there is not a strong use case for
> role=presentation without alt being specified.
>
> Although the objections based on negative consequences ranged from
> weak to only moderately strong, omitting alt when role=presentation is
> specified was not found to have any valid, non-redundant use cases,
> and so the bar for negative consequences was extremely low.
>
>
> Overall, the proposal to still require alt when role=presentation is
> specified drew weaker objections, compared to the proposal to allow
> alt to be omitted when role=presentation is present. Specific problems
> of varying severity were identified. Combined with the fact that there
> was no clearly identified use case that specifically required use of
> role=presentation without alt, this constitutes an overall strong
> objection.
>
>
> == 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.
>
>
> == Should it be permitted to omit alt in email or other private communications? ==
>
> At least one Change Proposal argued that when content comprises email
> or other private communications, it should be permitted to omit the
> alt attribute.
>
> The use case was expounded at some length, giving the example of a
> complex image in private e-mail:
>
>    3. PRIVATE USE: In some cases, extremely complex images may be
>    sent from one user to another as part of a private HTML document
>    or HTML e-mail. Such images may be so complex that writing useful
>    alternative text would be a significant endeavour of its own,
>    tantamount to recasting the entire image as text. Ordinarily, that
>    work would be worth the effort, since not all users are able to
>    see the images; the specification should in fact require that work
>    ordinarily. However, we would be ignored (and likely ridiculed) if
>    we required people to write such text in the case of private HTML
>    documents or HTML e-mails amongst users who know each other and
>    are aware of each other's abilities (both technical and physical)
>    to access visual images. Therefore we should have an exception in
>    the requirements for this specific case. ...
>
>    Now, we do not want conformance checkers to "allow" anyone to omit
>    alternative text just in case they are in this situation, so we
>    should further constrain conformance checkers to not allow this
>    unless they have been specifically configured. If we fail to do
>    this, we would undermine the entire attempt at making pages more
>    accessible by requiring alternative text for images in the normal
>    case.
>
> Furthering this argument, it was claimed that alt is often unnecessary
> in private communications, and would be omitted anyway, and therefore
> the spec should not make a requirement that would not be followed:
>
>    It makes no sense to require an author to provide content in two
>    forms (image and text) when one of those forms can be handled by
>    the entire target audience for the content. (A requirement
>    requiring that one's wife write a description of every photo sent
>    to one's husband is just going to be ignored, so there's no point
>    having such a requirement.)
>
> Others argued that, since people engaged in private communication
> would disregard the alt requirement anyway, no provision needs to be
> made for it:
>
>    Private situation does not need to be mentioned in the spec, just
>    as copyright licenses typically do not mention what the user is
>    authorized by law to do in private with the said thing. Man and
>    wife do not validate before they communicate with each others. It
>    improves nothing to put this particular exception in the spec - in
>    instead creates an *artificial* permission which really doesn't
>    permit anything: It is similar to adding restrictions or rights
>    which the copyright holder nevertheless cannot whether permit or
>    restrict this right.
>
> Similarly:
>
>    It is an author's prerogative not to provide text alternatives for
>    images because they're writing for themselves, close friends or
>    relatives. However, a HTML <img> element without both src and text
>    alternative is still not complete. Therefore, it should not be
>    considered valid.
>
> These were taken to be an objections based on validity or redundancy
> (it's not clear which was intended). Arguing that something should be
> allowed because people will do it anyway seems like a marginally
> stronger objection than arguing that something need not be allowed
> because people will disregard the spec. The set of valid use cases has
> generally been taken to be a strong influence on what markup should be
> conforming.
>
> For one specific form of the use case, specifically the case where a
> complex image requires a long description, validity was was disputed:
>
>    Regarding Proposal 1's statement about a complex image use case in
>    an email, it is not applicable. ISSUE 31- missing alt is about
>    short text alternatives not long ones. No one expects a long
>    description for alt text. In fact that would be incorrect. Complex
>    images would be covered by ISSUE 30- Longdesc.
>
> Since longdesc is not currently allowed, per WG decision, this does
> not seem like a relevant objection. Further, complex images requiring
> long descriptions were not the only use case cited. So this was taken
> to be a weak objection.
>
> Examining the question of redundancy, one commenter wrote:
>
>    Consider the same sort of GUI authoring tool I described above,
>    [..] For such tools, this option is essentially redundant with the
>    generator exception option. If both of these exceptions were
>    allowed, we would prefer tools to use the generator
>    mechanism. That leaves the use case of hand-authored content in
>    private communication, which doesn't seem common enough for the
>    spec to explicitly address.
>
> This objection argues that the private communication exemption is
> largely redundant if the generator exemption is allowed.
>
> Looking into the matter deeper, no one specifically claimed a personal
> interest in hand-authoring private communications in HTML format
> without specifying alt. Nor did anyone claim interest in implementing
> a validator feature to implement a special "private communications"
> mode. This strengthens the claim that the true core of the use case is
> covered by the generator exception.
>
> Thus, while the private communication exception was established to
> have a valid use case via marginally strong objections, this was
> greatly weakened by the objection that most of the use case, and
> perhaps nearly all in practice, is sufficiently well served by another
> mechanism. Therefore, the bar for objections based on negative
> consequences was low.
>
> On the topic of harm following from this exception, somer argued that
> senders or recipients of private communication may derive ancillary
> benefits from including alt:
>
>    And it is not a future proof rule: users keep e-mail archives for
>    years. One never knows: after agreeing to not include an alt, the
>    receiver may turn blind, he/she may unexpectedly be hindered from
>    using a graphical e-mail program and the sender himself/herself
>    may loose the image (because the program allows to delete
>    attachments) etc.
>
> And similarly:
>
>    Sighted recipients. They: May have a slow connection and turn off
>    images to speed download.  May have an expensive data roaming
>    connection (that is not slow).  May have images turned off to
>    decrease bandwidth use in order to lower their Internet usage
>    fees.  May have a text-only user agent.  May be listening to the
>    page being read out by a voice browser or other voice output, for
>    example, as they drive or otherwise cannot read the web page.
>
> This was taken to be a moderately weak objection, since the writers of
> this objections also claimed that people could disregard the rule in
> private communication, even if it made their content
> non-conforming. This undermines the premise that these benefits are so
> compelling, that senders of private emails must be required to specify
> alt. However, this was not as weak as some other objections, since
> specifics were provided.
>
> Others argued that allowing this exemption would encourage seeking of
> loopholes:
>
>    Further more, it encourages authors to look for loopholes.
>
> This was taken to be weak, because no specifics were provided.
>
> It was also claimed that the private communication exception
> discriminates:
>
>    The email exception spec text profiles, targets, and discriminates
>    between people on the basis of ability or disability.
>
> However, no specific evidence was given that this provision is
> discriminatory. So this was taken to be a weak objection.
>
> Another objection was on the basis of structural integrity.
>
>   The email exception mechanism breaks the structural integrity of
>   the <img> element.
>
> This linked the same argument as for the generator exemption, that
> omitting alt breaks structural integrity because alt is required. Once
> again, it was given no weight.
>
> The objections to allowing alt to be omitted in private communications
> based on negative consequences ranged from weak to moderately
> weak. However, because the omitting alt in this case was identified as
> redundant, the bar for claims of negative consequences was low. Even
> moderately weak objections are sufficient.
>
> Thus, overall, the proposal to require alt even in private communications
> and email (if none of the other exemptions applies) was found to draw
> weaker objections than the proposal to allow alt to be omitted in all
> cases in private communications.
>
>
> == Should it be permitted to omit alt when the title attribute is specified? ==
>
> At least one Change Proposal argued that when an image has a title
> attribute specified, it should be permitted to omit the alt attribute.
>
> Change proposals and poll responses argued that there are valid use
> cases for the title exemption. One use case proposed is that of
> content authors who cannot provide a true textual equivalent, but can
> provide a caption; one specific example was blind photographers:
>
>    If an author is unable to include alternative text (e.g. they are
>    a blind photographer), then they should still be required to
>    include _some_ information, which could include the image's
>    caption. The caption belongs in the title="" attribute or in
>    <figcaption>.
>
> And similarly:
>
>    2. EQUALITY: There are certain edge cases where a page producer
>    must reference an image without knowing what the image is. Such a
>    producer cannot, by definition, provide a textual alternative to
>    the image: they do not know what the image is.
>
>    One example of this would be a blind photographer who has taken a
>    hundred photos during a vacation, without keeping track of any
>    information as to when or where each photo was taken. Faced with
>    these one hundred JPEG images and the desire to write an HTML Web
>    page that exposes those images, the photographer has no ability to
>    provide alternative text.
>
> This seems like a strong objection to dropping both the title and
> figcaption exemptions; though it does not clearly establish that both
> need to be allowed.
>
> An opposed objection argues that this use case is redundant, because
> it is satisfied by blind photographers or others in this situation
> creating nonconforming content:
>
>    The blind photographer use case in Proposal 1 is a red herring. A
>    blind photographer is not prohibited from publishing photos
>    without text alternatives. They are perfectly free to do so. But
>    no matter if a photographer is sighted or not, if that
>    photographer does not provide a text alternative for an <img>
>    element, it doesn't change two facts:
>    * The <img> element is still incomplete.
>    * A blind USER cannot perceive a photo without a text alternative,
>      even if a blind photographer takes it.
>
> It is true that there are constructs in HTML5 that "work" (in the
> sense that they have a particular effect), even though they are not
> "conforming". However, in general, the rules for content conformance
> have been treated in decisions as being driven largely by the set of
> valid use cases for authors. The argument that authors could simply
> create nonconforming content appears to concede the validity of the
> use case and was thus taken as a weak objection.
>
> A further claimed use case was distinguishing advisory information
> from textual equivalents:
>
>    Advisory information (what title="" contains) is generally
>    different from textual equivalents (what alt="" contains). That
>    said, user agents could expose such content to the A11Y layer in
>    such cases, and this is clearly better than not exposing such
>    content. As such, we support permitting such markup.
>
> Since this lacked specific examples of when such a distinction is
> needed, it was taken to be a relatively weak objection. However, this
> objection was not seriously disputed. A comment apparently in
> opposition to allowing title said:
>
>   Authors are advised to only use the title attribute for "additional
>   information" and not as a full equivalent alternative.
>
> Yet this only seems to reinforce the premise that there is a
> distinction between the two, and thus was taken as an even weaker
> objection.
>
> There were no further objections to validity of these use cases.
>
> One might wonder: since the use cases for omitting alt when title is
> specified are described as being served by either title or figcaption,
> is it necessary to allow omitting alt in both cases, or only for one
> of these constructs? However, both advocates and opponents of these
> mechanisms pointed out important and relevant differences in
> behavior. In any case, no objection was made on the grounds of
> redundancy between these features. Nor was any specific reason given
> to pick one or the other. Thus, the use cases for title were not found
> to be redundant.
>
> On the whole then, strong objections establish that omitting alt when
> title is specified has valid, non-redundant use cases. Therefore, the
> bar for objections based on negative consequences is high.
>
> Examining the claims of negative consequences, some argued that
> allowing alt to be omitted when title is title specified is
> problematic, because the title attribute is fundamentally not
> accessible:
>
>    The title attribute is not an acceptable text alternative as it's
>    content is not displayed to the user unless they can use a mouse
>    and beforehand know the content is there. The content of the image
>    title attribute is also often not detected by AT by default unless
>    the user makes an explicit choice in their preferences to announce
>    the attribute contents.
>
> Similarly:
>
>    To reflect the unsuitability of title attribute content to act as
>    a caption when a text alternative is not available, as the content
>    is not displayed to the user unless they can use a mouse and they
>    know the content is there. Refer to Issue 80 for more detail.
>
> And furthermore:
>
>    The title attribute has been around for over 10 years and it has
>    never been implemented in a way that would make it a suitable
>    substitute for alt attribute content, and there is no sign from
>    implementors that this situation will change.
>
> Also:
>
>    The specification forbids user agents from displaying title
>    attribute content in the same way it displays alt attribute
>    content: "The alt attribute does not represent advisory
>    information. User agents must not present the contents of the alt
>    attribute in the same way as content of the title attribute."
>
>    This constraint makes it even less likely that at some point in
>    the future a critical mass of browsers will implement title
>    attribute such that its content will be displayed in a manner that
>    provides equivalent access to the content for all users.
>
> Though somewhat tricky to follow, the following passage implies that in at least some
> assistive technologies, the contents of the title attribute *are*
> exposed, in an accessible way:
>
>    What we *should* avoid is the the situation we have in the W3
>    HTML4 validation service today: there it is permitted to combine
>    empty @alt with a non-empty @title: <img src=img alt=""
>    title="Lorem ipsum."  > VoiceOver, in accordance with my Validity
>    map, treats this example as non-presentational. And, again in
>    accordance with my Validity map, the @alt should therefore at
>    contain an @alt, since the @alt should reflect the role of the
>    <img>. Note that VoiceOver makes no big difference between
>    @alt="<empty>" and no alt at all. Thus, as far as VoiceOVer is
>    concerned, the need for a non-empty @alt should not only be seen
>    as an accessibility but just as much as a simple rule for authors
>    to follow!
>
> This was combined with a second-hand report, lacking specifics, that
> other assistive technology products would not do so:
>
>    However, reportedly, in other AT than VoiceOver, the lack of @alt
>    in an <img> which has a non-empty @title, creates more or less the
>    same problems whether or not @title is lacking, even if some very
>    (conscious) AT user may get help from @title if they enable
>    support for it. This is an *accessibility* reason to require an
>    @alt even if the <img> has a @title.
>
> Since at least one product is known from testing to expose title="" in
> an accessible way, and since no evidence was provided that other
> products cannot or will not do so, the objection that title is an
> inaccessible mechanism was taken to be a weak objection. The claim
> that it can't or won't be exposed in an accessible way is outweighed
> by the concrete example of it being exposed in an accessible way.
>
> A more subtle objection was the claim that, since many products do not
> yet expose title in an accessible way, that it is problematic to use
> it now:
>
>    Encouraging use of the title attribute before it is implemented in
>    an accessible way does a disservice to users with disabilities.
>
> Not much evidence was provided that this cannot or will not change,
> however. At least one product is already known to expose title in an
> accessible way, and others were reported to do so as an option. Thus,
> this was also taken as a weak objection.
>
> Another argument claims that authors may simply specify title and then
> neglect to specify alt, even if a proper text alternative *is* known:
>
>    Suggesting that the title is an adequate substitute may encourage
>    authors to not provide a text alternative using the alt attribute
>    as conformance checkers will not flag the absence of the alt
>    attribute as an issue.
>
> No specific evidence was presented that this would occur, so this was
> taken to be a weak objection.
>
> Another objection argued:
>
>    Also, an empty @alt should together with a non-empty @atitle should
>    count as *invalid* since the sighted would perceive such an image
>    as non-presentational.
>
> However, this objection failed to explain why the situation described
> would be a problem, so it was taken to be weak.
>
> Thus, overall, the objections based on problems created by omitting
> alt when title is specified were found to be weak. But omitting alt
> when title is specified was found to serve valid, non-redundant use
> cases.
>
> Thus, overall, the proposal to allow alt to be omitted when title is
> specified was found to draw weaker objections than the proposal to
> still require alt when title is specified.
>
>
> == Should it be permitted to omit alt when the image is in a figure with a figcaption? ==
>
> At least one Change Proposal argued that when an image is inside a
> figure element with a figcaption specified, it should be permitted to
> omit the alt attribute.
>
> The same use cases were claimed for the figcaption exemption as for
> the title exemption. For brevity we do not repeat them here, but we
> note that overall they were found to constitute strong objections.
>
> It might be argued that this makes figcaption and title redundant
> mechanisms, however, both advocates and opponents of these mechanisms
> pointed out important and relevant differences in behavior. In any
> case, no objection was made on the grounds of redundancy between these
> features.
>
> Thus, as with title, omitting alt when a figcaption is used was found
> to have valid, non-redundant use cases. Thus, the bar for claims of
> negative consequences was high
>
> One claimed problem with allowing the figcaption exemption was the
> figure/figcaption association is not present in current assistive
> technology products:
>
>    ... based on today's user agents and AT this is a relationship
>    that is unsupported by AT. We should define this use case, and
>    thus allow AT to use <figcaption> as a label for the image.
>
> However, this lacked specifics on what products were tested. No
> evidence was provided that such products would not support the
> relatively new figcaption feature in the future. And it concedes that
> the use case is valid. Thus, this was taken to be a weak objection.
>
> Another argument claims that that some placeholder alt value could be
> included when figcaption provides a caption:
>
>    There is little reason to permit the dropping of the @alt when
>    there is a figcaption. The author can just as well identify the
>    image with a short text such "photo" or "figure", "diagram" or -
>    even - whitespace inside the @alt as this has the same effect and
>    is fast and quick for the author (but whitespace would probably
>    make it invisible to text browsers so this is no good advice -
>    though, not everyone obeys this but treat it as no-alt and
>    generates an @alt text.). Since user agents may repair the lack of
>    @alt if the author doesn't add it, and this yet another reason for
>    the same. It is nice and well if the figcaption provides a
>    label/caption for the image. However, it is a complicating rule to
>    say that one may drop the @alt.
>
> This argument claims that alt could be provided anyway, even if the
> primary text to expose is a caption in figcaption. However, no
> argument is given for why the particular examples chosen (e.g. alt
> containing only whitespace) are superior to omitting alt and relying
> on the caption. In fact, one respondent claimed that such a
> requirement would be excessive:
>
>    I object to requiring the presence of the alt attribute when the
>    image is in a figure with figcaption, because excessive
>    requirements will be perceived to lower the seriousness of all
>    requirements and requiring information that authors are likely to
>    consider duplicate information is likely to be perceived as an
>    excessive requirement.
>
> This was found to be a stronger objection than the objection that the
> figcaption exception is unnecessary.
>
> Another objection raised the possibility of multiple images in a
> single figcaption:
>
>    One thing to consider, as well, is that we are likely to see many
>    instances when there is more than the image inside the figure -
>    perhaps there is some text there, or two images. What then?
>    Authors are likely to not discern between the one image use case
>    and more-than-just-an-image use case very well. (May be it also
>    isn't necessary to discern so much - but this remains to be
>    tested.)
>
> No evidence was provided that multiple images in a single figure has
> created a problem in practice, so this was taken to be a weak
> objection.
>
> Another respondent argued that figcaption was a sufficient replacement
> for alt:
>
>    I do not object to the figcaption being permitted without an alt
>    attribute, as it can act as a mechanism to associate a text
>    alternative with an image when the text is appropriate to be
>    viewed in conjunction with the display of the image or when an
>    text alternative has not yet been provided via the alt attribute.
>
> However, this comment does not seem to comprise an objection either
> way, so it was given no weight.
>
> All objections based on negative consequences of allowing alt to be
> omitted when figcaption is used were found to be weak. The bar
> established by use cases was high.
>
> Therefore, in summary, the proposal to allow alt to be omitted on
> images inside a <figure> element with a <figcaption> drew weaker
> objections, compared to the proposal to still require alt in this
> case. There was no objection to the claim that figcaption has valid
> use cases, and little or no specific harm was identified.
>
> *** Decision of the Working Group ***
>
> Therefore, the HTML Working Group hereby decides that:
>
>   * The presence of aria-labelledby does not make missing alt conforming.
>   * The presence of role=presentation does not make missing alt conforming.
>   * The presence of <meta name=generator> makes missing alt conforming.
>   * Use of private communications does not, in itself, make missing alt conforming.
>   * The presence of title makes missing alt conforming.
>   * The presence of figcaption 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
>
> These Change Proposals agree with each other and with the WG decision
> on aria-labeldby, role=presentation and figcaption.
>
> 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
>
> On the email exception, Requirement Set 4 aligns with the WG decision:
>
>    http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707
>
> 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.
>
> Since the combination of prevailing Change Proposals does call for a
> spec change, the editor is hereby directed to make the changes in
> accordance with the Decision of the Working Group above.  Once those
> changes, as well as changes for the other surveys on these issues, are
> complete, ISSUE-31 and ISSUE-80 are to be marked as CLOSED.
>
> == Appealing this Decision ==
>
> If anyone strongly disagrees with the content of the decision and would
> like to raise a Formal Objection, they may do so at this time. Formal
> Objections are reviewed by the Director in consultation with the Team.
> Ordinarily, Formal Objections are only reviewed as part of a transition
> request.
>
> == 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.
>
>    As Al Gilman said on behalf of PF, "WCAG WG is chartered to set
>    Accessibility guidelines and HTML WG is not; so HTML5 should be
>    careful to supply features that support WCAG and describe their
>    use in ways that conform to WCAG."
>
> Gives no specific argument other than citing an authority.
>
>    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.
>
>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

Received on Monday, 18 April 2011 21:29:26 UTC