WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: HTML5 Image Description Extension (longdesc) isProposed Recommendation

for

From: Jonathan Avila
Date: Dec 8, 2014 9:12AM

> We still end up with many pieces for what should be a self-contained PDF file. With large websites (thousands and millions of pages and documents, such

I thought PDF attachments could be embedded into the PDF and be one file?

Jonathan

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Chagnon | PubCom
Sent: Monday, December 08, 2014 11:08 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] HTML5 Image Description Extension (longdesc) is Proposed Recommendation

Jonathan wrote:
"Could PDF attachments be used as a short-term solution until we standardize on something better?"

We still end up with many pieces for what should be a self-contained PDF file. With large websites (thousands and millions of pages and documents, such as with government agencies), management of all these pieces is a nightmare and sooner or later, a piece or two will become disassociated from the main PDF. End up with a broken PDF that's no longer fully accessible because its longdesc is now missing.

We've tried similar solutions several times and it just doesn't work after a year or two; management of that type of system of multiple data files is fine in theory but fails in the reality of an ordinary workplace. There's too much to keep track of!

-BJC
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508 Accessibility.
Take a Sec. 508 Class in 2014 - www.Pubcom.com/classes

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Jonathan Avila
Sent: Monday, December 08, 2014 8:49 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] HTML5 Image Description Extension (longdesc) is Proposed Recommendation

> I don't care whether it's longdesc or some other system of tag and/or
attribute, but we need a method where the people who create this type of visually complex graphical data (e.g., charts, maps, flow charts, plans, technical drawings, etc.) can easily write a detailed explanation of their graphics.

Could PDF attachments be used as a short-term solution until we standardize on something better?

Jonathan

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Chagnon | PubCom
Sent: Saturday, December 06, 2014 10:56 PM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] HTML5 Image Description Extension (longdesc) is Proposed Recommendation

Olaf wrote: "exactly what would you envision in for PDFs in this regard?"
I envision a defined feature, tag, attribute, or something else that would allow a long detailed description to be available to assistive technologies within the PDF, not outside it. It also needs to be easy to deploy for those who create documents (see the end of my comments for more).

Olaf wrote: "Why not use a link?"
Because links outside the PDF (such as to specific URL webpages) break over the lifetime of the PDF file. In large institutional environments (government agencies, corporations, major publishers), it's difficult, first, to define a specific URL while the document is being created (I.T.
generally doesn't like specifying this before the document is finalized), and second, ensure that the link will still be working a year or more down the road.

Plus, PDFs are often downloaded to individual computers and we can never assume that the end user will have a live internet connection when reading the document to visit a specified URL for the longdesc.

Links inside the PDF would have to link to pages that are added to the PDF but are not in the printed version of the document. An example: a client's 360-page statistical document has approximately 100 statistical, complex, graphical charts. The printed version of the document is OK and doesn't need anything like longdesc. However the matching electronic PDF version would now have to have an additional 30-50 pages added at the back of the book to accommodate longdesc descriptions for those charts, sort of like a special appendix of longdesc descriptions. This produces an electronic PDF version that isn't identical to the printed hardcopy, and that gets my clients in a tizzy; their agencies have interpreted the US federal law requiring electronic versions of all printed documents as meaning that the electronic version must match the printed version. So an electronic version with an extra appendix doesn't meet their federal requirements.

Olaf wrote:
"The longdesc attribute as defined for HTML runs the risk of hiding the longdesc-referenced content from certain groups of users. ... What I do know for sure is that due to the reduced discoverability of longdesc it is inferior to simply using a link."

Why is longdesc less discoverable or hidden from certain users?
Is that the fault of the attribute itself, the W3C definition of longdesc, or the lack of programming by assistive technology manufacturers?

If I recall correctly, the H1 tag wasn't discoverable by screen readers way back when. But over time, A.T. manufacturers have improved their software to discover H1 and many more tags and conventions that are now our standards.
Thank goodness we didn't throw out heading tags back then just because assistive technologies wouldn't deal with them!

What prevents longdesc from becoming a recommended standard/procedure/technique that can be used by those who create documents, as well as for A.T. manufacturers to develop functionality for their users?

What's needed:
I don't care whether it's longdesc or some other system of tag and/or attribute, but we need a method where the people who create this type of visually complex graphical data (e.g., charts, maps, flow charts, plans, technical drawings, etc.) can easily write a detailed explanation of their graphics.

We need the author of the document to create this, not the accessibility technician who follows him, nor the web team, nor the editors, nor the graphic designers, nor anyone else in a typical publishing workflow who completes the document after the author is done.

This task has to be done by the author. So right there, that leaves out links - internal PDF links or external website URL links - because the authors can't code them at their stage of a publication's workflow. This type of document usually takes a year or longer to write and I.T. can't determine where it will live on the website at that point.

So a feature/utility as easy to use as Alt-Text in MS Word would be ideal:
- Right-click and write the Alt-text for the graphic.
- Right-click again and write the long description for the graphic.

If it's attached to the graphic inside the document (such as an attribute on the <figure> tag like Alt-Text), then it stays with the graphic as the document is edited and reflowed, and it will carry through from MS Word into the exported PDF. Or if the content is converted to HTML it will travel with it. Or if the Word file is imported into InDesign for desktop publishing layout, it can carry through into that layout and its exported PDF. And if the document is stored in a content management system (CMS), that it travels with that version, too. Or when the document must conform to established publishing DTDs, schemas, and standards (such as PubMed's DTD for the NLM database).

The functionality has to begin at the author stage and then travel through the half-dozen or more workflow stages of publishing, which is much greater than just Internet distribution alone.

-BJC
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508 Accessibility.
Take a Sec. 508 Class in 2014 - www.Pubcom.com/classes