|
Section 508
Policy: Backwards Compatibility
Section
508 is very vague when it comes to specific methods for handling document content.
Alt. text is required, and basic rules are given for tables, but almost nothing
else about content handling is included in the regulation. In order to achieve
any meaningful degree of compliance and usability, each agency must develop their
own standards for content handling beyond the simple prescriptions offered in
the regulation itself. Backwards compatibility is one such key policy point. Should
PDFs be "backwards compatible" to the current version of JAWS? Many
government agencies use the JAWS screen-reader software as their benchmark for
accessibility testing. However, because JAWS uses MSAA to access the content in
PDF files, it cannot actually read the structure in PDFs that Section 508 requires
for complex tables! Moreover, JAWS cannot "see" other structural tags
in PDF such as Headings and Lists. These elements are not required by the letter
of Section 508... but they ARE highly desirable for usability purposes - the spirit
of 508. Regardless
of these limitations, PDF files may be made BOTH Section 508 compliant AND highly
usable even for those using JAWS or other MSAA software. Some key work-arounds
for complex tables ensures that other screen-readers that do not depend on MSAA
are not shortchanged. In
tagging PDF files to ensure compliance with Section 508, it is necessary, therefore,
to ask and answer the following two questions: 1.
Must our files work well with JAWS, and if so, are we prepared to commit the resources
necessary to correct the table tagging? 2.
Can we accept "strict" 508 compliance, or must we tag to allow a higher
degree of usability for advanced screen-readers?
Compression:
What and Why
In
the business and legal worlds, the correct use of image compression is poorly
understood, even though it affects "high profile" PDFs intended for
the web, disc or email distribution. In this article, we'll discuss compression
for black-and-white (bitonal) scans. Before
Acrobat 5.0 was released, the only business- usable bitonal compression supported
in PDF was CCITT-G4, also known as "Group 4". This compression remains
in common use today as the bitonal TIFF compression of choice. Reasonably efficient
for text, "dirty" scans and images reduce its effectiveness considerably.
Average per-page sizes for G4 compression range from 30kb for "clean"
text- only pages to 100kb or more. Beginning
with Acrobat 5.0, it became possible to encode bitonal images in PDF with JBIG2.
Less an image-compression format than a glyph-matching system (don't ask unless
you really want to know), JBIG2 attempts to find like instances of a given pattern
of dots (such as a character), and then average them together. The result, even
with "perceptually lossless" compression, is effectively flawless -
users need not fear that the image is compromised in any meaningful way. JBIG2
compression is especially effective on longer documents, where character averages
may be extended over many pages to increase compression efficiency even further.
Even "dirty" documents often get a dramatic reduction in file-size...
those spots on the image can be averaged too, just like the characters. If
you have to maintain backwards compatibility to Acrobat 4, however, you can't
use JBIG2. The
real excitment over JBIG2, of course, is the file- size. On documents longer than
a page or two, JBIG2 can really shine, reducing file sizes from 30% to 70% or
more. Even one-page documents are generally significantly smaller than their G4
equivalents. Understanding
compression in PDF really works to your advantage. Effective use of JBIG2 can
result in far more pages per disc, far quicker downloads, less cluttered email
servers, reduced bandwidth costs and extended usage of existing file-server capacity.
For some, the availability of JBIG2 compression in PDF is reason enough to switch
from their current TIFF-based document management system to something that works
well with PDF. | 
