WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: LongDesc for documents, not websites

for

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

From: Bevi Chagnon | PubCom
Date: Tue, Apr 19 2011 9:30PM
Subject: LongDesc for documents, not websites
No previous message | Next message →

This question comes up every time I teach my 508 classes to government
employees.
What’s the best way to handle Alt-text for complex graphics in MS Word and
PDF documents (not websites)?

My government clients have very complex graphics such as charts, graphs,
maps, technical drawings, floor plans, and flow charts. Standard Alt-text
isn’t sufficient to describe the details of the graphics.

The LongDesc attribute doesn’t work for these documents for these reasons:

1) The attribute requires that my clients know what the final website
location of the LongDesc webpage is, and this is impossible for them to know
while they are creating the M.S. Word or PDF file.

2) There is a lengthy approval process for all documents (usually months
away) so it’s not possible to know where the document will live on a file
server, website, or intranet while it’s under construction.

3) The I.T. department usually controls where the final document is stored,
not my clients who are making the document, and I.T. will not tell them 2-3
months in advance where that location will be. (Note, Federal security
requirements often affect this, too.)

4) There are often hundreds of these complex graphics in a document.

Writing the detailed description into the narrative of the document often
doesn’t work. The description alone can take up an entire page of narration
for very complex graphics, and therefore a long narration impairs sighted
readers (they’ll quickly lose interest in the document).

One idea we had was to repeat the complex graphics at the end of the
document along with a detailed narrative. In the main body of the document,
the graphic can have a normal text link to the back where the detailed
narrative is located.

Example:
Main body of the document <Figure>
Pie chart shows growth of x-y during 2010. <live link to the back page>Text
description of this chart is at the end of this document.

There are two significant drawbacks to this method:

1) It's very time consuming and impractical to construct this, especially
given the immense number of revisions that a government document goes
through before it is finalized. The live text links will eventually get out
of whack during the normal editing and revision process.

2) In these graphic-intensive documents, it could easily add a hundred or
more pages to the document because the graphics will appear twice, once in
the main body of the text and again in the back section with the detailed
description.

Any suggestions? Remember, these are Word and PDF documents, not websites.
Thanks in advance for your words of wisdom!

--Bevi Chagnon

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
Government publishing specialists, trainers, consultants | print, press,
web, Acrobat PDF & 508
April-May Classes: www.pubcom.com/classes Section 508 Accessibility for
Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :  
** It’s our 30th year! 1981-2011 **

From: Karlen Communications
Date: Wed, Apr 20 2011 4:51AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

For PDF I suggest using the ability to attach documents to a PDF. I also
point people to the Wright State University/Dayton Art Institute project "A
Picture is worth 300 Words" which was a CSUN presentation.
http://www.csun.edu/cod/conf/2001/proceedings/0031alonzo.htm

Although created for artwork, the guidelines can be used to build a
framework for describing complex images in documents so that the
descriptions don't become essays themselves.

For PDF this lets the descriptions travel with the PDF which means that
people don't have to go looking for them. As someone who uses a screen
reader I will seldom go looking for a description of something on another
web site. I just figure that it isn't important enough to travel with the
document. I also suggest using a TXT file to house the description or a
plain vanilla Word document without a lot of formatting/formatting as
needed. Of course I'm not in school depending on access to a textbook.

The Alt Text for the image is something like "detailed description attached:
filename X." If the document author has used captions I refer to the figure
number in the filename. Depending on how many complex images there are in a
document I may have a detail document for each image or one file with all
descriptions formatted with headings for navigation.

For Word documents the only suggestion I have is creating the actual link to
the Appendices once the document has been approved. Again I hate having to
go somewhere else on a server or site to read details of complex images or
other information. That is my preference but it has made me think about how
to integrate everything so that it is easy to find for everyone.

I also suggest that if someone is not going to use the Notes area of
PowerPoint that this area be used to provide the more detailed information
about an image on a slide. This is part of the decision making process in
determining how the PowerPoint document will be distributed and what types
of content are accessible or not given the distribution methods.

My PDF exploration in figuring out a solution for this type of content came
about when trying to make Visio based PDF accessible. I had a huge process
chart with tons of acronyms and abbreviations and the attachment of a plain
Word document with expanded acronyms and abbreviations made the chart easier
for everyone to understand.

Now your post has me considering a solution for this in Word. <smile>

Cheers, Karen

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bevi Chagnon |
PubCom
Sent: April-19-11 11:32 PM
To: WebAIM Discussion List
Subject: [WebAIM] LongDesc for documents, not websites

This question comes up every time I teach my 508 classes to government
employees.
What’s the best way to handle Alt-text for complex graphics in MS Word and
PDF documents (not websites)?

My government clients have very complex graphics such as charts, graphs,
maps, technical drawings, floor plans, and flow charts. Standard Alt-text
isn’t sufficient to describe the details of the graphics.

The LongDesc attribute doesn’t work for these documents for these reasons:

1) The attribute requires that my clients know what the final website
location of the LongDesc webpage is, and this is impossible for them to know
while they are creating the M.S. Word or PDF file.

2) There is a lengthy approval process for all documents (usually months
away) so it’s not possible to know where the document will live on a file
server, website, or intranet while it’s under construction.

3) The I.T. department usually controls where the final document is stored,
not my clients who are making the document, and I.T. will not tell them 2-3
months in advance where that location will be. (Note, Federal security
requirements often affect this, too.)

4) There are often hundreds of these complex graphics in a document.

Writing the detailed description into the narrative of the document often
doesn’t work. The description alone can take up an entire page of narration
for very complex graphics, and therefore a long narration impairs sighted
readers (they’ll quickly lose interest in the document).

One idea we had was to repeat the complex graphics at the end of the
document along with a detailed narrative. In the main body of the document,
the graphic can have a normal text link to the back where the detailed
narrative is located.

Example:
Main body of the document <Figure>
Pie chart shows growth of x-y during 2010. <live link to the back page>Text
description of this chart is at the end of this document.

There are two significant drawbacks to this method:

1) It's very time consuming and impractical to construct this, especially
given the immense number of revisions that a government document goes
through before it is finalized. The live text links will eventually get out
of whack during the normal editing and revision process.

2) In these graphic-intensive documents, it could easily add a hundred or
more pages to the document because the graphics will appear twice, once in
the main body of the text and again in the back section with the detailed
description.

Any suggestions? Remember, these are Word and PDF documents, not websites.
Thanks in advance for your words of wisdom!

--Bevi Chagnon

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805 Government
publishing specialists, trainers, consultants | print, press, web, Acrobat
PDF & 508 April-May Classes: www.pubcom.com/classes Section 508
Accessibility for Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :
** It’s our 30th year! 1981-2011 **

