[Bug 21437] New: Say that @longdesc should point to *accessible* descriptions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21437

            Bug ID: 21437
           Summary: Say that @longdesc should point to *accessible*
                    descriptions
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
               URL: http://www.w3.org/TR/2013/WD-html-longdesc-20130312/#l
                    ongdesc
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML Image Description Extension
          Assignee: chaals@yandex-team.ru
          Reporter: xn--mlform-iua@xn--mlform-iua.no
        QA Contact: public-html-bugzilla@w3.org
                CC: public-html-admin@w3.org,
                    xn--mlform-iua@xn--mlform-iua.no

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 29 March 2013 19:27:51 UTC