w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-31/80: What to do about validation when the image element is missing the alt attribute - Straw Poll for Objections
The results of this questionnaire are available to anybody.
This questionnaire was open from 2011-03-29 to 2011-04-05.
6 answers have been received.
Jump to results for question:
- Objections to Aria-labelledby being permitted or not permitted
- Objections to Role attribute with a value of "presentation" being permitted or not permitted
- Objections to Generator mechanism being permitted or not permitted
- Objections to Email exception being permitted or not permitted
- Objections to Title attribute being permitted or not permitted
- Objections to Figcaption being permitted or not permitted
1. Objections to Aria-labelledby being permitted or not permitted
We have a set of Change Proposals identified in the summary description that allow and disallow various exceptions to the general requirement to specify an alt attribute on all img elements. If you have strong objections to permitting or not permitting a missing alt attribute when aria-labelledby is specified, then please state your objections below.
Aria-labelledby is allowed as an exception by: Requirement Set 2 and Requirement Set 3.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to Aria-labelledby being permitted or not permitted |
|---|---|
| Ian Hickson | 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. |
| Leif Halvard Silli | Please see my Validity map for overview and details the folloing standpoint <http://lists.w3.org/Archives/Public/public-html/2011Mar/0750>: NOTE: I pressuppose 3 things: 1) that this poll uses @aria-labelledby as a phrase which also covers @aria-label and @aria-describedby At any rate: everytime, I say '@aria-labelledby' I also include @aria-label and @aria-describedby 2) that *empty* @aria-labelledby, @aria-describedby or @aria-label is not what it is asked about. 3) that *empty* @alt is not meant to be valid in combination with @aria-labelledby. (For general justification for why I pressupose these things, see my Validity map.) Objection: * I object to stamping an <img> with an *non-empty* @aria-labelledby as valid whenever it lacks an *non-empty* @alt. (Thus empty @alt is also invalid). @aria-labelledby should be permitted also when @alt has been omitted. But it should not make the <img> more or less valid. The basic reason is found in my Validity map: a) We shoudl have a simple rule that img role requires a non-empty @alt - even if the alt is the empty string. b) A non-empty aria-labelledby should - in lack of any other signals, such as an explicit role="presentation", be seen as implicitly setting the role to "img". c) It is important to establish a hiearchy: @alt should be seen as the servant of the <img>'s role. This is the only logical order and is also the order taht e.g. VoiceOver follows. A lack of @alt - irrespective of whether there is a @title, @aria-describedby or role=presentation - should always make the image invalid. 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 plus that it has various effects in different user agents - some perform a repair and display a dummy fallback such as [image], while some do not. It also complicates the situation for authoring tools: should they bug the author about lack of @alt or should it not? Why? Why not? HTML5 clarifies the role of an empty and an non-empty @alt: * The empty @alt is equal to role=img, unless something, such as an explicit role=presentation contradicts that. * The non-empty @alt is, role wise, only to be interpreted as a confirmation of the default role of img elements - role=img. We need to emphasize these rules, because they are simple to authors and because even these simple rules are not without bugs in implemenations: just during this poll, I came across a particular situation where VoiceOver for some reason looked at the @src attribute in order to create an alternative text despite that @alt was empty. Likewise, some other user agents makes no distinction between empty alt and white-space inside alt. The @alt text should be seen as a textual substitute. If the author thinks that a nearby text provides a sufficient label for the image, then the author may simply fill the @alt with whitespace (HTML5 and the editor is clear on the fact that whitespace is also counting as non-empty alt) or if not whitespace when some other dummy text, and use aria-labelledby to link to the nearby label - this will work fine for ARIA supporting AT. This way the author can create a predictable fallback/alternative text experience. If the author wants to provide something more meaningful, (s)he can type a relevant dummy like "photo" - while also using aria-labelledby to link to something more meaningful. If the author doesn't provide some fallback text, then the user agent may anyway often autogenerate a fallback text such as [image] or use the URL as fallback text - thus it is better to write " Photo. ", if that is what it is. The Flickr use case can use the above mentioned methods and, actually, do already write "photo". In a summary: aria-labelledby in combination with lack of alt is not an error. But lack of @alt is an error. Put differently: One should not be punished for trying to do something good, such as adding aria-labelledby. But one should also not be "rewarded" by not needing to do something relevant with @alt. The only reward one SHOULD get, though, is that the validator should require a non-empty @alt, rather than any (empty or no-empty alt. |
| Laura Carlson | |
| Henri Sivonen | |
| Steve Faulkner | |
| Theresa O'Connor |
2. Objections to Role attribute with a value of "presentation" being permitted or not permitted
We have a set of Change Proposals identified in the summary description that allow and disallow various exceptions to the general requirement to specify an alt attribute on all img elements. If you have strong objections to permitting or not permitting a missing alt attribute when the role attribute with a value of "presentation" is specified, then please state your objections below.
Role attribute with a value of "presentation" is allowed as an exception by: Requirement Set 2.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to Role attribute with a value of "presentation" being permitted or not permitted |
|---|---|
| Ian Hickson | 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. role="presentation" should naturally be allowed (and indeed implied) if there is an (empty) alt="" attribute. |
| Leif Halvard Silli | Please see my Validity map for overview and details the folloing standpoint <http://lists.w3.org/Archives/Public/public-html/2011Mar/0750>: Objection: * I object to not require an *empty* @alt when the <img> has an explicit role="presentation". When role=presenation is explicitly declared, an empty @alt must be required. Neither no-alt or non-empty @alt should count as fully valid. The basic reason is found in my Validity map: a) We shoudl 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. b) It is important to establish a hiearchy: @alt should be seen as the servant of the <img>'s role. This is the only logical order and is also the order that e.g. VoiceOver follows. While one could say that AT is saved by role=presentation and leave it at that - no @alt requirements, this creates a dissonanse between what one may see in text browsers/with image display disabled etc and what one "sees" in a ARIA AT. Such dissonance should be avoided. ARIA itself recommends to do make CSS visibillity dependt on selection of the aria-hidden attribute ([aria-hidden="true"] { visibility: hidden; }) to ensure that ARIA sees as visisble what sighted sees as visible. A similar approach seems logical when it comes to role=presenatio, except in the opposed order: The img that is served as presentational to the AT user, should be - when it matters - also be perceived as presenational (that is: not be perceived at all) by sighted user. In general, we should not use ARIA as a tool which frees us from any rules - that is not its purpose. Ian said in his comment about @aria-labelledby that it should not affect conformance criteria of non-ARIA content since ARIA is only an annotation mechanism for accessibility APIs. I agree with this. Except that anything that explicitly or implicitly sets the role of the img, as as result of that explicit or implicit role, should lead to author requirments on the non-ARIA level. Thus, a non-empty aria-labelledby should lead to role=img requirements w.r.t.. @alt. And likewise for role="presentation": it should lead to a requirement that the @alt should be empty. By permitting role=presenation 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. We help the author to verify that (s)he did what (s)he meant and meant what (s)he did. This is also similar to how <table role=presentation> require that the content of the table is not a table-like text but a text that simply needs "layout". Likewise, role=presentation should be treated as indicative of what the author meant. AT treat it like that - they respect the role="presentation". And Valdiators should behave in a similar way except that they should require an empty @alt rather than simply ignoring it. 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 supporte 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 validaiton 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 preciely 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 anoyanse that they themselves may care for. And it shoudl help authors to author consequent markup. And should therefore complain about the lack of an emtpy @alt for images with role=presentation. |
| Laura Carlson | |
| Henri Sivonen | I object to allowing role=presentation when the alt attribute is present but has a value that is non-empty. role=presentation means that the element is flattened out of the representation of the document exposed to assistive technologies. A non-empty value for the alt attribute means the image has a text alternative that is of interest to people who don't see the image. Thus, the combination of trying to convey information while marking the information as something that gets dropped is most likely an authoring error and should be flagged as such. For avoidance of doubt: I do not object to role=presentation without an alt attribute or role=presentation with an alt attribute whose value is the empty string. |
| Steve Faulkner | |
| Theresa O'Connor | 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. |
3. Objections to Generator mechanism being permitted or not permitted
We have a set of Change Proposals identified in the summary description that allow and disallow various exceptions to the general requirement to specify an alt attribute on all img elements. If you have strong objections to permitting or not permitting a missing alt attribute when the generator mechanism is used, then please state your objections below.
Generator mechanism is allowed as an exception by: Requirement Set 1.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to Generator mechanism being permitted or not permitted |
|---|---|
| Ian Hickson | 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. 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. |
| Leif Halvard Silli | Please see my Validity map for overview and details the folloing standpoint <http://lists.w3.org/Archives/Public/public-html/2011Mar/0750>: I object to looser requirments for the use of @alt based on the presence of a "generator mechanism". It is the attributes of the image itself plus eventually the context it appears withing (<figcaption> etc) which decides the explicit or implicit role of the img. And, subsequently, it is this implicit or explicit role which should decide the requirements to have a empty or non-empty @alt. Hence, the generator mechanism should not have any bearing on the @alt rquirements 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. |
| Laura Carlson | I object to the generator mechanism as one of the validity options. It should be eliminated from the alt section of the spec regarding guidance for conformance checkers. http://www.w3.org/TR/2010/WD-html5-20100624/embedded-content-1.html#guidance-for-conformance-checkers The generator mechanism facilitates the creation of inaccessible content. For details please visit: http://tinyurl.com/28a33ss The generator mechanism breaks the structural integrity of the <img> element. For details please visit: http://tinyurl.com/4dlo5xp This break is an inequity that results in content not perceivable to some people. A text alternative is as necessary to the schema technically as is src. 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. For details please visit: http://tinyurl.com/4mwagqe Regarding Proposal 1's statement about teachable moments, HTML should facilitate accessibility education and provide something useful in the way of information beyond an error. For details please visit: http://tinyurl.com/4mwagqe This information is currently provided in classes, workshops, tutoring, websites, books, mail lists, forums as well as in tools that follow ATAG. But beyond these, we currently hold a real opportunity for validators to help educate by directly pointing authors who encounter a missing text alternative error, to advice on how to fix it. Mike Smith's pilot will trigger error text "expected to reference additional guidance on text alternatives in WCAG support materials". Integrating accessibility into HTML5 in this manner is an advent that will directly facilitate more perceivable content. The generator mechanism would make this useless. 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. In response to Ian's "If an authoring tool or other generator does not have sufficient information" comment on this survey, please refer to "Addressing the Authoring Tool Rule" and Gez Lemon's quote for rationale. http://tinyurl.com/4sd9sbv Application developers should follow ATAG http://www.w3.org/TR/ATAG20/ They should help authors provide text alternatives i.e XStandard. http://xstandard.com/en/articles/better-alt/ aria-labelledby could provide a solution for the Flickr use case. http://tinyurl.com/4nh5lmw 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." http://lists.w3.org/Archives/Public/public-html/2008Feb/0082.html The generator mechanism violates WCAG. |
| Henri Sivonen | 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.) |
| Steve Faulkner | |
| Theresa O'Connor |
4. Objections to Email exception being permitted or not permitted
We have a set of Change Proposals identified in the summary description that allow and disallow various exceptions to the general requirement to specify an alt attribute on all img elements. If you have strong objections to permitting or not permitting a missing alt attribute in the case of email or other private communications, then please state your objections below.
Email exception is permitted by: Requirement Set 1.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to Email exception being permitted or not permitted |
|---|---|
| Ian Hickson | 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.) |
| Leif Halvard Silli | Please see my Validity map for overview and details the folloing standpoint <http://lists.w3.org/Archives/Public/public-html/2011Mar/0750>: I object to, in any context or with any attribute, declaring it as permitted to not use the - as required - empty or non-empty @alt. 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 befor they communicate with each others. It improves nothing to put this particular exception in the spec - in instead creats an *articifical* 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. 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 attachmetns) etc. Further more, it encourages authors to look for loopholes. |
| Laura Carlson | I object to the email exception as one of the validity options. It should be eliminated from the alt section of the spec regarding guidance for conformance checkers. http://www.w3.org/TR/2010/WD-html5-20100624/embedded-content-1.html#guidance-for-conformance-checkers The email exception spec text profiles, targets, and discriminates between people on the basis of ability or disability. HTML5 should not make rules beyond its scope. For details please visit: http://tinyurl.com/324gdhr The email exception mechanism breaks the structural integrity of the <img> element. For details please visit: http://tinyurl.com/4dlo5xp 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. |
| Henri Sivonen | |
| Steve Faulkner | |
| Theresa O'Connor | Consider the same sort of GUI authoring tool I described above, in the question on role=presentation. 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. |
5. Objections to Title attribute being permitted or not permitted
We have a set of Change Proposals identified in the summary description that allow and disallow various exceptions to the general requirement to specify an alt attribute on all img elements. If you have strong objections to permitting or not permitting a missing alt attribute in when the title attribute is specified, then please state your objections below.
Title attributed is allowed as an exception by: Requirement Set 1.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to Title attribute being permitted or not permitted |
|---|---|
| Ian Hickson | 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>. |
| Leif Halvard Silli | Please see my Validity map for overview and details the folloing standpoint <http://lists.w3.org/Archives/Public/public-html/2011Mar/0750>: Objection: * I object to not require an *non-empty* @alt when the <img> has a *non-empty* @title (provided that there is no @role=presentation which overrules this) Also, an empty @alt should togethe with a non-empty @atitle should count as *invalid* since the sighted woudl perceive such an image as non-presentatinoal. The basic reason is found in my Validity map: a) We shoudl have a simple rule that img role requires a non-empty @alt when the role is img, regardless of whether the img role is explicit or implicit. b) It is important to establish a hiearchy: @alt should be seen as the servant of the <img>'s role. This is the only logical order and is also the order that e.g. VoiceOver follows. 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, treates this example a non-presenational. 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! 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. Thirdly, the very idea that authors can skip using @alt if @title is present, could be perceived by authors as if lack of @alt is not such a big problem. It is also a complicating rule for authors. Authors need a simpler rule about how to use @alt. This example from HTML4 demonstrates how important the @alt is. In contrast to HTML4, HTML5 makes it clear that empty @alt equals presentation role. To combine signals which says that the image is non-presentational with an emtpy @alt - which says the opposite, MUST therefore be forbidden. |
| Laura Carlson | I object to the title attribute as one of the validity options. It should be eliminated from the alt section of the spec regarding guidance for conformance checkers. http://www.w3.org/TR/2010/WD-html5-20100624/embedded-content-1.html#guidance-for-conformance-checkers Text alternative validity should not be dependent on a feature that is not accessibility supported. For more details please visit: http://tinyurl.com/4jy22r5 |
| Henri Sivonen | |
| Steve Faulkner | i object to the title attribute being permitted, my reasons are detailed in http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 |
| Theresa O'Connor | Advisory information (what title="" contains) is generally differnt 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. |
6. Objections to Figcaption being permitted or not permitted
We have a set of Change Proposals identified in the summary description that allow and disallow various exceptions to the general requirement to specify an alt attribute on all img elements. If you have strong objections to permitting or not permitting a missing alt attribute in when the image is in a figure with a figcaption, then please state your objections below.
Figcaption element is allowed as an exception by: Requirement Set 1, Requirement Set 2, Requirement Set 3, and Requirement Set 4.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to Figcaption being permitted or not permitted |
|---|---|
| Ian Hickson | 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>. |
| Leif Halvard Silli | Please see my Validity map for overview and details the folloing standpoint <http://lists.w3.org/Archives/Public/public-html/2011Mar/0750>: Objection: * Just as for a non-empty @title I object to permission to omit having a non-empty @alt just because the <img> is the sole content of a <figure> which has a <figcaption>. Basically, the justification is the same as what I said abou @title (see above). In addition, based on today's user agents and AT this is a relationship that is unsupported by AT. We should define this usecase, and thus allow AT to use <figcaption> as a label for the image. However, we shuld still not permit the @alt to be empty. 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. Rather than loosenign the rule to always use @alt, we should have looser rules about how to use @alt: When the image has a caption inside the figcaption, the author may provide a simple @alt text such as "photo" or other text which identifies something about the image's nature. (Remember, if the author doesn't provide such a text, the user agent may write [image], and I cannot see that this is the slightest better than the author providing a slightly more useful text such as "Photo.") 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 thsi remains to be tested.) My basic permis is that when an <img> plus an <figcaption> is the only child of a <figure>, then its role should be considered to implicitly be rol=img. Thus validators should as for a *non-empty* alt. And when the @alt is empty, it should, as well, demand a non-empty @alt, due to this context. PS: HTML5 should also identify *other* element + <img> combinations which defaults the <img> to have role=img - see my Validity map. For instance, if <img> is the only child of a <dfn> element, then the <img> should logically have role=img and contain a non-empty text. |
| Laura Carlson | |
| Henri Sivonen | 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. |
| Steve Faulkner | 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. |
| Theresa O'Connor | Captions are not textual equivalents. 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. |
More details on responses
- Ian Hickson: last responded on 29, March 2011 at 21:11 (UTC)
- Leif Halvard Silli: last responded on 31, March 2011 at 04:13 (UTC)
- Laura Carlson: last responded on 31, March 2011 at 05:37 (UTC)
- Henri Sivonen: last responded on 5, April 2011 at 11:32 (UTC)
- Steve Faulkner: last responded on 5, April 2011 at 15:40 (UTC)
- Theresa O'Connor: last responded on 6, April 2011 at 00:46 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project