From: Will Grignon
Date: Wed, Apr 20 2011 5:48AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Why not create the master document and a description document? The blind
user can read the master and, when he/she encounters a described graphic,
ALT+TAB to the description document to get the full description, then
ALT+TAB back to the master to resume reading. I am a blind screen reader
user and it's a pain to jump to the back of a document to find an endnote
then jump back to where I had left off, but it is relatively easy to read a
master document, jump over to a secondary document, then jump back to the
master at the point I had left it to read the secondary document.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bevi Chagnon |
PubCom
Sent: Tuesday, April 19, 2011 11:32 PM
To: WebAIM Discussion List
Subject: [WebAIM] LongDesc for documents, not websites

This question comes up every time I teach my 508 classes to government
employees.
What’s the best way to handle Alt-text for complex graphics in MS Word and
PDF documents (not websites)?

My government clients have very complex graphics such as charts, graphs,
maps, technical drawings, floor plans, and flow charts. Standard Alt-text
isn’t sufficient to describe the details of the graphics.

The LongDesc attribute doesn’t work for these documents for these reasons:

1) The attribute requires that my clients know what the final website
location of the LongDesc webpage is, and this is impossible for them to know
while they are creating the M.S. Word or PDF file.

2) There is a lengthy approval process for all documents (usually months
away) so it’s not possible to know where the document will live on a file
server, website, or intranet while it’s under construction.

3) The I.T. department usually controls where the final document is stored,
not my clients who are making the document, and I.T. will not tell them 2-3
months in advance where that location will be. (Note, Federal security
requirements often affect this, too.)

4) There are often hundreds of these complex graphics in a document.

Writing the detailed description into the narrative of the document often
doesn’t work. The description alone can take up an entire page of narration
for very complex graphics, and therefore a long narration impairs sighted
readers (they’ll quickly lose interest in the document).

One idea we had was to repeat the complex graphics at the end of the
document along with a detailed narrative. In the main body of the document,
the graphic can have a normal text link to the back where the detailed
narrative is located.

Example:
Main body of the document <Figure>
Pie chart shows growth of x-y during 2010. <live link to the back page>Text
description of this chart is at the end of this document.

There are two significant drawbacks to this method:

1) It's very time consuming and impractical to construct this, especially
given the immense number of revisions that a government document goes
through before it is finalized. The live text links will eventually get out
of whack during the normal editing and revision process.

2) In these graphic-intensive documents, it could easily add a hundred or
more pages to the document because the graphics will appear twice, once in
the main body of the text and again in the back section with the detailed
description.

Any suggestions? Remember, these are Word and PDF documents, not websites.
Thanks in advance for your words of wisdom!

--Bevi Chagnon

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805 Government
publishing specialists, trainers, consultants | print, press, web, Acrobat
PDF & 508 April-May Classes: www.pubcom.com/classes Section 508
Accessibility for Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :
** It’s our 30th year! 1981-2011 **

From: Angela French
Date: Wed, Apr 20 2011 9:03AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Bev -
I would be inclined to put the long description at the back of the document as you described but without duplicating the graphic again. If the first appearance of the graphic has a Figure number, then I would just put the figure number at the end similar to a footnote. I would also put a link from the foot note back to the graphic to make returning to the place left off easier. Any reason why you feel the graphic must appear again?

Angela French





link to the back where the detailed narrative is located.

Example:
Main body of the document <Figure>
Pie chart shows growth of x-y during 2010. <live link to the back page>Text description of this chart is at the end of this document.

There are two significant drawbacks to this method:

1) It's very time consuming and impractical to construct this, especially given the immense number of revisions that a government document goes through before it is finalized. The live text links will eventually get out of whack during the normal editing and revision process.

2) In these graphic-intensive documents, it could easily add a hundred or more pages to the document because the graphics will appear twice, once in the main body of the text and again in the back section with the detailed description.

Any suggestions? Remember, these are Word and PDF documents, not websites.
Thanks in advance for your words of wisdom!

--Bevi Chagnon

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805 Government publishing specialists, trainers, consultants | print, press, web, Acrobat PDF & 508 April-May Classes: www.pubcom.com/classes Section 508 Accessibility for Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :
** It's our 30th year! 1981-2011 **

From: Karlen Communications
Date: Wed, Apr 20 2011 9:48AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

I like to keep the image and the document close together for people with
learning or cognitive disabilities so that it is right there for visual
reference. The image doesn't have to be large, just a reminder of which
image they needed the details for.

Sometimes moving back and forth loses your concentration especially in a
complex image heavy document.

Cheers, Karen

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Angela French
Sent: April-20-11 11:03 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] LongDesc for documents, not websites

Bev -
I would be inclined to put the long description at the back of the document
as you described but without duplicating the graphic again. If the first
appearance of the graphic has a Figure number, then I would just put the
figure number at the end similar to a footnote. I would also put a link
from the foot note back to the graphic to make returning to the place left
off easier. Any reason why you feel the graphic must appear again?

Angela French





link to the back where the detailed narrative is located.

Example:
Main body of the document <Figure>
Pie chart shows growth of x-y during 2010. <live link to the back page>Text
description of this chart is at the end of this document.

There are two significant drawbacks to this method:

1) It's very time consuming and impractical to construct this, especially
given the immense number of revisions that a government document goes
through before it is finalized. The live text links will eventually get out
of whack during the normal editing and revision process.

2) In these graphic-intensive documents, it could easily add a hundred or
more pages to the document because the graphics will appear twice, once in
the main body of the text and again in the back section with the detailed
description.

Any suggestions? Remember, these are Word and PDF documents, not websites.
Thanks in advance for your words of wisdom!

--Bevi Chagnon

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805 Government
publishing specialists, trainers, consultants | print, press, web, Acrobat
PDF & 508 April-May Classes: www.pubcom.com/classes Section 508
Accessibility for Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :
** It's our 30th year! 1981-2011 **

From: John E Brandt
Date: Wed, Apr 20 2011 11:27AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

I am not sure there is an easy answer here since there are many aspects to
your question that might be unique to the specific situation at hand. That
said, let me share the something my wise old dissertation chair used to
pound into us when he taught research design and we were writing tons of
research papers (I am paraphrasing):

...Tables and graphs are visual methods for communicating and supporting
what you have written in the narrative of your document. You never put
information into a table or graph and let the reader try to figure out what
it means or encourages them to draw their own conclusions...

I have always used the same philosophy in all of my writing whether it be in
a word processed document or an HTML document. And I have encouraged others
to do the same in workshops I have taught on the subject.

Now, there may be cases "in government work" where you do put out complex
charts and graphs or other objects that are intended to be used as "source
materials" for others to use, digest and interpret. My suggestion is that
all charted content should be provided in spreadsheet format with
appropriate labeling - or if in HTML, as a Table with appropriate coding.
Graphs would need a detailed explanation and there have been several
suggestions recommended already.

