- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 18 Apr 2011 16:09:41 -0500
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
For the Accessibility Task Force's information:
QUOTE:
*** 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.
http://lists.w3.org/Archives/Public/public-html/2011Apr/0451.html
---------- Forwarded message ----------
From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 18 Apr 2011 13:33:00 -0700
Subject: Working Group Decision on ISSUE-31 / ISSUE-80 validation survey
To: HTMLWG WG <public-html@w3.org>
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.
--
Laura L. Carlson
Received on Monday, 18 April 2011 21:10:12 UTC