Bug ID: JDK-4706779 stddoclet: Add text equivalent of ASCII art in class tree for accessibility

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.4.2 mantisFixed

The ASCII class trees need equivalent text.

  Priority 1
  Section 508 1194.22(a)
      A text equivalent for every non-text element shall be provided 
      (e.g., via "alt", "longdesc", or in element content)
  W3C Checkpoint 1.1
       http://www.w3.org/TR/WCAG10-CORE-TECHS/#text-equivalent
       "Text equivalents mus be provided for every non-text element ... 
        This includes ASCII art..."

The ASCII art under consideration is the vertical line, horizontal line 
and plus sign:

   java.lang.Object
    |
    +--java.lang.String

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b03

14-06-2004

EVALUATION Important for accessibility. ###@###.### 2002-06-22 There are two ways to resolve this: - Put a <MAP title="xxx"> element around each piece of ASCII art, similar to that recommended for grouping links in a navigation bar - Replace the ASCII art with an image <IMG src="inherit.gif" alt="xxx"> The second approach would also make the appearance better, a long-needed enhancement. ###@###.### 2002-08-22 > What should the alt text be? > > The alt text should make sense when spoken by an accessibility program > to a non-sighted user in the context of the words before and after it. > For example, the above would be spoken as: > > "java-dot-lang-dot-Object is extended by com-dot-package-dot-Class1" > > Unfortunately, this is the reverse of the way we normally speak it. > > A) "is extended by" in all cases > B) Insert different strings for an interface "implemented by" a class > compared to an interface "extended by" an interface, > and a class "extended by" a class. > C) Drop the word "is" in proposal A or B: "extended by", "implemented by" > D) Other proposals? I vote C. I'd *definitely* distinguish extended and implemented. I agree that the "is" seems unnecessary, but I could go either way on it. Regards, ###@###.### Conclusion for alt text: interface "implemented by" class interface "extended by" interface class "extended by" class ###@###.### 2002-08-27 Decided to create a resources directory in the destination directory to hold non-HTML files that come from the source tree resources directory, such as inherit.gif and stylesheet.css. Equivalent to what is used in the MIF Doclet. ###@###.### 2002-08-29

29-08-2002