I will not comment on other objects such as images and ALT text or LongDesc
as that issue has been discussed - at length - in another thread.

Those are my two cents for what they are worth...

John E. Brandt
www.jebswebs.com
= EMAIL ADDRESS REMOVED =
207-622-7937
Augusta, Maine, USA

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bevi Chagnon |
PubCom
Sent: Tuesday, April 19, 2011 11:32 PM
To: WebAIM Discussion List
Subject: [WebAIM] LongDesc for documents, not websites

This question comes up every time I teach my 508 classes to government
employees.
What’s the best way to handle Alt-text for complex graphics in MS Word and
PDF documents (not websites)?

My government clients have very complex graphics such as charts, graphs,
maps, technical drawings, floor plans, and flow charts. Standard Alt-text
isn’t sufficient to describe the details of the graphics.

The LongDesc attribute doesn’t work for these documents for these reasons:

1) The attribute requires that my clients know what the final website
location of the LongDesc webpage is, and this is impossible for them to know
while they are creating the M.S. Word or PDF file.

2) There is a lengthy approval process for all documents (usually months
away) so it’s not possible to know where the document will live on a file
server, website, or intranet while it’s under construction.

3) The I.T. department usually controls where the final document is stored,
not my clients who are making the document, and I.T. will not tell them 2-3
months in advance where that location will be. (Note, Federal security
requirements often affect this, too.)

4) There are often hundreds of these complex graphics in a document.

Writing the detailed description into the narrative of the document often
doesn’t work. The description alone can take up an entire page of narration
for very complex graphics, and therefore a long narration impairs sighted
readers (they’ll quickly lose interest in the document).

One idea we had was to repeat the complex graphics at the end of the
document along with a detailed narrative. In the main body of the document,
the graphic can have a normal text link to the back where the detailed
narrative is located.

Example:
Main body of the document <Figure>
Pie chart shows growth of x-y during 2010. <live link to the back page>Text
description of this chart is at the end of this document.

There are two significant drawbacks to this method:

1) It's very time consuming and impractical to construct this, especially
given the immense number of revisions that a government document goes
through before it is finalized. The live text links will eventually get out
of whack during the normal editing and revision process.

2) In these graphic-intensive documents, it could easily add a hundred or
more pages to the document because the graphics will appear twice, once in
the main body of the text and again in the back section with the detailed
description.

Any suggestions? Remember, these are Word and PDF documents, not websites.
Thanks in advance for your words of wisdom!

--Bevi Chagnon

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805 Government
publishing specialists, trainers, consultants | print, press, web, Acrobat
PDF & 508 April-May Classes: www.pubcom.com/classes Section 508
Accessibility for Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :
** It’s our 30th year! 1981-2011 **

From: Bevi Chagnon | PubCom
Date: Wed, Apr 20 2011 9:48PM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

<< Why not create the master document and a description document? >>

These are government documents. Sometimes they're created by government
employees, and sometimes by outside contractors or subcontractors.
Consequently, there is no way to guarantee that the two documents will be
kept together by the next "pair of hands" that processes the document.

And since the information might not be uploaded to a website or intranet for
several months in the future, there is no way that the folks creating these
files can know in advance where that Web location will be. If only we had
such a crystal ball from the IT and Web gurus!

That's why it's imperative that the detailed descriptions be included with
the master document.

--Bevi
: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
Government publishing specialists, trainers, consultants | print, press,
web, Acrobat PDF & 508
March-May Classes: www.pubcom.com/classes Section 508 Accessibility for
Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :  
** It’s our 30th year! 1981-2011 **


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Will Grignon
Sent: Wednesday, April 20, 2011 7:30 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] LongDesc for documents, not websites

Why not create the master document and a description document? The blind
user can read the master and, when he/she encounters a described graphic,
ALT+TAB to the description document to get the full description, then
ALT+TAB back to the master to resume reading. I am a blind screen
ALT+reader
user and it's a pain to jump to the back of a document to find an endnote
then jump back to where I had left off, but it is relatively easy to read a
master document, jump over to a secondary document, then jump back to the
master at the point I had left it to read the secondary document.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bevi Chagnon |
PubCom
Sent: Tuesday, April 19, 2011 11:32 PM
To: WebAIM Discussion List
Subject: [WebAIM] LongDesc for documents, not websites

This question comes up every time I teach my 508 classes to government
employees.
What’s the best way to handle Alt-text for complex graphics in MS Word and
PDF documents (not websites)?

My government clients have very complex graphics such as charts, graphs,
maps, technical drawings, floor plans, and flow charts. Standard Alt-text
isn’t sufficient to describe the details of the graphics.

The LongDesc attribute doesn’t work for these documents for these reasons:

1) The attribute requires that my clients know what the final website
location of the LongDesc webpage is, and this is impossible for them to know
while they are creating the M.S. Word or PDF file.

2) There is a lengthy approval process for all documents (usually months
away) so it’s not possible to know where the document will live on a file
server, website, or intranet while it’s under construction.

3) The I.T. department usually controls where the final document is stored,
not my clients who are making the document, and I.T. will not tell them 2-3
months in advance where that location will be. (Note, Federal security
requirements often affect this, too.)

4) There are often hundreds of these complex graphics in a document.

Writing the detailed description into the narrative of the document often
doesn’t work. The description alone can take up an entire page of narration
for very complex graphics, and therefore a long narration impairs sighted
readers (they’ll quickly lose interest in the document).

One idea we had was to repeat the complex graphics at the end of the
document along with a detailed narrative. In the main body of the document,
the graphic can have a normal text link to the back where the detailed
narrative is located.

Example:
Main body of the document <Figure>
Pie chart shows growth of x-y during 2010. <live link to the back page>Text
description of this chart is at the end of this document.

There are two significant drawbacks to this method:

1) It's very time consuming and impractical to construct this, especially
given the immense number of revisions that a government document goes
through before it is finalized. The live text links will eventually get out
of whack during the normal editing and revision process.

2) In these graphic-intensive documents, it could easily add a hundred or
more pages to the document because the graphics will appear twice, once in
the main body of the text and again in the back section with the detailed
description.

Any suggestions? Remember, these are Word and PDF documents, not websites.
Thanks in advance for your words of wisdom!

--Bevi Chagnon

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805 Government
publishing specialists, trainers, consultants | print, press, web, Acrobat
PDF & 508 April-May Classes: www.pubcom.com/classes Section 508
Accessibility for Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :
** It’s our 30th year! 1981-2011 **

From: Bevi Chagnon | PubCom
Date: Wed, Apr 20 2011 9:54PM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Thanks Jeb for your comments.

RE: charts and graphics, yes, I agree. The actual data can be presented in a
table below the visual chart or graph. That gives many benefits such as:
1. Data is easily navigated by AT.
2. Info is probably more efficiently conveyed via a table than via a
narrative description.
3. Keeps the data with the chart in the same document, which eliminates the
IT/web storage issue for government publishers.

