Closed Bug 16501 Opened 25 years ago Closed 23 years ago

Editor LONGDESC Support

Categories

(Core :: DOM: Editor, enhancement, P3)

Product:
Core
Component:
DOM: Editor
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: CodeMachine, Assigned: cmanske)

References

Details

(Keywords: access, helpwanted) 

For accessibiliy purposes, everywhere that there is a specific field for ALT
text, there should also be a specific one for LONGDESC.
Blocks: 16397
W3C Authoring Tool Guidelines 3rd Sep 99 Checkpoint 3.1
These are

3.1 Prompt the author to provide alternative information (e.g., captions,
expanded versions of acronyms, long descriptions of graphics).
5.2 Ensure that the highest-priority accessible authoring practices are among
the most obvious and easily initiated by the author.
Assignee: buster → cmanske
reassign to cmanske@netscape.com, cc beppe@netscape.com and myself
Status: NEW → ASSIGNED
Target Milestone: M20
I don't think it is appropriate to add this to the already complicated
Image Properties dialog for the initial release, which is aimed at general
"word processing", not serious web authoring.
I'm all behind supporting the useability guidelines, but this seems to be a
feature for a subsequent version.
Any other opinions?
Your logic sounds sound.  I'm used to hearing "next version".  =)
Depends on: longdesc
LONGDESC support in Gecko is covered by bug 1996. Adding as dependency since if
the editor is going to support it, people will wonder why Gecko itself doesn't!
moving to future milestone
Assignee: cmanske → beppe
Status: ASSIGNED → NEW
moving back to previous owner
Assignee: beppe → cmanske
Target Milestone: M20 → Future
This will be adequately supported in the 'Advanced Properties' dialog where
you can edit arbitrary attributes for any tag.
Status: NEW → ASSIGNED
added helpwanted
Keywords: helpwanted
Given that this is an attribute on any tag, I still contend that our "Advanced
Properties" editor is the proper place to support longdesc. To encourage it's 
use, it should always be included in the attribute name menulist that is 
planned to be added as soon as anyone gets around to it! It will be filled with
all the common attributes and those specific to the tag being edited.

> Given that this is an attribute on any tag

LONGDESC only applies to IMG, FRAME and IFRAME, if I recall correctly.
Keywords: access
I think we should mark this bug as WONTFIX.  We've done all we intend to do (and 
that wasn't what was requested here).  Users of Composer can add longdesc 
attributes if desired.  If we do (someday) decide to fix this issue, it'd just be 
a part of the fix for bug #16397 (which is currently Future'd).

As described, we support LONGDESC in the "Advanced Properties" dialog, and it
appears in the list of attributes only for the appropriate elements according
to the HTML 4.0 DTD.
Thus I'm inclined to mark this bug as "fixed". Any objections? 
mark it fixed by all means
Ok, fixed it is
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Sorry for not getting back earlier.

I'm sure the information was provided, but the bug as reported is to comform to
the W3C ATAG.

If you think Mozilla does, fine, but from my reading of the ATAG, it doesn't. 
If you want further details of that, I'll look at it further.

So IMO, as brade said, this should be either left open or WONTFIX.
we do supply access to insert longdesc attribute which does satisfy the request,
even though longdesc is only legal in the IMG, FRAME and IFRAME elements -- so I
am not clear why this would be wontfix, marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.