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

Hi Maciej,
I am working on a proposal to re-open the decision in regards to title/alt
providing clarifications and new information, so will withdraw my formal
objection at this time.

regards
Stevef

On 18 April 2011 22:28, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> 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
>



-- 
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