Now on to figuring out what to do with PDFs and Word documents of maps,
floorplans, and engineering drawings!

<LongDesc> won't work for this situation: by W3C definition, that attribute
refers to a URL where the long description is stored.

Since these are government documents created by federal employees,
contractors and subcontractors who have no control over their agency's
website, they do not know the URL in advance and therefore can't refer to it
in a <LongDesc> attribute.

Well, not unless they had a crystal ball or bribed the web weenies with
donuts and coffee! <grin>

--Bevi
___________________
Bevi Chagnon / PubCom
Government publishing specialists, trainers, consultants
Print, press, web, Acrobat PDF and 508
April-May Classes: www.pubcom.com/classes Section 508 Accessibility for
Word, InDesign, and Acrobat PDF

From: Jeevan Reddy
Date: Thu, Apr 21 2011 1:54AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Hello Grignon,
I appreciate your thought, but remember accessibility is not only for
Screen reader users. Why you need so many jumpings?
As our other experts said, i suggest to use a "discription" link at end of
each graph or chart, once the user click on description, it'll take you to
the description in the same page, where two "back" links one to resumed
position and another to top take you to the resumed position and top
respectively.
This will benefit:
1 A screen reader user can locate the description of the graph or chart
easily.
2 A cognitive user can look the description of the chart or graph easily.
3 A motor impaired user can locate descriptions with minimal keystrokes if
he/she needed.
4 Benefits every one by reducing document scrolling.

Best Regards,

On Wed, Apr 20, 2011 at 4:59 PM, Will Grignon < = EMAIL ADDRESS REMOVED = >wrote:

> Why not create the master document and a description document? The blind
> user can read the master and, when he/she encounters a described graphic,
> ALT+TAB to the description document to get the full description, then
> ALT+TAB back to the master to resume reading. I am a blind screen reader
> user and it's a pain to jump to the back of a document to find an endnote
> then jump back to where I had left off, but it is relatively easy to read a
> master document, jump over to a secondary document, then jump back to the
> master at the point I had left it to read the secondary document.
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bevi Chagnon |
> PubCom
> Sent: Tuesday, April 19, 2011 11:32 PM
> To: WebAIM Discussion List
> Subject: [WebAIM] LongDesc for documents, not websites
>
> This question comes up every time I teach my 508 classes to government
> employees.
> What’s the best way to handle Alt-text for complex graphics in MS Word and
> PDF documents (not websites)?
>
> My government clients have very complex graphics such as charts, graphs,
> maps, technical drawings, floor plans, and flow charts. Standard Alt-text
> isn’t sufficient to describe the details of the graphics.
>
> The LongDesc attribute doesn’t work for these documents for these reasons:
>
> 1) The attribute requires that my clients know what the final website
> location of the LongDesc webpage is, and this is impossible for them to
> know
> while they are creating the M.S. Word or PDF file.
>
> 2) There is a lengthy approval process for all documents (usually months
> away) so it’s not possible to know where the document will live on a file
> server, website, or intranet while it’s under construction.
>
> 3) The I.T. department usually controls where the final document is stored,
> not my clients who are making the document, and I.T. will not tell them 2-3
> months in advance where that location will be. (Note, Federal security
> requirements often affect this, too.)
>
> 4) There are often hundreds of these complex graphics in a document.
>
> Writing the detailed description into the narrative of the document often
> doesn’t work. The description alone can take up an entire page of narration
> for very complex graphics, and therefore a long narration impairs sighted
> readers (they’ll quickly lose interest in the document).
>
> One idea we had was to repeat the complex graphics at the end of the
> document along with a detailed narrative. In the main body of the document,
> the graphic can have a normal text link to the back where the detailed
> narrative is located.
>
> Example:
> Main body of the document <Figure>
> Pie chart shows growth of x-y during 2010. <live link to the back page>Text
> description of this chart is at the end of this document.
>
> There are two significant drawbacks to this method:
>
> 1) It's very time consuming and impractical to construct this, especially
> given the immense number of revisions that a government document goes
> through before it is finalized. The live text links will eventually get out
> of whack during the normal editing and revision process.
>
> 2) In these graphic-intensive documents, it could easily add a hundred or
> more pages to the document because the graphics will appear twice, once in
> the main body of the text and again in the back section with the detailed
> description.
>
> Any suggestions? Remember, these are Word and PDF documents, not websites.
> Thanks in advance for your words of wisdom!
>
> --Bevi Chagnon
>
> : : : : : : : : : : : : : : : : : : :
> : : : : : : : : : : : : :
> Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805 Government
> publishing specialists, trainers, consultants | print, press, web, Acrobat
> PDF & 508 April-May Classes: www.pubcom.com/classes Section 508
> Accessibility for Word, InDesign, and Acrobat PDF
> : : : : : : : : : : : : : :
> ** It’s our 30th year! 1981-2011 **
>
>
>
>

From: Giovanni Duarte
Date: Thu, Apr 21 2011 6:24AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

The approach mentioned below is what we do in our online courses. The
difference is that we have developed a JavaScript that allows us to use the
"hide and show" function. In this way the user is not taken out of the page
and the description is available to anyone. The student clicks on the
"transcript" link and this expands a section within the page that shows the
description.
The four points mentioned below are very valid and I agree that when
considering accessibility we are talking not only about blind users but for
everyone.

Thanks,
Giovanni.


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jeevan Reddy
Sent: Thursday, April 21, 2011 2:46 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] LongDesc for documents, not websites

Hello Grignon,
I appreciate your thought, but remember accessibility is not only for
Screen reader users. Why you need so many jumpings?
As our other experts said, i suggest to use a "discription" link at end of
each graph or chart, once the user click on description, it'll take you to
the description in the same page, where two "back" links one to resumed
position and another to top take you to the resumed position and top
respectively.
This will benefit:
1 A screen reader user can locate the description of the graph or chart
easily.
2 A cognitive user can look the description of the chart or graph easily.
3 A motor impaired user can locate descriptions with minimal keystrokes if
he/she needed.
4 Benefits every one by reducing document scrolling.

Best Regards,

On Wed, Apr 20, 2011 at 4:59 PM, Will Grignon
< = EMAIL ADDRESS REMOVED = >wrote:

