This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
PROPOSAL: augment the definition of alt="<non-empty-string> to clearly cover alt="<whitespace>". ALT. 2 PROPOSAL: define alt="<whitespace>" as equal to omitted @alt. ALT. 3 PROPOSAL: One of the two alternative above, with a warning against use of alt="<whitespace>" ALT. 4 PROPOSAL: A separate definition of the semantics of alt="<whitespace>" means. PROBLEMS THAT NEEDS SOLVING: (1) authors might easily think of alt=<whitespace> as equlaato alt=<empsty-string> when it comes to the effect it has for AT users. Whereas, in reality, e.g. VoiceOver+Safari announces the presence of any image whose @alt contains whitespace: if the content is a single space character, then it announcees "space, image", and if it contains two spaces, then it announces "image". (2) Authors might not trust the effect of omitting the @alt - and the spec also includes warnings against omitting @alt. (3) alt="<empystring>" triggers role="presentation", whereas role="<whitespace>" triggeres role="img". Thus authors could easily start doing alt="<whitespace>" instead of role="img". (In VoiceOver+Webkit, it works that way - see bug 10604.) CONSIDERATIONS: AUTHOR BENEFITS OF alt="<whitespace>": The author might want to ensure that the user is able to download the image, and whitespace does provide that functionality. (The alternative for the author, is to use role="img", to omit the @alt or to provide some other @alt text.) NEGATIVE SIDES OF alt="<whitespace>" Ambiguity: the semantics of a space character is ambiguous. E.g. in GUI browsers, if image is unavailable, then it will be replaced be a space, which is often not a good way to represent an image. It is also probably difficult for authors to keep track of whether they intentionally inserted a whitespace, or whether they meant to insert the empty string. OTHER THINGS: Difficult to interpret for the sighted user if the fallback is the empty string. WHAT SPEC CURRENTLY SAYS: about @alt with non-empty string: ]] The image is a key part of the content; the alt attribute gives a textual equivalent or replacement for the image. [[ about absent/omitted @alt ]] The image might be a key part of the content, and there is no textual equivalent of the image available. [[ about @alt with the empty string: ]] The image is either decorative or supplemental to the rest of the content, redundant with some other information in the document. [[
One natural place to add advice about use of alt="<whitespace>" is under the general guidelines http://dev.w3.org/html5/spec/embedded-content-1.html#general-guidelines
Please only file one issue per bug. 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 open a new 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: Problem 1: I don't see why authors would think alt=" " was equivalent to alt="". The spec is clear about the meaning of "empty" and this kind of distinction is all over the platform. Pretty much the only place where they _are_ the same is inter-element whitespace. Problem 2: If people don't trust the spec, we can't fix the problem by adding yet more text to the spec. Problem 3: I do not buy the premise that any authors would even think about this. If you disagree with any of these please file a new bug specifically for that issue.
The Bug Triage Sub Team think this Bug relates to ISSUE 31.