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: The spec should 1 require @longdesc to point to *accessible* descriptions. 2 include NOTE about the basic IMPLICATIONS of 'accessible': 2.1 RECOMMENDED formats: Docs - and fragment URIs to DOCS - that are readable to all Web browser users (even without special A11Y equipment). Practically speaking: Web (HTML/XHTML) docs & fragment URIs to fragments in such documents. Description in non-textual formats ought to be embedded in HTML (with the known a11y requirments that then applies) and the resulting page be referred to by the longdesc attribute- 2.2 MAY be used formats: Textual docs offered without fragment URI. Typically, such docs ought to be SHORT. EXAMPLES: Plain text docs, HTML docs offered without fragment URI to the description (in particular if the doc lacks structuring elements such as headings etc), PDFs without structure. 2.3 MAY be used if authored accessibly: XML docs with <svg> <math> as root element (In other wrods: SVG and MathML docs.) 2.4 NOT RECOMMENDED: Long/Complicated/Slow documents, though a fragment to the exact description - and other means that simplifies the access to the relevant section (e.g. CSS or JavaScript that hides the irrelevant stuff), might defend use of such documents. 2.5 MUST NOT be used formats: non-textual documents for visual consumption such as static bitmaps (PNG, GIF, JPEG), even if the bitmap depicts text. Static bitmaps should instead be embedded in a regular HTML page - with the text alternative alternative requirements that then applies - and the HTML page be presented to the user as the long description. (Point 2.1 - 2.5 should of course preferrably be shortened, and of course the exact choice of MUST NOT/MAY/RECOMMENDED etc, is of course open for refinements and debate.) CURRENT SITUATION: The spec says that the longdesc URL is a hyperlink to, quote: ]] a description of the image that its parent img element represents. [[ This definition, however, is too loose. For contrast, the definition of the img element’s @src, is more specific. It says that the @src attribute performs the following task: [1] ]] referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted. [[ The HTML5 spec further adds this NOTE describing the IMPLICATIONS: ]] The requirements above imply that images can be static bitmaps (e.g. PNGs, GIFs, JPEGs), single-page vector documents (single-page PDFs, XML files with an SVG root element), animated bitmaps (APNGs, animated GIFs), animated vector graphics (XML files with an SVG root element that use declarative SMIL animation), and so forth. However, these definitions preclude SVG files with script, multipage PDF files, interactive MNG files, HTML documents, plain text documents, and so forth. [PNG] [GIF] [JPEG] [PDF] [XML] [APNG] [SVG] [MNG] [[ QUESTIONS: * May @longdesc point to a multipage PDF document? * May @longdesc point to PDF? * May @longdesc point to a SVG document? * May @longdesc point to a MathML document? * What about images with a textual description of the current image? * What about larage version of current image? The Longdesc Lottery lists many misuses of @longdesc, including that longdesc points to images. I have myself discovered several - *several* - solutions, including JavaScript libraries, that uses @longdesc for linking to a larger version of the current image. Currently, the longdesc spec does not take up this issue in any way. NOTE ABOUT THE SCOPE OF THIS BUG: This bug does not ask that the spec describes what it refers to as "Best practices for full descriptions of images". It only seeks to give basic rules for choice of format. [1] http://www.w3.org/TR/html5/embedded-content-0.html#attr-img-src [2] http://blog.whatwg.org/the-longdesc-lottery
I'd be happy to add "accessible" to the description. I don't think it is a good idea to add normative information about what that requires. A reference to WCAG, which gives a normative guide to what that means might be in order. I would also be happy to add an informative note pointing out that a link to a larger version of the image is a petently inadequate description for almost all users, and should not be considered a valid implementation. Would you be happy with that?
(In reply to comment #1) > I'd be happy to add "accessible" to the description. Excellent! > I don't think it is a good idea to add normative information about what that > requires. A reference to WCAG, which gives a normative guide to what that > means might be in order. Such a link would be excellent! > I would also be happy to add an informative note pointing out that a link to > a larger version of the image is a petently inadequate description for > almost all users, and should not be considered a valid implementation. Excellent. > Would you be happy with that? Yup!
There is an informative pointer in https://dvcs.w3.org/hg/html-proposals/raw-file/0dd2e510d4e1/longdesc1/longdesc.html
I visited this bug, with the intention to verify it as closed. However, I don't see that you added the word 'accessible' yet: (From comment #1) > I'd be happy to add "accessible" to the description. I thought this meant that you would do something like this: ]] The URL is a hyperlink to _AN ACESSIBLE_ description [[ I see that you added this NOTE: ]] This document does not define accessibility. For further guidance on making the description an accessible document, authors should consult [[ If that note said 'accessible' and not 'accessibility' and if the preceding normative text said, 'an accessible description', then it would have been more the way I was hoping. (As it stands, the word 'accessibility' hangs a bit in the air.) Since am in this corner, then I don't think you took action on this: (From comment #1) > I would also be happy to add an informative note pointing out that a link to > a larger version of the image is a petently inadequate description for > almost all users, and should not be considered a valid implementation.
Further more: 1) The fragment URI to the [WCAG] reference is broken. 2) While I am happy for the WCAG reference pointer, could you also add a pointer to a directly relevant section in WCAG 2.0? I suggest to do it like so: ]] The URL is a hyperlink to an <a href=" http://www.w3.org/TR/WCAG20/#guidelines ">accessible</a> description [[ Justification: To simply point to WCAG 2.0 means that authors/readers understand that the thing to bleach, is really really long ... By adding a pointer to the very Guidelines section, where the principles (namely: Perceivable, Operable, Understandable, Robust) are described, makes the entire thing a bit more directly relevant.
I don't think that the start of a list of guidelines is as helpful as pointing to the document, which contains introduction, guidelines, etc so people can work out where in the document they need to look according to their understanding of the issue. I've fixed the fragment reference in my copy - it will appear in the next draft. I still propose WONTFIX.
(In reply to comment #6) > I don't think that the start of a list of guidelines is as helpful as > pointing to the document, which contains introduction, guidelines, etc so > people can work out where in the document they need to look according to > their understanding of the issue. Whichever reference to WCAG you would prefer, perhaps you could add that link to the word 'accessible'. That way, the word 'accessible' would stand out more, and the comment in the note, about not defining what 'accessible'/'accessibility' means, would become a little clearer. Btw, another option could also be to explain 'accessibl' inside the Dependencies section: https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html#dependencies
THe TF agreed that the current approach in the editor's draft is sufficient and refers appropriately.