> Why not create the master document and a description document? The
> blind user can read the master and, when he/she encounters a described
> graphic,
> ALT+TAB to the description document to get the full description, then
> ALT+TAB back to the master to resume reading. I am a blind screen
> ALT+reader
> user and it's a pain to jump to the back of a document to find an
> endnote then jump back to where I had left off, but it is relatively
> easy to read a master document, jump over to a secondary document,
> then jump back to the master at the point I had left it to read the
secondary document.
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bevi
> Chagnon | PubCom
> Sent: Tuesday, April 19, 2011 11:32 PM
> To: WebAIM Discussion List
> Subject: [WebAIM] LongDesc for documents, not websites
>
> This question comes up every time I teach my 508 classes to government
> employees.
> What's the best way to handle Alt-text for complex graphics in MS Word
> and PDF documents (not websites)?
>
> My government clients have very complex graphics such as charts,
> graphs, maps, technical drawings, floor plans, and flow charts.
> Standard Alt-text isn't sufficient to describe the details of the
graphics.
>
> The LongDesc attribute doesn't work for these documents for these reasons:
>
> 1) The attribute requires that my clients know what the final website
> location of the LongDesc webpage is, and this is impossible for them
> to know while they are creating the M.S. Word or PDF file.
>
> 2) There is a lengthy approval process for all documents (usually
> months
> away) so it's not possible to know where the document will live on a
> file server, website, or intranet while it's under construction.
>
> 3) The I.T. department usually controls where the final document is
> stored, not my clients who are making the document, and I.T. will not
> tell them 2-3 months in advance where that location will be. (Note,
> Federal security requirements often affect this, too.)
>
> 4) There are often hundreds of these complex graphics in a document.
>
> Writing the detailed description into the narrative of the document
> often doesn't work. The description alone can take up an entire page
> of narration for very complex graphics, and therefore a long narration
> impairs sighted readers (they'll quickly lose interest in the document).
>
> One idea we had was to repeat the complex graphics at the end of the
> document along with a detailed narrative. In the main body of the
> document, the graphic can have a normal text link to the back where
> the detailed narrative is located.
>
> Example:
> Main body of the document <Figure>
> Pie chart shows growth of x-y during 2010. <live link to the back
> page>Text description of this chart is at the end of this document.
>
> There are two significant drawbacks to this method:
>
> 1) It's very time consuming and impractical to construct this,
> especially given the immense number of revisions that a government
> document goes through before it is finalized. The live text links will
> eventually get out of whack during the normal editing and revision
process.
>
> 2) In these graphic-intensive documents, it could easily add a hundred
> or more pages to the document because the graphics will appear twice,
> once in the main body of the text and again in the back section with
> the detailed description.
>
> Any suggestions? Remember, these are Word and PDF documents, not websites.
> Thanks in advance for your words of wisdom!
>
> --Bevi Chagnon
>
> : : : : : : : : : : : : : : : : : : :
> : : : : : : : : : : : : :
> Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
> Government publishing specialists, trainers, consultants | print,
> press, web, Acrobat PDF & 508 April-May Classes:
> www.pubcom.com/classes Section 508 Accessibility for Word, InDesign, and
Acrobat PDF
> : : : : : : : : : : : : : :
> ** It's our 30th year! 1981-2011 **
>
>
>
>

From: Bevi Chagnon | PubCom
Date: Thu, Apr 21 2011 6:51AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Just to reiterate, the solution must work for stand alone documents (mainly
Word and PDF files), as well as websites.
Also, the people creating these documents have no control over the
government agency's website and where the documents will eventually reside
on the site.

--Bevi

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
Government publishing specialists, trainers, consultants | print, press,
web, Acrobat PDF & 508
March-May Classes: www.pubcom.com/classes Section 508 Accessibility for
Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :  
** It’s our 30th year! 1981-2011 **

-----Original Message-----
The approach mentioned below is what we do in our online courses. The
difference is that we have developed a JavaScript that allows us to use the
"hide and show" function. In this way the user is not taken out of the page
and the description is available to anyone. The student clicks on the
"transcript" link and this expands a section within the page that shows the
description.
The four points mentioned below are very valid and I agree that when
considering accessibility we are talking not only about blind users but for
everyone.

Thanks,
Giovanni.

-----Original Message-----

Hello Grignon,
I appreciate your thought, but remember accessibility is not only for
Screen reader users. Why you need so many jumpings?
As our other experts said, i suggest to use a "discription" link at end of
each graph or chart, once the user click on description, it'll take you to
the description in the same page, where two "back" links one to resumed
position and another to top take you to the resumed position and top
respectively.
This will benefit:
1 A screen reader user can locate the description of the graph or chart
easily.
2 A cognitive user can look the description of the chart or graph easily.
3 A motor impaired user can locate descriptions with minimal keystrokes if
he/she needed.
4 Benefits every one by reducing document scrolling.

Best Regards,

On Wed, Apr 20, 2011 at 4:59 PM, Will Grignon
< = EMAIL ADDRESS REMOVED = >wrote:

> Why not create the master document and a description document? The
> blind user can read the master and, when he/she encounters a described
> graphic,
> ALT+TAB to the description document to get the full description, then
> ALT+TAB back to the master to resume reading. I am a blind screen
> ALT+reader
> user and it's a pain to jump to the back of a document to find an
> endnote then jump back to where I had left off, but it is relatively
> easy to read a master document, jump over to a secondary document,
> then jump back to the master at the point I had left it to read the
secondary document.

From: Vlad Alexander (XStandard)
Date: Thu, Apr 21 2011 9:48AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Bevi wrote "Also, the people creating these documents have no control over the government agency's website and where the documents will eventually reside on the site."

Sounds like a workflow problem rather than a longdesc problem. One solution is for your department to create a URL redirect service similar to TinyURL - let's call it GovURL for the purposes of this discussion.

1. Through GovURL, create URLs that will work as placeholders to these documents. For example:

http://govurl.gov/a6je9 = http://pubcom.com/temp/doc1.doc
http://govurl.gov/9h37d = http://pubcom.com/temp/doc2.pdf
http://govurl.gov/kd8u3 = [no url yet]

2. Use the URLs above in the longdesc attributes.

3. When the final destination of description documents is determined, modify the target URLs in GovURL service.

Regards,
-Vlad
http://xstandard.com


----- Original Message -----
From: = EMAIL ADDRESS REMOVED =
To: = EMAIL ADDRESS REMOVED =
Sent: 2011-04-21T05:50:34
Subject: Re: [WebAIM] LongDesc for documents, not websites

Just to reiterate, the solution must work for stand alone documents (mainly
Word and PDF files), as well as websites.
Also, the people creating these documents have no control over the
government agency's website and where the documents will eventually reside
on the site.

--Bevi

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
Government publishing specialists, trainers, consultants | print, press,
web, Acrobat PDF & 508
March-May Classes: www.pubcom.com/classes Section 508 Accessibility for
Word, InDesign, and Acrobat PDF
:�� :�� :�� :�� :�� :�� :�� :�� :�� :�� :�� :�� :�� :��
** It?s our 30th year! 1981-2011 **

