PDF/UA: Defining Accessible PDFs

PDF/UA is needed because while the PDF specification creates accessibility mechanisms it fails to set clear rules for actually creating (or delivering) reliably accessible PDF content.

 "UA" stands for Universal Accessibility; PDF/UA designation certifies that documents are compliant with ISO Standard 14289, the new international standard for Accessible PDFs. There are approximately 25 million individuals in the US, 1 million individuals in Canada and over 30 million individuals in the EU that have difficulty reading bills, statements and other customer communications. A document that has been produced in the PDF/UA format using best practices will guide customers’ assistive technology to present that document in the most accessible way possible.

In a Nutshell:

A PDF/UA document is a PDF file that contains specific content in it's infrastructure to make its content as accessible as possible to users that require assistance to access the content, primarily using "screen readers" that allow a sight-impaired user to navigate a document as it is read aloud. The main points:

• Content is tagged. The tags used describe what the content is, for example a heading, and the order of that content within the document – this guides the screen reader and facilitates navigation through the document.
• Graphical elements have a text description so that a user can know what that element is.
• Tables have tags for their column headings and row headings so that the user can know what the values within the table represent.
• Fonts must be embedded
• The language of the document is specified

These are just the basics. A protocol has been developed, the Matterhorn Protocol, that defines 136 attributes a PDF/UA document will contain. Like all PDFs, it is a document that will print and be viewed electronically uniformly across all platforms. It also contains metadata within the tags that may make such PDFs more suitable for archive and retrieval purposes and can be produced in such a way that it also conforms to the PDF/A standard for long term preservation of electronic documents. 

The importance of PDF/UA documents is that they conform to the definitive standard for Accessible PDFs that the ISO (International Organization for Standardization) has published based on efforts of a global consortium of technology experts spanning almost a decade. This is a concise, prescriptive guide to using the tagging and other content storage and organization technology in PDFs to document the hierarchy and structure specific to the contents for each document type. With these tags, a PDF/UA document enables your customers’ assistive technology to present the contents in a logical order that enables comprehension, making the content both accessible and usable

A bit of history:

Back in 2000, Adobe added the capability to add “tags” within PDF files. To use an uncommon word for a moment, tags add “semantic” meaning to content within a PDF and tells us what that content is. For example, a tag might tell us that content is an image or a table. Another example is to have a heading tag applied to content within the PDF, identifying headings and their relative importance (“Heading 1” is more important than “Heading 2”). This introduction of tags is important because it started to lay the groundwork for making PDFs accessible. In 2008, Adobe’s Reference 1.7 version of PDF became a Standard (ISO 32000-1:2008). Adobe handed the ongoing management and enhancement of PDF to subject-matter expert committees around the world through the International Organization for Standardization (ISO). PDF/UA and regulatory compliance.

There are many regulations that specify what your organization’s obligations are with regard to meeting the needs of people with disabilities. An obvious example is handicapped parking spaces. In the United States these are often called ADA parking, where ADA stands for ‘Americans with Disabilities Act.’ Other examples include ramps for wheelchairs, push buttons that automatically open a door, etc. All of these are required by law.

PDF/UA documents meet or exceed the regulations set down in Section 508 of the Rehabilitation Act PDF/UA is one of many ways your organization can provide accessible electronic documents to your customers and help you meet regulatory obligations, while providing the best possible experience.

Added benefits of PDF/UA:

• A PDF/UA file can also be a PDF/A file, offering a single approach to address both your long-term archiving requirements as well as accessible PDF requirements.
• A PDF/UA file, due to its content tagging, makes the user experience on mobile devices much better due to text reflow as an alternative to zooming in on content in order to read it
• A PDF/UA file can make content re-use easier due to the fact that the content is tagged. For example, copy & paste or extracting to HTML is more easily achieved.
• A PDF/UA file can provide better search results. If your archive or search tool can utilize PDF tags, the ability to find what you are looking for can be based on the complete set of actual PDF document content.

Please contact us for more information on making your documents compliant with Section 508 and PDF/UA.

 Matterhorn Protocol: http://www.pdfa.org/wp-content/uploads/2014/06/MatterhornProtocol_1-02.pdf provides 136 criteria for PDF/UA compliance, of which 47 require human judgment.

Estimating Costs for Section 508 Compliance Remediation

Here's a nice overview showing some real-world examples of what it takes to make documents accessible and compliant with Section 508:

