[Webkit-unassigned] [Bug 10448] Support Longdesc atribute at img element

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Mar 12 22:14:21 PDT 2012 

https://bugs.webkit.org/show_bug.cgi?id=10448


Leif Halvard Silli <xn--mlform-iua at xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xn--mlform-iua at xn--mlform-i
                   |                            |ua.no




--- Comment #6 from Leif Halvard Silli <xn--mlform-iua at xn--mlform-iua.no>  2012-03-12 22:14:21 PST ---
(In reply to comment #1)
> Please describe what kind of support for LONGDESC you would like to see, and why.

Chrome features and basic link behaviour - iCab-inspired:

* On control-click: Be available in context-menu.
* On hover: Display cursor that indicates presence of description link.
  [ If wrapped inside a link or if @title is non-empty, then the long
    description cursor must become more intricate or be suppressed by
    the the link or non-empty-title cursor. ]
* On activation: Open URL, as if target=_blank was specified, in new
  window/tab/context, so that the user can just close the longdesc
  context  in order to be back at the same location on the page,
  where he/she was when the link was activated.

CSS features:

* Except when image loading is disabled, the longdesc link is only
  rendered in the chrome - and not in the page.
* When not visually rendered, the image must thus be activated via
  VoiceOver or via contextual menu.
* When rendered visually, the link could be rendered as a symbol or
  image and should behave as a focusable link. [To VoiceOver users
  the behavior should probably not be affected by whether the link has
  visual rendering or not.]
* Generated content could be used to render the link [Idea taken from
  Steve Faulkner.] 
* When image loading is disabled:
  # Display as a link, before ALT text. Perhaps use the fallback image
    as a link, and just change its shape and color to indicate this?
* When image loading is enabled: 
  # No visible indicator is shown by default. However, authors and
    browser users can use CSS or preferences to enable a clickable
    indicator that occurs outside or above the image.

Keyboard accessibility:

* For VoiceOver users, see next section, below.
* For GUI users:  The longdesc link should be keyboard accessible
  - focusable - but this should rely on the generated content
  version of the link being visible.
  Hence, focusability should automatically step in if the image *isn't*
  loaded. Or if the link is specifically made visible via CSS.
  This is just like how focusability/tabbing general works: If the
  element isn't displayed, then it can't take focus.
* Tabbing order: it should be the same as for the <img>, if it has
   one, but actually take place just *before* the <img>.
* If one tries the contextual menu on such a longdesc hot-spot,
   then the user should probably get the <img>'s usual context
   menu.
* If the user hovers above such a visual longdesc hotspot, then
  the status bar etc, should display the URL.

VoiceOver features:

* *before* reading the @alt text: Announce that it is an image, and
  that it has a description link. Example announcement: ''Described
  image. Press [some key  e.g. Tab] to treat it as a link.''
  # Then proceed to read the image's alt text as normal.
  # If reader presses the key, then switch to presenting the alt text
    as a link  and allow the user to follow the link in the 'normal' way,
    when and if the users wants. 
* if the user chose to open the longdesc context, then, when closing
  the context, VoiceOver should probably behave as if the alt text of
  the image had been presented - even if actually did not read
  everything because the user pressed the link early - and move to
  present next element.

  NOTE: Why announce the description link before reading the alt text? Well, in JAWS, the longdesc opportunity is announced *after* the alt text has been read. But this comes as a surprise to the user, when he has listened to all the alt text - with possible negative attitude as result. It seems better to make the user aware of it from the start. Also, in case the user wants to primarily read the long description, then it is probably not satisfying to have to wait for the entire alt text to be read before being given this opportunity.

Features when image is wrapped inside link:

* Code example: <a href=l><img longdesc=d src=s alt=a></a>
* When longdesc URL and link URL are DIFFERENT:
  # VoiceOver to say:'Link with described image.Press [key] for image.'
    - Then VoiceOver reads link as normal.
    - If key gets pressed: Treat image as 'described image', see above.
  # GUI implementation - when image is not loaded: 
    - the fallback image becomes an extra link, outside and before 
      the textual link.
  # GUI implementation - when image is loaded and CSS to make it
    display is *not* enabled: Nothing special happens.
  # GUI implementation - when image is loaded and CSS to make it
    display *is* enabled: a clickable link outside and above image.
    NOTE: for GUI, this happens regardless of whether the two URLs are
          identical or not.
* When longdesc URL and link URL are THE SAME: 
  # In this case, the link URL is probably meant as a long description
  link. Hence, unless the image ha a non-img @role, then VoiceOver
  should treat the image as a image with a longdesc and not as a link.
  While GUI Webkit should make no difference.
  # ADVANTAGE to VoiceOver users: Longdesc becomes a signal of the
    link's role - it 'demotes' role of the link from link to
    description link. Currently it is a problem, in VoiceOver, that
    linked images are treated as links - the user doesn't get to know
    that it is an image.

Use cases:

* The EPUB usecase: http://diagramcenter.org/development/epubdescribedat.html
   E-pub readers seem to be starting to get longdesc support - possibly under another name on the attribute: <http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0090>. Relevant in that regard, is that  EPUB3 is just HTML5 with some extra 'stuff', and that there are services, such as ibisreader.com, that allows you to read your EPUB books as Web pages. Unless there is a HTML feature, then this functionality can't be expressed.

* Laura Carlsson's use cases:
  http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Use_Cases

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list