-----Original Message-----
The approach mentioned below is what we do in our online courses. The
difference is that we have developed a JavaScript that allows us to use the
"hide and show" function. In this way the user is not taken out of the page
and the description is available to anyone. The student clicks on the
"transcript" link and this expands a section within the page that shows the
description.
The four points mentioned below are very valid and I agree that when
considering accessibility we are talking not only about blind users but for
everyone.

Thanks,
Giovanni.

-----Original Message-----

Hello Grignon,
I appreciate your thought, but remember accessibility is not only for
Screen reader users. Why you need so many jumpings?
As our other experts said, i suggest to use a "discription" link at end of
each graph or chart, once the user click on description, it'll take you to
the description in the same page, where two "back" links one to resumed
position and another to top take you to the resumed position and top
respectively.
This will benefit:
1 A screen reader user can locate the description of the graph or chart
easily.
2 A cognitive user can look the description of the chart or graph easily.
3 A motor impaired user can locate descriptions with minimal keystrokes if
he/she needed.
4 Benefits every one by reducing document scrolling.

Best Regards,

On Wed, Apr 20, 2011 at 4:59 PM, Will Grignon
< = EMAIL ADDRESS REMOVED = >wrote:

> Why not create the master document and a description document? The
> blind user can read the master and, when he/she encounters a described
> graphic,
> ALT+TAB to the description document to get the full description, then
> ALT+TAB back to the master to resume reading. I am a blind screen
> ALT+reader
> user and it's a pain to jump to the back of a document to find an
> endnote then jump back to where I had left off, but it is relatively
> easy to read a master document, jump over to a secondary document,
> then jump back to the master at the point I had left it to read the
secondary document.

From: Duff Johnson
Date: Thu, Apr 21 2011 10:03AM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Bevi,

As Karen suggested, why not a PDF with attachments? This approach would appear to meet your needs since it features the following attributes:

1) Stand-alone (No dependencies on government (or other) websites)
2) Non-technical (ie, easy for end-users with good PDF manipulation software)
3) The "connection" persists irrespective of location, network availability, etc, etc.

Duff Johnson, CEO
Appligent Document Solutions

22 E. Baltimore Ave
Lansdowne, PA 19050
+1 610 284 4006
+1 617 553 1934 (direct)
= EMAIL ADDRESS REMOVED =
http://www.appligent.com
http://www.twitter.com/duffjohnson



On Apr 21, 2011, at 8:52 AM, Bevi Chagnon | PubCom wrote:

> Just to reiterate, the solution must work for stand alone documents (mainly
> Word and PDF files), as well as websites.
> Also, the people creating these documents have no control over the
> government agency's website and where the documents will eventually reside
> on the site.
>
> --Bevi
>
> : : : : : : : : : : : : : : : : : : :
> : : : : : : : : : : : : :
> Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
> Government publishing specialists, trainers, consultants | print, press,
> web, Acrobat PDF & 508
> March-May Classes: www.pubcom.com/classes Section 508 Accessibility for
> Word, InDesign, and Acrobat PDF
> : : : : : : : : : : : : : :
> ** It’s our 30th year! 1981-2011 **
>
> -----Original Message-----
> The approach mentioned below is what we do in our online courses. The
> difference is that we have developed a JavaScript that allows us to use the
> "hide and show" function. In this way the user is not taken out of the page
> and the description is available to anyone. The student clicks on the
> "transcript" link and this expands a section within the page that shows the
> description.
> The four points mentioned below are very valid and I agree that when
> considering accessibility we are talking not only about blind users but for
> everyone.
>
> Thanks,
> Giovanni.
>
> -----Original Message-----
>
> Hello Grignon,
> I appreciate your thought, but remember accessibility is not only for
> Screen reader users. Why you need so many jumpings?
> As our other experts said, i suggest to use a "discription" link at end of
> each graph or chart, once the user click on description, it'll take you to
> the description in the same page, where two "back" links one to resumed
> position and another to top take you to the resumed position and top
> respectively.
> This will benefit:
> 1 A screen reader user can locate the description of the graph or chart
> easily.
> 2 A cognitive user can look the description of the chart or graph easily.
> 3 A motor impaired user can locate descriptions with minimal keystrokes if
> he/she needed.
> 4 Benefits every one by reducing document scrolling.
>
> Best Regards,
>
> On Wed, Apr 20, 2011 at 4:59 PM, Will Grignon
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Why not create the master document and a description document? The
>> blind user can read the master and, when he/she encounters a described
>> graphic,
>> ALT+TAB to the description document to get the full description, then
>> ALT+TAB back to the master to resume reading. I am a blind screen
>> ALT+reader
>> user and it's a pain to jump to the back of a document to find an
>> endnote then jump back to where I had left off, but it is relatively
>> easy to read a master document, jump over to a secondary document,
>> then jump back to the master at the point I had left it to read the
> secondary document.
>
>
>

From: Bevi Chagnon | PubCom
Date: Thu, Apr 21 2011 8:24PM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Thanks, Duff and Karen.
I think a PDF with attachments might work.

But what about Word documents?

--Bevi

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
Government publishing specialists, trainers, consultants | print, press,
web, Acrobat PDF & 508
March-May Classes: www.pubcom.com/classes Section 508 Accessibility for
Word, InDesign, and Acrobat PDF
:   :   :   :   :   :   :   :   :   :   :   :   :   :  
** It’s our 30th year! 1981-2011 **

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Duff Johnson
Sent: Thursday, April 21, 2011 12:00 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] LongDesc for documents, not websites

Bevi,

As Karen suggested, why not a PDF with attachments? This approach would
appear to meet your needs since it features the following attributes:

1) Stand-alone (No dependencies on government (or other) websites)
2) Non-technical (ie, easy for end-users with good PDF manipulation
software)
3) The "connection" persists irrespective of location, network
availability, etc, etc.

Duff Johnson, CEO
Appligent Document Solutions

22 E. Baltimore Ave
Lansdowne, PA 19050
+1 610 284 4006
+1 617 553 1934 (direct)
= EMAIL ADDRESS REMOVED =
http://www.appligent.com
http://www.twitter.com/duffjohnson



On Apr 21, 2011, at 8:52 AM, Bevi Chagnon | PubCom wrote:

