Re: Unresolved Issues

I'll try to answer some of these unresolved issues.
It should be pointed out that some are addressed by other 
work groups of WAI and some in other activities of W3C.

The answers are embedded in the text of the original message.

At 03:48 PM 9/14/99 -0400, eric hansen wrote:
>Unresolved Issues, 13 September 1999
>
>There are a few issues that, at least in my mind, were unresolved in the 5 
>May recommendation and which needed further attention. It seems that some 
>of the recent discussion on the role and nature of LONGDESC are related. 
>
>General Issue Regarding Text Equivalents
>
>Issue 1 - What are "entry points" for text equivalents for each element 
>type? By entry point, I mean that this is the first place to look for a 
>text equivalent for some piece of primary content. It is obvious that the 
>entry point for IMG elements in the primary content is the alt-text. But 
>for other elements I am not sure that it is always obvious. Is a LONGDESC 
>or d-link ever the entry point for a text equivalent or is it always a 
>secondary (or later) location for text equivalents? (It appears that 
>LONGDESC is an entry point for a text equivalent of a frame.)

In HTML:
<object> and <applet> element's content (excluding the param elements if
available)
<img> the alt attribute.
for <frameset> I would say <noframes>
 
>
>Issue 2 - Are there recommended maximum lengths for alternative content at 
>entry points. For example what is the maximum length for alt-text: 10 words 
>or 60 characters?

There are no specific limitations beyond common sense. This applies also 
to paragraphs and headings, and may depend on the type of content, language
etc.
It would be difficult to quantify.

>
>Issue 3 - What are the possible (approved) ways of pointing to secondary 
>(and tertiary, etc.) locations for alternative content? For example, 
>suppose that the main text equivalent for an IMG is found in one paragraph 
>in the main body of a document, in other words, that the text equivalent is 
>available to all users as part of the main document. Presumably there 
>should be something in the alt-text value that refers to that paragraph; 

It could be that alt="" is OK if the image is supplementary 
and all its content is fully available in the text, or if the paragraph is 
right after the image.

A relevant example to your query might be a server side image map. In this
case 
the alt text may say "Navigation links are at the bottom of the page"
(if there is a chunk of content between the map and the text navigation
links.)

>what should be the style and structure of that reference? Another example 
>concerns the use of LONGDESC. Should the alt-text value refer to the 
>existence and/or location of the LONGDESC? 

No. The user agent should be able to find the longdesc attribute.

>Should references be made via 
>prose or by URI? Should terms like "above" and "below" be used? This issue 
>points to the bigger issue how "meta" information could or should be used 
>to establish associations between alternative content and the content for 
>which it is an alternative.

In the case of longdesc attribute, the HTML specification say that's its 
value is a URI. The server side image map example I gave above uses human
language
because alt text is human language.

>
>Issue 4 - How does one designate (tag) the scope (extent, span) of text 
>equivalents that are part of the primary content? (This issue is simply an 
>elaboration of #3.)

This is a reformulation of issue 1, I think. Unless I am missing something.

>
>Issue 5 - Should there be specific tagging to signal the URI/location and 
>sequence of text equivalents for a given piece of content? (This issue is 
>simply an elaboration of #3.)

Depend on what you are doing. For example nested object elements specify 
a sequence of equivalents. But you may consider just puting a list of links 
to an image, a video clip, or whatever, and the text should made it clear 
that these are alternatives. You may also provide alternatives using HTTP
content 
negotiation.

I would say that giving the user the alternative that suits him 
best automatically is better, but limitation of HTTP, HTML and their 
implementation in current browsers may dictate otherwise in some cases. 

The guidelines do not address this in detail because they attempt to be
stable.
The techniques document, which may be revised independently of the
guidelines, 
addresses these issuses in greater detail.

>
>Issue 6 - How does one handle text equivalents for specific disabilities? 
>Because a text equivalent may be constrained/defined by the nature of a 
>disability and the state of technology, it is possible to have different 
>text equivalents for different disabilities. For the sake of efficiency, we 
>encourage people to write text equivalents that would be appropriate for 
>essentially all disability groups, but this may not always be practical. 
>For example, certain variants may be better suited to different types of 
>cognitive or learning disabilities or deafness. How would one tag these 
>alternative text equivalents?

Generally there should be that for any given disability there should be at
least 
one accessible equivalent. That is providing an image as the only equivalent 
to a video clip is not good enough.  

>
>Text Equivalents and Multiple Languages
>
>Issue 7 - How does one handle "text equivalents" in other languages? Isn't 
>it the case that alt-text, LONGDESC, and d-links are reserved for 
>accessibility purposes, not internationalization efforts?

alt text and longdesc should not be used to give "another language
equivalent".
Current specifications such as HTTP (content negotiation) or HTML (the link
element) allow 
to specify "a language equivalent" to a complete document. This issue may
be improved
(e.g. specifying alternatives fragments) in future versions of these or
other specifications, but belongs to the internationalization activity of
W3C.  

>
>Issue 8 - How does one handle language changes in the midst of locations in 
>which the language attribute is not available (e.g., alt attribute).

Use <object> instead of <img>

>
>Issue 9 - How does one handle parallels versions of content in different 
>languages. For example, if the Rosetta Stone were transferred to the Web, 
>what tagging would be appropriate?

This is an internationalization issue. It has some aspects regarding 
accessibility, and somewhat addressed in the techniques document.
(1) HTTP content negotiation is the preferred technique, and (2) different
HTML 
documents in different languages can refer to each other via <link> and (3)
simple anchors at the begining of each document as a fall back in case the
previous two
didn't work (due to poor implementation in the user agent).

I would use all three simultaneously. If browsers were to implement <link> 
in some reasonable way (as Lynx does) the third option would not be needed.

>
>
>Text Equivalents and Auxiliary Information
>
>Issue 10 - In what location(s) does one discuss the relationships between 
>frames as required in checkpoint 12.2? (I realize now that this is 
>basically explained in technique 4.10.2, although I was somewhat surprised 
>to have the contents of LONGDESC called a text equivalent for the frame. I 
>wonder if that should be considered some kind auxiliary or meta information 
>but not a text equivalent.) 
>
>Issue 11 - How does one signal to the user the existence location of 
>auxiliary information, such as title, table summary, acronyms, 
>abbreviations? (This seems to be a basic issue for authoring tool and user 
>agent groups and is probably being addressed.)

How title and summary are presented are mainly a user agent issue. Although
giving authors a clue how they are implemented should be helpful for writing 
this content well. This is not done in current guidelines or techniques due
to lack of 
implementations at this point.

>
>Issue 12 - Is "title" a disability access feature? Could title be used as a 
>text equivalent? (My notes suggest that I saw it being used as such but I 
>don't recall what it may have been.)

The general answer is that title is not for equivalents. It is for giving
suplementary information.  One exception would be <frame> where title may
serve as "a link 
description" to the function of the frame. This is shortcoming of HTML, or
more 
precisely of the way frames were imposed on HTML by Netscape.

The title of <link> also serves as a link description but it suplements 
the rev and rel attributes (although these are optional).

Regards,
Nir.


===================================
Nir Dagan
Assistant Professor of Economics
Brown University 
Providence, RI
USA

http://www.nirdagan.com
mailto:nir@nirdagan.com
tel:+1-401-863-2145

Received on Tuesday, 14 September 1999 19:52:38 UTC