Child Abuse Prevention Resource Guide for 2013 is over 80 pages (see https://www.childwelfare.gov/pubs/guide2013/guide.pdf). From design of this document to PDF conversion, this report required about 20 hours of work to ensure compliance. 

Child Maltreatment 2011 and 2012 reports (http://www.acf.hhs.gov/programs/cb/research-data-technology/statistics-research/child-maltreatment) are examples of ~250-page reports that required about 40–50 hours to fix Section 508 compliance issues and address any resulting formatting issues in the PDF.

Child Welfare Outcomes reports (http://www.acf.hhs.gov/programs/cb/research-data-technology/statistics-research/cwo) are over 400 pages, with many data tables, and may take well over 80 hours and $6–8K to make Section 508 compliant.

Overall remediation budget for about 200–225 PDFs of various sizes and complexity, most in the 2–20 page range with perhaps a quarter in the 21–200 page range, is about $250K. If most of the documents are at the high end of these page ranges, the cost (assuming a loaded rate of $80/hour) would be upwards of $300K.

These are just examples- the variation is as broad as is the variation in documents. Consult with a knowledgeable 508 remediator to find out what it takes to make your documents accessible and compliant. 

http://508compliantdocumentconversion.com/

Section 508 PDF Remediation: Get Jiggy with 1194.22

Question: You are working on an RFP for a governmental agency, and the requirements include delivering a Section 508 compliant PDF document. What does this mean, and how can you get this job done?

Answer: Here is a sample 508 RFP requirements/specifications from a government contract offering, the boilerplate, so to speak:

All electronic and information technology (EIT) procured through this solicitation must meet the applicable accessibility standards at 36 CFR 1194, unless an agency exception to this requirement exists. 36 CFR 1194 implements Section 508 of the Rehabilitation Act of 1973, as amended. 

In accordance with the above, in addition to the work requirements specified in the Statement of Work, contractors/vendors must ensure that all EIT that they provide either: (1) meets the technical provisions of the Section 508 Access Board Standards applicable to a given procurement (see below); or (2) uses designs or technologies as alternatives to those prescribed in the specified technical provisions, provided they result in substantially equivalent or greater access to and use of a product for people with disabilities. 

The following standard, from Subpart B of the regulations, will be applicable to PDFs delivered via this contract:

 1194.22 Web-based intranet and internet information and applications. 

(Note:The standards do not require the installation of specific accessibility-related software or the attachment of an assistive technology device, but merely require that the EIT be compatible with such software and devices so that it can be made accessible if so required by the agency in the future.)

Question: How can I make sure my documents meet 1194.22?

Answer: Contact and deal directly with a reputable, knowledgeable Section 508 remediator.  Ask questions, make sure they know what they are doing, that they are not just a pass-through. You may want to learn about the process, or maybe not (some clients just want us to make this particular headache go away... <8^) - we at EDCS are glad to tell you as much or as little as you care to know, as the end result is the same: we remediate your document and deliver a Section 508 compliant PDF that meets all 13 requirements of 1194.22, and the documentation to prove your due diligence.

Under Subpart B: Technical Standards, we see the applicable requirements for PDF compliance, §1194.22.  This is NOT our interpretation of compliance, this is the language in the regulation.  Ten of these sixteen standards apply to PDF format. Meet these ten requirements - as all EDCS-certified documents do - and rest assured that your documents are in complete compliance.

Here's the regs, we've struck-through the ones that aren't applicable to PDF:

1194.22 Web-based intranet and internet information and applications.

(a) A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

(e) Redundant text links shall be provided for each active region of a server-side image map.

(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

(g) Row and column headers shall be identified for data tables.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

(o) A method shall be provided that permits users to skip repetitive navigation links.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Formatting Accessible URLs for 508 Compliant Documents

Question: I want my URLs to be accessible and compliant with Section 508- what is the "correct" format?

Answer: Unfortunately, the interpretation of Section 508 requirements by various government agencies is not consistent. EDCS always asks clients for their "style sheet" with guidelines regarding their preferred format, and here are the basic choices and what we consider to be best practices: Complete URLs or descriptive text? HHS specifies in their checklists that URLs should be complete-

"contain the correct hyperlink and display the fully qualified URL (i.e.,http://www.samhsa.gov and notwww.samhsa.gov)"

while SSA suggests plain text, that clearly describes the destination, like

"Best Practices Library"

rather than the actual URL,

"http://www.ssa.gov/accessibility/bpl/bps/navigation/links/default.htm"

URLs are often pretty descriptive, but do you think a sight-impaired user wants to hear a long, non-descriptive URL read out loud? Like

http://www.regulations.gov/#!searchResults;rpp=50;so=ASC;sb=agency;po=0;a=HHS%252BACF%252BAHRQ%252BAOA%252BCDC%252BCMS%252BFDA%252BHRSA%252BHHSIG%252BSAMHSA%252BNIH%252BIHS;dct=PR%252BFR;dkt=R

I believe the answer is pretty obvious- the best practice is to use plain text that clearly describes the destination. For more information on best practices for accessibility, visit the SSA Best Practices Library!

Question: What about underlining URLs?

Answer: Again, no definitive answer within the regulations, but we customarily artifact any underlines, as there is no need for them to be read out loud. JAWs, etc., can identify and label links for users, the underline is just extra noise. Furthermore, Google has abandoned underlines, and only relies on color to identify links. Colored URLs are easy to pick out for sighted users, the underline is not needed. And if Google says underlines have "gone out", we all know it is useless to resist...

So, use descriptive text, contrasting color, and skip the underlines. Happy tagging!!!

VA has it's hand's full with Section 508...

The URL about says it all: http://veterans.house.gov/hearing/assessing-inadequacies-in-va-data-usage-for-and-services-provided-to-visually-impaired By January 2013 all Veterans Affairs Department websites were required to conform with Section 508 of the Rehabilitation Act, but not only are many VA websites non-compliant, the department lacks a clear timeline for meeting the requirement. Section 508 requires federal agencies to make electronic content and information technology accessible to people with disabilities. "At this point in time we've not achieved 100 percent conformance with the 508 standard," said Lorraine Landfried, deputy chief information officer for product development at VA. Landfried spoke May 28 before the House Veterans Affairs subcommittee on oversight and investigations. Landfried later said she could not provide a date when all VA systems would meet the standard. Anyone out there who has done compliance work for the VA understands the problem here: an entrenched bureaucracy, with contractor's lining their pockets instead of trying to help make documents accessible!!! Read more: VA websites miss 508 compliance deadline, lack timeline for achievement - FierceGovernmentIT http://www.fiercegovernmentit.com/story/va-websites-miss-508-compliance-deadline-lack-timeline-achievement/2014-05-29#ixzz33DJ9Qwbn Subscribe at FierceGovernmentIT

Getting Multiple Government Agencies on the Same Page Regarding Section 508

Anyone involved in the often onerous task of remediating documents for Section 508 compliance can find themselves aiming at a moving target, depending on the specific requirements of their clients. Section 508 of the Americans With Disabilities Act contains lofty goals for universal accessibility, but does not get down into the weeds with specific guidelines for document creators. That has left the door open for "interpretation" by different agencies, and subsequently makes life difficult for remediators.

A great example comes in creating accessible hyperlinks in documents. Here's what Health and Human Services (HHS) asks in their "PDF File Checklist", section 1.8:

Do all URLs contain the correct hyperlink and display the fully qualified URL     (i.e.,http://www.samhsa.gov and not www.samhsa.gov) 

That's pretty unambiguous. HHS was the first of the government agencies to interpret the regulation and create a checklist, but that doesn't make their interpretation correct, or make documents following their interpretation more accessible than documents that see it differently.

Below is a contrary- and persuasive- argument on hyperlinks from the Social Security Administration, in their guide to creating accessible documents. Consider their logic:

When a Screen Reader is reading text and there is a link, the software will insert the word "Link" in front of the text to alert the user that this is a selectable hyperlink. Another way that Screen Readers can access the links that are in a document is for them to call up a list of links. This list will display only the text that has been marked as a link. It is important that the list of links makes sense to the user when it is read out of context. That is, the name of each link should make sense in the list when it is read in isolation.

Consider the following four examples of the same text and same link rendered using different methods:

1. Please read The SSA Online Accessibility Policy. Click Here

2. Please read The SSA Online Accessibility Policy.
http://www.ssa.gov/webcontent/accessibility.htm

3. Please visit The SSA Online Accessibility Policy.

4. Please visit The SSA Online Accessibility Policy:
http://www.ssa.gov/webcontent/accessibility.htm

If every link in the document was rendered using method #1, the list of links would read like this:

• Click Here

• Click Here

• Click Here

• Click Here

It is easy to see that individual links are not possible to read out of context. If every link was rendered using method #2, the list would read like this:

• http://www.ssa.gov/webcontent/accessibility.htm

• http://ssa.gov/pgm/links_disability.htm

• http://www.section508.gov/

This list also makes no sense in context. While we might be comfortable in normal conversation saying "go to s s a dot gov" we generally do not say to people "go to s s a dot gov slash p g m slash links underscore disability dot h t m". It is too long and it is too difficult to understand. However, when the list of links is presented this way, this is exactly how the Screen Reader will say each link.

If every link was rendered with method #3, the list would be read like this:

• The SSA Online Accessibility Policy

• SSA Disability Benefits

• GSA's Section 508 website

Using this method, all of the links make sense when spoken out of context. This is the best method to use.

What is the lesson here? It's that "compliance" with Section 508 is not defined at the granular level, but a regulation that has many interpretations. Before starting any remediation project, it is best practice to query your client for any specific requirements or checklists that are to be followed. Just remember that the goal is accessibility, with compliance merely being the by-product.