13449 2011-07-29 13:58:53 +0000 Don't allow blank alt text on area elements 2016-02-26 18:58:56 +0000 1 1 1 Unclassified HTML WG HTML a11y Task Force unspecified PC Windows XP RESOLVED FIXED http://www.w3.org/TR/2011/WD-html5-20110525/the-map-element.html#the-area-element a11y, a11ytf, a11y_text-alt P2 normal --- 8171 1 cooper chaals chaals faulkner.steve ian laura.lee.carlson mark.sadecki+w3c mike public-html-a11y public-html-admin public-html-wg-issue-tracking dave.null oldest_to_newest 51750 0 cooper 2011-07-29 13:58:53 +0000 The description of <area> states "The alt attribute may be left blank if there is another area element in the same image map that points to the same resource and has a non-blank alt attribute." While there is a procedure later in the spec that details how user agents should handle this situation (looking for other <area> elements referencing the same target and retrieving the alt text for those), the HTML accessibility task force does not believe that user agents will go to those lengths, based on input from UA developers in the task force. A situation where alt text is sometimes required and sometimes not also leads to a high probability of author error. Therefore this provision should be removed. Edit details: * Remove the sentence "The alt attribute may be left blank if there is another area element in the same image map that points to the same resource and has a non-blank alt attribute." from http://www.w3.org/TR/2011/WD-html5-20110525/the-map-element.html#the-area-element * Remove step 2 in the second numbered list "Remove all the area elements in areas that have no alt attribute, or whose alt attribute's value is the empty string, if there is another area element in areas with the same value in the href attribute and with a non-empty alt attribute." from http://www.w3.org/TR/2011/WD-html5-20110525/the-map-element.html#processing-model 51894 1 faulkner.steve 2011-08-01 10:33:24 +0000 As implemented in latest Firefox and IE(haven't tested others) this results in screen readers announcing the presence of a link but providing no information about the link target. 52581 2 mike 2011-08-04 05:02:49 +0000 mass-moved component to LC1 54629 3 ian 2011-08-10 20:47:38 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Duplicating the link is even worse in UAs that convert the <map> to a list of links. It is more likely that graphical UAs exposing stuff to ATs will do the right thing here than non-graphical UAs, since the former have far more engineering resources available. 88753 4 mark.sadecki+w3c 2013-06-05 17:39:59 +0000 The TF is no longer tracking this bug, but recognize it is still an accessibility issue. The a11y keyword will remain. 102246 5 chaals 2014-03-12 17:57:35 +0000 Chaals will write a test case and see if there is any reason to believe (after a few years) that user agents deal with this or whether we should ask the spec to change to match reality. 121029 6 chaals 2015-06-16 07:28:50 +0000 More importantly than screen readers, users who primarily interact visually but rely on assistance from information like alt text are likely to be confused. The scenario implied is that there are several regions of an image that would logically link to the same destination. A visual user who seeks confirmation from alt will not be given the same information for the different area element links. It seems this is therefore a straight-out bug. 125275 7 chaals 2016-02-26 18:58:56 +0000 Nothing useful happened in years, the bug is still a problem. Should be resolved with Pull Request #102 https://github.com/w3c/html/pull/102