Re: Unresolved Issues

My comments with CMN, Nir's with ND and Eric's original text EH

  At 03:48 PM 9/14/99 -0400, eric hansen wrote:
[snip]
  >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.)
ND  
  In HTML:
  <object> and <applet> element's content (excluding the param elements if
  available)
  <img> the alt attribute.
  for <frameset> I would say <noframes>
CMN
I am not sure I understand. Are you asking whrere the user looks for
equivalent content? In that case it is important to make that clear in
techniques (by including information such as Nir ahs given) and there is a
dependency between this group and the user agent guidelines to make sure they
are interpreting the specifications the same way.
   
EH
  >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?
ND  
  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.
CMN
In fact there is a limitation - the element including the pointy brackets can
eba maximum of 64k in size. In practice the alt text should be as concise as
possible consistent with it fulfilling its function. That's about as much as
can be said - some things simply do not reduce to simple numeric expressions.
  
EH
  >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; 
ND  
  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.)
CMN
I think Nir's answer is good. I would prefer to have alt="illustration " in
order to be clear that there is one. I wuld far prefer to have

  <object type="image/svg" data="illustration.svg">
    <object type="image/png" data="illustration.png">
      <p>A <a href="illustration">simple graphic diagram</a> is also
      available</p>
    </object>
  </object>

EH
  >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? 
ND  
  No. The user agent should be able to find the longdesc attribute.
EH  
  >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.
ND  
  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.
CMN
I agree with Nir
  
EH
  >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.)
ND  
  This is a reformulation of issue 1, I think. Unless I am missing something.
CMN
This actually seems like issue 4 with a different perspective. Where it is
not explicit in markup (for example a longdesc is explicitly associated with
a particular object) it should either be done in the content of the document
itself (e.g., "the following mathematical formula shows that gravity gets
exponentially weaker as objects move farther apart"), or (in the future
perhaps) as machine-readable metadata. 
  
EH
  >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.)
ND  
  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.
CMN
Agreed - this is a good technique in the absence of a mechanism for doing it
in a machine-comprehensible way (such a mechanism is provided by SMIL, and
hopefully in SMIL 2 it will in fact be much more powerful.
  
EH
  >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?
ND  
  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.  
CMN
Currently there is no markup which allow the specification of multiple
alternatives. This is one of the areas where the adoption of RDF and the move
to XML will allow us to create much richer markup. At a page-by-page level it
can be done using PICS already (this is implemented in plenty of browsers).
There is some very good work in this area being done in the UK.
  
The Protocols and formats group are looking at this issue. The hows are a lot
more complex than the whats and whys, which are what I think is n the
province of WCAG.

EH
  >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?
ND  
  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.  
EH  
  >
  >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).
ND  
  Use <object> instead of <img>
EH  
  >
  >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?
ND  
  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.
CMN
This is in fact a crossover issue -  how does one handle the use of signed
languages such as Auslan, BSL and ASL as alternatives? One answer is to use
SMIL. Another approach is to use object and allow for content negotiation.
  
This is probably an open issue for techniques in this group.

EH
  >
  >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.)
ND  
  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.
EH  
  >
  >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.)
ND  
  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).
CMN
I think Nir has answered these pretty well.
  
  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
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Wednesday, 15 September 1999 11:02:03 UTC