WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: HTML5 Image Description Extension (longdesc) is Proposed Recommendation

for

From: L Snider
Date: Dec 9, 2014 6:43AM

But then we wind up with the issue I am facing, which is accessible PDFs
are not that accessible on Macs, Iphones and Android devices...and the
context of the image and the description is hard to keep track of...

I am curious how many times people use longdesc? I have never used it,
instead I have been able to use the text around an image to explain it so
it is usable for everyone.However, I could see cases where this might not
be possible....so I am curious as to its use.

Cheers

Lisa

On Mon, Dec 8, 2014 at 10:12 AM, Jonathan Avila < <EMAIL REMOVED> >
wrote:

> > 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
>
>
> > > messages to <EMAIL REMOVED>
> > > messages to <EMAIL REMOVED>
>
> > > messages to <EMAIL REMOVED>
> > > >