E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Olaf Drümmer
Date: Sat, Dec 06 2014 5:51AM
Subject: HTML5 Image Description Extension (longdesc) is a Proposed Recommendation
No previous message | Next message →

Hi Bevy,

On 5 Dec 2014, at 18:22, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:

> Is there any word on the street about something similar for PDFs?

exactly what would you envision in for PDFs in this regard? Why not use a link?

The longdesc attribute as defined for HTML runs the risk of hiding the longdesc-referenced content from certain groups of users. If longdesc simply were an ordinary link, labeled something like "Detailed explanation of Figure 3", and point to the same target as longdesc would - what would be lost? What I do know for sure is that due to the reduced discoverabilty of longdesc it is inferior to simply using a link.

Olaf

From: Chagnon | PubCom
Date: Sat, Dec 06 2014 8:55PM
Subject: Re: HTML5 Image Description Extension (longdesc) is Proposed Recommendation
← Previous message | Next message →

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

From: Olaf Drümmer
Date: Sun, Dec 07 2014 5:29AM
Subject: Re: Longdesc and PDF (was:HTML5 Image Description Extension (longdesc) is Proposed Recommendation)
← Previous message | Next message →

Hi Bevy,

thanks a lot for your detailed reply!

A clarification before we look at some of the details: with links I meant PDF-internal links; I fully agree that the PDF file at hand must remain self-contained.

One thing that scares me:
> 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


from my point of view there should not be a legal difference between additional information whether encoded via a longdesc-like mechanism (it's there, but not visible by default) and an annex (it's there and it is visible by default). Do people with disabilities not have the right to the exact same quality of information as everybody else? Do they have to accept a non-official version of the official document? To me it looks like those agencies either have to fix their understanding of US federal law, or the law has to be fixed.

Also, having an annex in a PDF file with additional explanatory text for complex graphics and other such content (and links in the main content that point to it) has the following advantages:
- it doesn't get in the way of readers who do not need it
- it is always there, and is more likely to undergo various quality assurance mechanisms (information not visible by default, like Alt text, has a much higher rate of spelling errors, grammatical errors, inconsistency between entries, incorrect status/not updated after a change to content, and much more; if Alt were forced to be visible all the time for everyone, that rate of errors would likely go down to that of the rest of the document)
- it's not a special mechanism just for people with disabilities, rather, it is represented using the same mechanism available and used for "ordinary" content, and for every reader of the content
- it also does not need a special tool, one can create it in most document creation tools, whether Word, InDesign or something else; once someone understands the idea, it can be executed without further ado; no special tools or features required.
- having content fully available by default in a fashion that is natural for the technology (HTML, or PDF, or… ) used, will have an educational impact - more people will recognise and understand it exists, and might consider providing for such additional content in their own documents (or documents they have others create for them); and all that without sending them a teacher / accessibility trainer
- why not allow access to the additional explanatory information even with very simple PDF presenting tools, like a printer, or a cheap PDF viewer on a low cost ebook device (which likely will not offer much in terms of accessibility features). If it's there in them same way as any other content, it will always be there for everyone to consume at their discretion. Please keep in mind, such additional information is not only for people with very low or no vision.
- there is also one aspect that might hit PDF more than HTML: the only way in PDF to express content in a rich way is by using … PDF (as opposed to a plain text string; already Alt [and this applies to HTML as much as to PDF] has no mechanism to enrich the plaint text - no tags/no substructure, no attributes, no features like links leading to even more information or cross references etc.); so a longdesc attribute in the form of a plain text string is not up to the task

Now, if someone were to insist that a longdesc equivalent in the form of a plain text string must be introduced into PDF - the mechanism is already there. It is called XMP metadata. XMP metadata provide for a very rich mechanism to add information (which would not normally be visible) to visible page content. It can be associated with arbitrary objects, and with tags in the tagged PDF structure. Here a range of predefined metadata fields could be used, like dc:description (Dublin Core metadata field for description) or tiff:ImageDescription (EXIF metadata field for image description). It still wouldn't offer the richness of PDF (or HTM) content.

That much said, I would like to urge everyone to include additional explanations for graphical content in the same manner as the rest of the content: rendered by default, expressed in the same language (HTML for HTML, PDF for PDF) as the rest of the content, and not fall back to [1] just text that is [2] not normally visible/displayed/rendered.



Olaf



On 7 Dec 2014, at 04:55, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:

> 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
>
>
> > >

From: Chagnon | PubCom
Date: Sun, Dec 07 2014 12:13PM
Subject: Re: Longdesc and PDF (was:HTML5 Image DescriptionExtension (longdesc) is Proposed Recommendation)
← Previous message | Next message →

Thanks Olaf.
I agree with just about everything you said. (Wow, we've reached consensus
on something! grin)

Just to clarify: the US federal law about providing electronic versions of
all printed documents precedes Section 508 regulations. It was passed
sometime in the 1990s and was intended to provide electronic archival
versions of all published federal material. Essentially, the printed volumes
were deteriorating, and the original source files (word processing, desktop
publishing, etc.) were getting lost on a bazillion agency file servers.

So in that respect, that particular electronic version should match the
printed version, but I'm not a die-hard on this.

I have one concern that makes me hesitate about adding an appendix of
longdesc; in the sample I'm using (300+ pages with 100+ statistical charts)
it will add about 30-50 more pages to the printed document. My agencies
don't have the budget to cover those additional pages, so the idea has been
nixed by upper management. No additional money can be spent.

One option that has worked for some of these charts is to put a table with
the chart's data just below the graphical chart. This gives all readers,
disabled or not, access to the hard data and in a format that's navigable by
A.T. But again, that adds to the printed page count and therefore the cost
of printing and distributing.

