Re: Working Group Decision on ISSUE-31 / ISSUE-80 validation survey

Apologies for the repost I have done so as Jonas pointed out[2] that
it would be much better to reply to the existing thread


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

All browsers that I know of treat these 2 cases the same in regards to
accessibility API mapping:


example 1
<img src="2421.png" title="Image 640 by 100, filename 'banner.gif'">


example 2
<img src="2421.png" alt="Image 640 by 100, filename 'banner.gif'">

in the cases above both title and alt are mapped to the accessible
name property in accessibility APIs, this has always been the case and
as there is no practical alternative will continue to be the case.

So for a screen reader user there is no difference in how the two are
presented to the user.

The only difference in the HTML5 specification are normative rules
about what each attribute can contain, the alt attribute rules are
precisiely described, the title attribute rules are not.
Authoring as in example 2 is non conforming authoring 1 is not, quite
the opposite it is encouraged in cases where a text alternative is not
known.

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

No graphical browser supports title attribute display in an accessible
way. Now graphical browser maps title to accessibility APIs
differently from how it maps alt when alt is not present.
of the graphical browsers only webkit displays title content when
images are not viewable or disabled, but only if the title content is
a few words:
(refer to the follwoing test/results
http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/alt-examples.html)

The fact that webkit displays title attribute content in the same way
as alt when images are not displayed, is not an argument for its
accessibility as it requires keyboard only users to turn images of in
order to view titles. there is no equivalency in the method of access
between keyboard and mouse users.


Note: webkits behaviour is also non conforming as per the HTML5 spec:

"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." [1]


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

There is a clear distinction between the two, use of figcaption
provides accessible display of the caption content, to all users at
all times.
Use of title does not and thus discriminates against a range of users
as it is not implemented in a device independent way in any  browser
although it has been in HTML for 10+ years.
these users include:
those who cannot use a pointing device.
screen magnifier software users. (at higher magnifications tooltips
are not displayed in the viewport and as they are tied to mouse
position the user can never read all the tooltips of more than a few
words)
users of built in browser magnification (tootlips are not magnified).
users with cognitive impairments (in most browsers tooltips only apear
on hover for a short time, around 5 seconds, so ).


[1] http://dev.w3.org/html5/spec/embedded-content-1.html#the-img-element
[2] http://lists.w3.org/Archives/Public/www-archive/2011Apr/0082.html

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 Tuesday, 19 April 2011 12:43:21 UTC