W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2016

Re: PDF's Exposed via Web Pages and Accessibility

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Tue, 5 Jan 2016 15:44:34 -0600
To: <ptykodi@tykodi.com>
Cc: <w3c-wai-ig@w3.org>
Message-ID: <OFFBA8A9CE.8D369B22-ON86257F31.007635CB-86257F31.0077706A@us.ibm.com>
Paul,
can you comment a little more about your use of the term " embedding PDF 
files in web pages"? 
I assume you mean "not attaching them", or otherwise making them available 
to be detached, downloaded, printed, etc. But embedded as in "displayed 
in-line" with a PDF browser plug-in? 

>From a software architecture perspective, there are several considerations 
or requirements, but not that many "best practices" other than my list 
below:

Possible Courses of Action:
Identified are a set of possible courses of action that need to be 
considered when developing a remediation plan for making PDFs accessible 
with a sustainable approach.  Depending on the type of issues found and 
the type of PDF itself (e.g. data tables and/or interactive forms) the 
enterprise can take one or more of the following possible courses of 
action:
1.      Alternative format ? strongly consider providing an alternative 
format of the same information at the same availability.  For example, for 
PDFs that contains a data table, consider providing a spreadsheet 
equivalent in CSV or Microsoft Excel format of the same data, and provide 
it dynamically on-demand when that is how the PDF is provided.  Another 
example is to provide a more mobile friendly accessible e-Pub 3 or a 
desktop HTML 5 version of the information with an appropriate CSS style 
sheet for printing. 
2.      Repair the back-end system ? consider repairing the back-end 
system that collects the information and dynamically creates the PDF.  For 
example, do an analysis of the original source data, PDF templates, XML 
schemas and any transformation systems that created the dynamic PDF to 
identify repair options and requirements.  This will often require working 
with the back-end system owner (software developer or vendor).
3.      Repair the PDF ? Assess and remediate the PDF and replace it for 
future downloading or reference.  For example, a single annual company 
report may simply be repaired once and then replaces the previous 
inaccessible version.
4.      Repair on-demand ? Upon request, assess and repair the PDF 
document.  This course of action will often require educating the customer 
help desk with procedures on how to respond to customer request, often 
require adding end-user information on how to request a repaired PDF, and 
a responsive repair procedure that is acceptable to end-user expectations. 
The on-demand option could also be out-sourced to a 3rd party service 
provider with appropriate turn-around times expectations set. .
5.      Replace the back-end system ? replace the back-end system with one 
that is capable of creating accessible PDFs.  Conduct an assessment of the 
system, including original source data, PDF templates, XML schemas and any 
transformation systems that creates the PDF to ensure it will meet 
accessibility standards.  Commercial back-end systems are available for 
comparisons and assessment of applicability to the enterprise?s 
requirements.
6.      Establish the back-end creation process, tools,  and procedures ? 
replace the process, tools,  and procedures that are used to create the 
original PDF.  For example, provide training and software wizards that 
guide the original author to make or output accessible PDFs for original 
source systems such as Microsoft Office Word and PowerPoint.  Often this 
course of action will also require a periodic audit of PDF attachments to 
determine if the process and procedures are being followed and that only 
accessible PDFs are being posted to the website. 
7.      Patch the back-end system ? repair part of the back-end system by 
intercepting the PDF content during the workflow and redirect the output 
to a transformation system that can convert/repair the PDF before the 
final PDF is posted for end users to download.  For example, work with a 3
rd party service provider that specializes in back-end PDF remediation. 
8.      Remove ? Assess the value or need of keeping inaccessible PDF 
available and remove the ones that are no longer needed. 

Combination ? Some appropriate combination of the above possible courses 
of action.  Often this approach is used across an enterprise where 
different back-end process, procedures, and systems are used (for example 
by line of business), each requiring a different course of action.  Often 
an enterprise wide as-is assessment along with a strategy and roadmap will 
be the most efficient and effective course of action for the enterprise.. 

____________________________________________
Regards,
Phill Jenkins, 
IBM Accessibility



From:   "Paul Tykodi" <ptykodi@tykodi.com>
To:     <w3c-wai-ig@w3.org>
Date:   01/05/2016 11:05 AM
Subject:        PDF's Exposed via Web Pages and Accessibility



Hi,
 
I am currently working on a Customer Communications Management 
architecture project for a financial services firm. One of the issues I 
have been asked to investigate, from an architectural perspective, is the 
use of PDF files embedded within a publicly available web page.
 
I have been reviewing the proposed refresh of the United States of America 
Section 508 regulation, which specifically calls out using PDF/UA when 
embedding PDF files into web pages: 
http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh
 
In looking at this issue from an architectural perspective, it seems like 
placing some form of validator in the delivery channels from PDF creator 
to web page delivery would likely be necessary to insure all PDF?s made 
available for web page deployment were PDF/UA compliant.
 
I am hoping that subscribers to this W3C list with experience in this area 
might be able to comment on best practices for embedding PDF files in web 
pages and maintaining accessibility conformance (Examples: WCAG 2.0 and 
the ISO Standard known as PDF/UA) going forward.
 
Thanks.
 
Best Regards,
 
/Paul
 
 

Paul Tykodi
Principal Consultant

Tykodi Consulting Svcs LLC
Phone:
(603) 343-1820
 
 
3 Lowell Ave
Cell:
(603) 866-0712
 
Dover, NH 03820
Fax:
(603) 343-1820
 
USA
E-mail: 
ptykodi@tykodi.com
 
www.tykodi.com
Skype:
Tykodiconsultingservices







 
Co-Chair               - IEEE-ISTO PWG IPP Working Group
Vice-Chair             - IEEE-ISTO PWG Semantic Model Working Group
 
This e-mail message and any attachments are confidential and may be 
privileged.
If you are not the intended recipient, please notify Tykodi Consulting 
Services LLC 
immediately by replying to this message and destroying all copies of this 
message 
and any attachments. Thank you
 



picture
(image/png attachment: 01-part)

Received on Tuesday, 5 January 2016 21:45:12 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 January 2016 16:39:04 UTC