> Just to reiterate, the solution must work for stand alone documents
> (mainly Word and PDF files), as well as websites.
> Also, the people creating these documents have no control over the
> government agency's website and where the documents will eventually
> reside on the site.
>
> --Bevi
>
> : : : : : : : : : : : : : : : : : : :
> : : : : : : : : : : : : :
> Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
> Government publishing specialists, trainers, consultants | print,
> press, web, Acrobat PDF & 508 March-May Classes:
> www.pubcom.com/classes Section 508 Accessibility for Word, InDesign,
> and Acrobat PDF
> : : : : : : : : : : : : : :
> ** It’s our 30th year! 1981-2011 **
>
> -----Original Message-----
> The approach mentioned below is what we do in our online courses. The
> difference is that we have developed a JavaScript that allows us to
> use the "hide and show" function. In this way the user is not taken
> out of the page and the description is available to anyone. The
> student clicks on the "transcript" link and this expands a section
> within the page that shows the description.
> The four points mentioned below are very valid and I agree that when
> considering accessibility we are talking not only about blind users
> but for everyone.
>
> Thanks,
> Giovanni.
>
> -----Original Message-----
>
> Hello Grignon,
> I appreciate your thought, but remember accessibility is not only
> for Screen reader users. Why you need so many jumpings?
> As our other experts said, i suggest to use a "discription" link at
> end of each graph or chart, once the user click on description, it'll
> take you to the description in the same page, where two "back" links
> one to resumed position and another to top take you to the resumed
> position and top respectively.
> This will benefit:
> 1 A screen reader user can locate the description of the graph or
> chart easily.
> 2 A cognitive user can look the description of the chart or graph easily.
> 3 A motor impaired user can locate descriptions with minimal
> keystrokes if he/she needed.
> 4 Benefits every one by reducing document scrolling.
>
> Best Regards,
>
> On Wed, Apr 20, 2011 at 4:59 PM, Will Grignon
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Why not create the master document and a description document? The
>> blind user can read the master and, when he/she encounters a
>> described graphic,
>> ALT+TAB to the description document to get the full description, then
>> ALT+TAB back to the master to resume reading. I am a blind screen
>> ALT+reader
>> user and it's a pain to jump to the back of a document to find an
>> endnote then jump back to where I had left off, but it is relatively
>> easy to read a master document, jump over to a secondary document,
>> then jump back to the master at the point I had left it to read the
> secondary document.
>
>
>

From: Bevi Chagnon | PubCom
Date: Thu, Apr 21 2011 8:36PM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Vlad wrote:
" Sounds like a workflow problem rather than a longdesc problem"

Hmm. Have you worked on a federal government website with millions of pages with national security requirements? <grin>

The URL redirect could work, but is likely to have several stumbling blocks.
1) The tasks would be performed by 2 distinct groups of people, the document creators and the web team.
2) Successfully coordinating these 2 teams over the course of several months is dicey.
3) At some agencies, a web team will process several hundred documents a day. It's quite likely that they'll overlook changing the 100+ URL redirects in one PDF out of the many other documents they process that day.

I think this can be a viable solution for a smaller organization with tighter work teams, and I'll keep it as an option.

Thanks,
--Bevi
___________________
Bevi Chagnon / PubCom
Government publishing specialists, trainers, consultants
Print, press, web, Acrobat PDF and 508
April-May Classes: www.pubcom.com/classes Section 508 Accessibility for Word, InDesign, and Acrobat PDF

From: Vlad Alexander (XStandard)
Date: Thu, Apr 21 2011 10:18PM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

> Hmm. Have you worked on a federal government website with millions of pages
> with national security requirements? <grin>
As it happens, for the past 11 years I have worked closely with a Canadian federal government department who has been using a CMS that I wrote. And I've worked on a project building a Web-based app for the US Department of Defense. <grin>

Regards,
-Vlad




----- Original Message -----
From: = EMAIL ADDRESS REMOVED =
To: = EMAIL ADDRESS REMOVED =
Sent: 2011-04-21T19:32:44
Subject: Re: [WebAIM] LongDesc for documents, not websites

Vlad wrote:
" Sounds like a workflow problem rather than a longdesc problem"

Hmm. Have you worked on a federal government website with millions of pages with national security requirements? <grin>

The URL redirect could work, but is likely to have several stumbling blocks.
1) The tasks would be performed by 2 distinct groups of people, the document creators and the web team.
2) Successfully coordinating these 2 teams over the course of several months is dicey.
3) At some agencies, a web team will process several hundred documents a day. It's quite likely that they'll overlook changing the 100+ URL redirects in one PDF out of the many other documents they process that day.

I think this can be a viable solution for a smaller organization with tighter work teams, and I'll keep it as an option.

Thanks,
--Bevi
___________________
Bevi Chagnon / PubCom
Government publishing specialists, trainers, consultants
Print, press, web, Acrobat PDF and 508
April-May Classes: www.pubcom.com/classes Section 508 Accessibility for Word, InDesign, and Acrobat PDF

From: Duff Johnson
Date: Thu, Apr 21 2011 10:30PM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Bevi,

> Thanks, Duff and Karen.
> I think a PDF with attachments might work.
>
> But what about Word documents?

I'm going to take a page from Vlad's book and say... "well, that's a workflow matter".

Why post a Word file if you can post a good PDF file instead? :)

"Post PDFs!", after all, is going to be a lot easier sale, workflow-wise than "re-invent government so it works like small business".

Final-form electronic documents are almost by-definition PDF files - or so I'd contend. A Word file has lots of appropriate functions - being posted as a formal document on a formal (ie, government) website generally isn't one of them.

(awaits slings and arrows)

Duff Johnson, CEO
Appligent Document Solutions

22 E. Baltimore Ave
Lansdowne, PA 19050
+1 610 284 4006
+1 617 553 1934 (direct)
= EMAIL ADDRESS REMOVED =
http://www.appligent.com
http://www.twitter.com/duffjohnson




> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Duff Johnson
> Sent: Thursday, April 21, 2011 12:00 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] LongDesc for documents, not websites
>
> Bevi,
>
> As Karen suggested, why not a PDF with attachments? This approach would
> appear to meet your needs since it features the following attributes:
>
> 1) Stand-alone (No dependencies on government (or other) websites)
> 2) Non-technical (ie, easy for end-users with good PDF manipulation
> software)
> 3) The "connection" persists irrespective of location, network
> availability, etc, etc.
>
> Duff Johnson, CEO
> Appligent Document Solutions
>
> 22 E. Baltimore Ave
> Lansdowne, PA 19050
> +1 610 284 4006
> +1 617 553 1934 (direct)
> = EMAIL ADDRESS REMOVED =
> http://www.appligent.com
> http://www.twitter.com/duffjohnson
>
>
>
> On Apr 21, 2011, at 8:52 AM, Bevi Chagnon | PubCom wrote:
>
>> Just to reiterate, the solution must work for stand alone documents
>> (mainly Word and PDF files), as well as websites.
>> Also, the people creating these documents have no control over the
>> government agency's website and where the documents will eventually
>> reside on the site.
>>
>> --Bevi
>>
>> : : : : : : : : : : : : : : : : : : :
>> : : : : : : : : : : : : :
>> Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
>> Government publishing specialists, trainers, consultants | print,
>> press, web, Acrobat PDF & 508 March-May Classes:
>> www.pubcom.com/classes Section 508 Accessibility for Word, InDesign,
>> and Acrobat PDF
>> : : : : : : : : : : : : : :
>> ** It’s our 30th year! 1981-2011 **
>>
>> -----Original Message-----
>> The approach mentioned below is what we do in our online courses. The
>> difference is that we have developed a JavaScript that allows us to
>> use the "hide and show" function. In this way the user is not taken
>> out of the page and the description is available to anyone. The
>> student clicks on the "transcript" link and this expands a section
>> within the page that shows the description.
>> The four points mentioned below are very valid and I agree that when
>> considering accessibility we are talking not only about blind users
>> but for everyone.
>>
>> Thanks,
>> Giovanni.
>>
>> -----Original Message-----
>>
>> Hello Grignon,
>> I appreciate your thought, but remember accessibility is not only
>> for Screen reader users. Why you need so many jumpings?
>> As our other experts said, i suggest to use a "discription" link at
>> end of each graph or chart, once the user click on description, it'll
>> take you to the description in the same page, where two "back" links
>> one to resumed position and another to top take you to the resumed
>> position and top respectively.
>> This will benefit:
>> 1 A screen reader user can locate the description of the graph or
>> chart easily.
>> 2 A cognitive user can look the description of the chart or graph easily.
>> 3 A motor impaired user can locate descriptions with minimal
>> keystrokes if he/she needed.
>> 4 Benefits every one by reducing document scrolling.
>>
>> Best Regards,
>>
>> On Wed, Apr 20, 2011 at 4:59 PM, Will Grignon
>> < = EMAIL ADDRESS REMOVED = >wrote:
>>
>>> Why not create the master document and a description document? The
>>> blind user can read the master and, when he/she encounters a
>>> described graphic,
>>> ALT+TAB to the description document to get the full description, then
>>> ALT+TAB back to the master to resume reading. I am a blind screen
>>> ALT+reader
>>> user and it's a pain to jump to the back of a document to find an
>>> endnote then jump back to where I had left off, but it is relatively
>>> easy to read a master document, jump over to a secondary document,
>>> then jump back to the master at the point I had left it to read the
>> secondary document.
>>
>>
>>

From: Bevi Chagnon | PubCom
Date: Thu, Apr 21 2011 11:39PM
Subject: Re: LongDesc for documents, not websites
← Previous message | Next message →

Duff wrote:
" Why post a Word file if you can post a good PDF file instead? :) "

When the document is a work in progress, PDF isn't feasible. An editable
file (a REAL editable file, not the pseudo-editing capabilities in PDF) is
needed as the document is developed, reviewed, and approved. Plus,
government agencies use Word's track changes as an electronic paper trail
throughout the life of the document. Only after it's approved and finalized
does it become a PDF, and usually both the PDF and the Word source file are
stored somewhere on a server or intranet.

Many government documents never become PDFs but stay as Word documents. A
good example are templates for reports, forms, publications, fact sheets,
and research.

So a PDF file is like a one-size-fits-all shirt: it fits some people, but it
really doesn't fit all.

My interpretation of Section 508 standards (well, the forthcoming ones) is
that all information and communication technology must be accessible. So
that includes the working source files (namely Word) and a final PDF.

Given that one of the original intents of Section 508 was to give disabled
federal employees equal access to government information so that they can do
their job, it then doesn't make sense to have only the final PDF accessible
but not the working source file. If the working source file isn't
accessible, that means disabled federal employees aren't able to be on the
work team that is creating that source file.

Granted, it might not be feasible to make all working documents fully
accessible, but there should be a valid attempt to do so.

In sum, a good accessible PDF is fine for part of the workflow, but not the
entire workflow.

--Bevi

P.S. " Final-form electronic documents are almost by-definition PDF files -
or so I'd contend."
Wow, do I disagree! Not from an editor's or designer's viewpoint, that's for
sure.
___________________
Bevi Chagnon / PubCom
Government publishing specialists, trainers, consultants
Print, press, web, Acrobat PDF and 508
April-May Classes: www.pubcom.com/classes Section 508 Accessibility for
Word, InDesign, and Acrobat PDF

From: Duff Johnson
Date: Fri, Apr 22 2011 6:27AM
Subject: Re: LongDesc for documents, not websites
← Previous message | No next message

Bevi,

On Apr 22, 2011, at 1:29 AM, Bevi Chagnon | PubCom wrote:

> Duff wrote:
> " Why post a Word file if you can post a good PDF file instead? :) "
>
> When the document is a work in progress, PDF isn't feasible.

Ok, I'd assumed we were talking about "final" documents - ie, not a work in progress.

> An editable
> file (a REAL editable file, not the pseudo-editing capabilities in PDF)
> is needed as the document is developed, reviewed, and approved.

...before the document makes it to a "final form" - fair enough.

> Plus, government agencies use Word's track changes as an electronic paper trail
> throughout the life of the document. Only after it's approved and finalized
> does it become a PDF, and usually both the PDF and the Word source file are
> stored somewhere on a server or intranet.
>
> Many government documents never become PDFs but stay as Word documents. A
> good example are templates for reports, forms, publications, fact sheets,
> and research.

Templates aren't going to need any longdesc....

> So a PDF file is like a one-size-fits-all shirt: it fits some people, but it
> really doesn't fit all.

More on that below.

> My interpretation of Section 508 standards (well, the forthcoming ones) is
> that all information and communication technology must be accessible. So
> that includes the working source files (namely Word) and a final PDF.
>
> Given that one of the original intents of Section 508 was to give disabled
> federal employees equal access to government information so that they can do
> their job, it then doesn't make sense to have only the final PDF accessible
> but not the working source file. If the working source file isn't
> accessible, that means disabled federal employees aren't able to be on the
> work team that is creating that source file.
>
> Granted, it might not be feasible to make all working documents fully
> accessible, but there should be a valid attempt to do so.
>
> In sum, a good accessible PDF is fine for part of the workflow, but not the
> entire workflow.
>
> --Bevi
>
> P.S. " Final-form electronic documents are almost by-definition PDF files -
> or so I'd contend."
> Wow, do I disagree! Not from an editor's or designer's viewpoint, that's for
> sure.

I did say "final-form", not "in-progress"....

Naturally, a PDF isn't suitable if the same file is intended for further editing. HOWEVER, PDF files can include attachments, as already noted. Such attachments may be of any type, including Word files. Thus, a PDF may be used as a "delivery truck" for a collection of content.

In at least one workflow I'm aware of, the "containing" PDF is a static representation of the editable document. Attached to that "posting" PDF are the editable Word (or other) file(s) plus any required attachments.

Duff Johnson, CEO
Appligent Document Solutions

22 E. Baltimore Ave
Lansdowne, PA 19050
+1 610 284 4006
+1 617 553 1934 (direct)
= EMAIL ADDRESS REMOVED =
http://www.appligent.com
http://www.twitter.com/duffjohnson