Learn about document compliance and how it is achieved:
Electronic documents come in many formats, but most are converted to PDF for publication on the Web. Invented by Adobe Systems over 20 years ago, Portable Document Format (PDF) is now an open standard for electronic document exchange maintained by the International Organization for Standardization (ISO). When you convert documents, forms, graphics, and web pages to PDF, they look just like they would if printed. But unlike printed documents, PDF files can contain clickable links and buttons, form fields, video, and audio — as well as logic to help automate routine business processes.
This underlying structure is not inherent in the PDF, but must be planned for during the source document creation, or added to the document during PDF “remediation”. The process ensures that the published document is accessible for users with disabilities as well as more valuable to all users, with logical document structure, internal navigation, and active bookmarks, URLs, and functional forms. This document structure is contained in the document’s “tags” that live behind the scenes and allows assistive technology like screen readers to interpret the document as intended by the authors.
Similar to the HTML code that defines how Web pages display, PDF document tags define how a document is read aloud using programs such as JAWS, and the quality and organization of the tags determine just how accessible the document will be, and how close to an equivalent experience the audio version of the document is compared with reading. They are labels that help the screen readers inform a sight-impaired user how the document is structured, and allow navigation through the document with the same functions available to a sighted user.
Proper tagging is the first step. Depending on how a document is converted, and what the source is, documents may be close to accessible with minor editing. Proper conversions from late versions of Word or InDesign give the best results, but this, too, is dependent on how the document was “styled” ; the most common example is font selection- the document creator may not have followed best practices using CSS “styles”, and the tags created during the conversion will need extensive editing. The document remediator’s job is to ensure the tags will tell the story as the author intends, that there is a logical underlying structure. As a programmer writes the underlying code for a Web page, the remediator builds (or renovates) the foundation that holds the content and correctly “displays” the final document for assistive technologies like JAWS.
Section 508 was enacted to eliminate barriers in information technology; advances in this technology have made it possible to significantly reduce these barriers, or even eliminate them completely. Electronic Document Compliance Services (EDCS) is dedicated to helping fulfill this promise. We do one thing, and we do it well: Documents certified compliant by EDCS are guaranteed to be accessible and compliant with Section 508.