XMP metadata might be the most efficient way to go, but heck, we don't even
have a predefined field for regular Alt-text, let alone longdesc!

Is there a chance that our WAI listmembers and Adobe's Andrew K can take
these ideas regarding XMP metadata back to the their camps? I'm told these
fields can't be added to their programs until the fields are standardized at
the international level. I'm under the impression that means ISO and
WAI/W3C, correct?

We need something to fix this shortcoming fairly quickly.

—Bevi
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
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 ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Olaf Drümmer
Sent: Sunday, December 07, 2014 7:30 AM
To: WebAIM Discussion List
Subject: [WebAIM] Longdesc and PDF (was: Re: HTML5 Image Description
Extension (longdesc) is Proposed Recommendation)

Hi Bevy,

thanks a lot for your detailed reply!

A clarification before we look at some of the details: with links I meant
PDF-internal links; I fully agree that the PDF file at hand must remain
self-contained.

One thing that scares me:
> 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


from my point of view there should not be a legal difference between
additional information whether encoded via a longdesc-like mechanism (it's
there, but not visible by default) and an annex (it's there and it is
visible by default). Do people with disabilities not have the right to the
exact same quality of information as everybody else? Do they have to accept
a non-official version of the official document? To me it looks like those
agencies either have to fix their understanding of US federal law, or the
law has to be fixed.

Also, having an annex in a PDF file with additional explanatory text for
complex graphics and other such content (and links in the main content that
point to it) has the following advantages:
- it doesn't get in the way of readers who do not need it
- it is always there, and is more likely to undergo various quality
assurance mechanisms (information not visible by default, like Alt text, has
a much higher rate of spelling errors, grammatical errors, inconsistency
between entries, incorrect status/not updated after a change to content, and
much more; if Alt were forced to be visible all the time for everyone, that
rate of errors would likely go down to that of the rest of the document)
- it's not a special mechanism just for people with disabilities, rather, it
is represented using the same mechanism available and used for "ordinary"
content, and for every reader of the content
- it also does not need a special tool, one can create it in most document
creation tools, whether Word, InDesign or something else; once someone
understands the idea, it can be executed without further ado; no special
tools or features required.
- having content fully available by default in a fashion that is natural for
the technology (HTML, or PDF, or… ) used, will have an educational impact -
more people will recognise and understand it exists, and might consider
providing for such additional content in their own documents (or documents
they have others create for them); and all that without sending them a
teacher / accessibility trainer
- why not allow access to the additional explanatory information even with
very simple PDF presenting tools, like a printer, or a cheap PDF viewer on a
low cost ebook device (which likely will not offer much in terms of
accessibility features). If it's there in them same way as any other
content, it will always be there for everyone to consume at their
discretion. Please keep in mind, such additional information is not only for
people with very low or no vision.
- there is also one aspect that might hit PDF more than HTML: the only way
in PDF to express content in a rich way is by using … PDF (as opposed to a
plain text string; already Alt [and this applies to HTML as much as to PDF]
has no mechanism to enrich the plaint text - no tags/no substructure, no
attributes, no features like links leading to even more information or cross
references etc.); so a longdesc attribute in the form of a plain text
string is not up to the task

Now, if someone were to insist that a longdesc equivalent in the form of a
plain text string must be introduced into PDF - the mechanism is already
there. It is called XMP metadata. XMP metadata provide for a very rich
mechanism to add information (which would not normally be visible) to
visible page content. It can be associated with arbitrary objects, and with
tags in the tagged PDF structure. Here a range of predefined metadata fields
could be used, like dc:description (Dublin Core metadata field for
description) or tiff:ImageDescription (EXIF metadata field for image
description). It still wouldn't offer the richness of PDF (or HTM) content.

That much said, I would like to urge everyone to include additional
explanations for graphical content in the same manner as the rest of the
content: rendered by default, expressed in the same language (HTML for HTML,
PDF for PDF) as the rest of the content, and not fall back to [1] just text
that is [2] not normally visible/displayed/rendered.



Olaf



On 7 Dec 2014, at 04:55, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = > wrote:

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

messages to = EMAIL ADDRESS REMOVED =

From: Jonathan Avila
Date: Mon, Dec 08 2014 6:48AM
Subject: Re: HTML5 Image Description Extension (longdesc) isProposed Recommendation
← Previous message | Next message →

> 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 ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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

From: Chagnon | PubCom
Date: Mon, Dec 08 2014 9:07AM
Subject: Re: HTML5 Image Description Extension (longdesc) is Proposed Recommendation
← Previous message | Next message →

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 ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
messages to = EMAIL ADDRESS REMOVED =

From: Jonathan Avila
Date: Mon, Dec 08 2014 9:12AM
Subject: Re: HTML5 Image Description Extension (longdesc) isProposed Recommendation
← Previous message | Next message →

> 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 ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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

From: L Snider
Date: Tue, Dec 09 2014 6:43AM
Subject: Re: HTML5 Image Description Extension (longdesc) is Proposed Recommendation
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = [mailto:
> = EMAIL ADDRESS 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED =
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > messages to = EMAIL ADDRESS REMOVED =
> > > >

From: Steve Faulkner
Date: Tue, Dec 09 2014 6:57AM
Subject: Re: HTML5 Image Description Extension (longdesc) is Proposed Recommendation
← Previous message | No next message

On 9 December 2014 at 13:43, L Snider < = EMAIL ADDRESS REMOVED = > wrote:

> 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 suggest using the most robust cross browser , cross AT method wherever
possible.

If a long description cannot be provided in page, provide a link to it that
is accessible to all.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;