- From: <bugzilla@jessica.w3.org>
- Date: Fri, 03 Sep 2010 02:38:06 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10434
Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |a11y, a11y_text-alt
Status|RESOLVED |REOPENED
Resolution|WORKSFORME |
Summary|Specify rel="longdesc" as |Mint a link type for
|an equivalent to @longdesc |pointing to long
| |descriptions
| |(rel="longdesc")
--- Comment #4 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2010-09-03 02:38:00 ---
(In reply to comment #3)
Getting rel="longdesc" into HTML5 sooner rather than later, could impact on the
(final) outcome of ISSUE-30 in one way or another. I therefore open this issue
again, offering more detailed description of how it should be implemented,
hoping that you seen opening for getting into the spec now. That said: I hope
that we discuss this issue in its own right - linking this issue to whether
@longdesc gets into the spec or not, is not likely to produce an honest and
productive debate of the features of rel="longdesc".
DETAILED rel="longdesc" PROPOSAL
PROBLEM:
HTML5 fails offer a link relation (also known as "link type") which
1. has the semantics "link to a long description in the WCAG sense"
2. implies a programmatic association between such a link and the embedded
content it links from
The @longdesc (or @describedby - bug 10455) is useful and should be kept.
However, @longdesc’s unique feature - that it doesn't create a regular link and
thus doesn't "disturb" those that supposedly don't need it - is also many
times not an advantage: An author might actually *want* to create a link
control that is visible/accessible for *all* users and which has the same or
simlar semantics as @longdesc as well as with same or similar user experience
as @longdesc has. However, there is no feature for that in HTML5. WCAG 2.0
describes how to use regular links for this purpose. However, the methods it
proposes are - many of them - to be considered hacks. (See
USE CASES:
* Data Visualization i.e. charts and graphs
* Diagrams
* Cartoons, drawings, illustrations, etc
* When @longdesc would have been ideal, but doesn't work (either as replacement
or complement to @longdesc)
PURPOSE:
The purpose of rel="longdesc"/rel="description" would be to make sure that
plain old links can be used - better, easier and more flexible - for the
purpose of linking to a long description of the object that the link is
visullay or programmatically connected to. It is an accommodation for blind and
visually impaired. However, unlike @longdes, it it is also aimed at all other
groups that could need a long description in another format, and which also
would like to know in advance, that it is a long description and also would
like to know how long description links - compared with how other links works.
(Gregory Rosmaita mentioned viewing wide embedded images on small screens as
one usecase - http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455#c74)
The aim of the long description is to provide what the visual representation
provides. But the aim is also to offer a way for anyone to "draw a link"
between object and 'long description'. Unlike (at least some interpretations
of) HTML4' longdesc attribute, a rel="longdesc" link can be used for sighted
and non-sighted alike. However, @longdesc is meant to link to a resource that
is related to the current article/page. It is not meant for linking to a
related article - in that case authors should rather another (or no) link type,
together with some link text which says "read more on this subject in this
related article".
FUNCTIONALITY & USAGE:
* The rel="longdesc" attribute can be placed inside any link element (<link>,
<area> or <a>), when the purpose of the link is to link to a long description
of an embedded object.
* The link element with rel="longdesc" might be wrapped around the object, or
adjacent to the object, or placed in an image <map> element for the object be
a child element of an <object> element. Thus there may or may not be a
programmatic association between the link element and the object for which it
points to a long descritpion.
* When presenting the link to the user, the user agents should have the option
to programmatically inform the user that it is a long description type of link,
in such a way that the user both understands _that_ it is is a long description
kind of link, and also understand what it is a long description for. (Much like
for @longdesc today.)
* A user that is informed that the link is of type rel="longdesc", should be
able to have a set of expectations about such links. E.g. when clicking the
link, the link should open in such a way that the current page is not
simultaneously closed. This could be achieved with an implicit
target="_blank", whicih is the same method that is implemented for @longdesc.
Or it could be achieved via some AJAX implemenation. The user can expect that
the link points to a resource directly related/linked to - and crafted for -
the current page, and which only points to some related in-dept info
specifically meant to be read, by those who want, in connection with the
current page/article. (This link type should *not* be used to link to an
article that merely *relates* to the current article, by being about the same
subjecto or something like that.)
* A rel="longdesc" link should be able to point to a document containing both
images and text, provided that the images are of role="presentation" *and*
contains a real, long description.
* To allow easy hiding of rel="longdesc" links from visual display ("due to the
marketing departement's requirements"), it should be considered whether the
link text of rel="longdesc" links can be permitted to be empty, in which case
it should be autogenerated by AT (or via CSS), much the same way that e.g. Jaws
generates "Press enter for long description" whenever there is a @longdesc.
* Links of rel="longdesc" type SHOULD be revealed when using keyboard
navigation.
* The functionality should also offer good fallback when the user agent does
not have any support for this link type. Therefore, in order to ensure good
fallback, and in addtion to a description of how user agents should implement
rel="Longdesc", we should also describe how authors can implement the expected
rel="longdesc" behavior. Keywords are: use of rel="longdesc", use of
target="_blank", use of CSS generated content (if there is no link text is
empty) and so on and so forth.
* A link with rel="longdesc" should "live in the same namespace" as @longdesc.
Thus, when the mark-up makes it clear (e.g. via @role="img" on a wrapper
element) that they are point to a long description for the same thing, then an
AT which supports both @longdesc and @rel="longdesc", should probably give
preference to the rel="longdesc" - or at least seek to filter out the one or
the other. Thus it if an <img> is wrapped inside a anchor element with
rel="longdesc", the @longdesc should preferrably be ignored - both to avoid
duplication and in case there they point to different resources. Instead the
rel="longdesc" link should be treated lik a @longdesc lik by the AT.
* Authors SHOULD NOT use 1 pixel images wrapped inside a rel="longdesc" link as
a method for hiding the rel="longdesc" link. Avoidance of that hackish method,
which never the less is described by WCAG 2.0 Technique G73, is one of the
reasons for the establishment of the rel="longdesc" link type.
* Finally, rel="longdesc" is likely to draw attention to this subject, and thus
create consciousness about the problem 'how to link to a long description',
including taht it would allow authors to become creative about how to solve the
problem.
LINKING METHODS - HTML5 vs WCAG2.
There are 4 relevant ways to use links with the purpose of linking to a long
description. However, WCAG 2.0 only offer a description of one of them -
adjacent links - as well as of a fift method: @longdesc:
1. a link adjacent to the object. Also known as "description links" in
WCAG 2.0 Technique G73: http://www.w3.org/TR/WCAG20-HTML-TECHS/G73
2. a link wrapped around the image/object. WCAG 2.0's only discusses this
option
for the usecase when an image funcitons as a link to another resource - it
does
not discuss it as an option for providing an longer description
3. an image map to create an association between object and link(s)
Image maps is actually a special case of adjacent links
4. a link that is located inside the fallback of the object,
e.g. if one is using the <object> element.
A link inside an object works pretty much like a @longdesc link as it
doesnt attract attention (not even a 'link stop' when using keyboard
navigation) from sighted userse
5. longdesc is WCAG 2.0 Technique H45:
http://www.w3.org/TR/WCAG20-HTML-TECHS/H45
DESCRIPTION LINK PROBLEMS - GENERAL
All the above solutions (except the @longdesc attribute, of course) share the
problem that it might be difficult for the user to know that the link actually
leads to a long description resource. This is a a problem for all users.
However, for a non-sighted user, this might be even more difficult to know.
Thus all of the above linking methods could benefit from a rel="longdesc" link
type.
Some of the 5 options above, might/may have been considered (by the WCAG 2.0
authors) to be more difficult to use for long descriptino purposes than others.
E.g the reason why a link wrapper is not discussed by WCAG 2.0 Techniques at
all, is probably because it is hard for a blind user to know whether the image
is a "image link", or whether it serves as an image enlargement button or (not
so often) if points to a long description. (Of course, it might also be
because describing such a method would compete with @longdesc.)
Some of the solutions suggested in G73 can be described as hacks. It involves
placing the link immediately adjactent to the embedded resource, hiding the
link in a very small image (1pixel wide et cetera), using a specific link text
("Long description of this resource") or using the anchor element as a
(visible) caption for the embedded resource, with information about the purpose
of the link inside the @title attribute.
DESCRIPTION LINK PROBLEMS - SPECIFIC
* Simply placing the link nearby the embedded resource does not always make
the relationship clear - thus it should be possible to wrap the link around an
object, in order to draw a stronger connection, without risking confusing the
user.
* However, when an object is wrapped inside an anchor element, then it can
be hard for a screenreader user to know whether the link points to a
description of the <img>, or whether the @alt text of the <img> is meant as
link text.
* When using an invisible/small <img> elment as link text container, then
what ARIA @role should the <img> element then have? Even if a suitable @role
can be found, it seems backwards to FIRST hide the link's visibility from
sighted user. AND THEN hide the fact that it is an image from the non-sighted
users via ARIA.
* Links might also be hidden via CSS. But regardles of how the link is
hidden, when navigating from link to link via the keyboard, such a link creates
a "stop", without any obvious purpose, for the sighted users (See Benjamin
Hawkes-Lewis comment 48 in bug 10455
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455#c48). @longdesc offers a
solution to this problem (it is unavaiable to keyboard navigation), as does
links inside the <object> element (links inside an object element are also not
available to keyboar navigation, as long as the embedded resource of the object
is available).
* Asking authors to use a standardized text such as "Long description of
resource X" - if the text is supposed to be possibel to standardize, then
perhaps it would be more accessible and more language independent to allow user
agents and CSS to generate it? An anchor element without visible content would
also be simpler to hide. The content could be made visible when the element has
focus.
* @longdesc is a good feature, but not even all screen readers support it. It
is unfortunate if authors, when they are looking for the semantics which
@longdesc posesses, are only able to choose a single feature - which doesn't
work universially. It is also unfortunate, should they choose to duplicate the
@longdesc as a link, that the link doesn't have the same semantics, In the
latter case, it would also lead to annoying llink duplication, should the user
agent happen to support @longdesc.
HOW REL=LONGDESC COULD BRING ENHANCEMENT:
There is no perfect solution for all situations. Authors must continue to use
all the methos described above. However, for all of the 4 ways one may use a
link, the rel="longdesc" offers an enhancement: it gives the user agent the
possibility of notifying the user that a certain link is a longdesc link, and
thus create expectations for the user about how such links are implemented in
his/her browser. In particular, @rel="longdesc" offer a benefit for images that
are wrapped in a link and for image maps - these methods are not
recommeded/described as solution by WCAG 2.0 today, Thus, the most important
benefit of rel="longdesc", is that it allows authors to take into use a wider
arsenal links, including links that are programmatically associated with the
object. Using Object elemetns instead of <img>, or using image map, may have
its problems and may be considered difficult to use by many authors. However,
HTML5 should provide the necesary means for those that want to put even take
those methods into use.
A rel="longdesc" link may also have one particular feature which perhaps now
and then is an advantage against @longdesc: for a visited links, a screenreader
informs that the link has been visited, whereas a for a @longdesc link, I don't
believe that they offer such information. (At least JAWS did not seem to do
that, when I tested it.) Another advantage over @longdesc, when the
rel="longdesc" link is placed inside the fallback of an <object>, is that
whether it is visible/available to the user depends on the media type: in
textual browsers, the link in the fallback will be visible - the same should be
the case for screenreader. Whereas in a GUI browser, it will be hidden.
FINALLY: @longdesc VERSUS rel="longdesc"
The two solutions would certainly compete with each others. But it would be a
good competition. Currently, @longdesc is not a success - it is often
misunderstood by authors and often "mystified". By specifiying how one can
recreate the *semantics* of @longdesc as a link, authors would also gain better
understanding for how @longdesc works, which again could make it more popular.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 3 September 2010 02:38:09 UTC