The following article was presented as Duff’s 2nd round of testimony to the US Access Board on the NPRM for Section 508 released February 18, 2015.

The Remarks are in addition to my previous testimony, but the proposed changes to the text of the regulations replaces my previous submission.

This testimony is my own, and does not represent the official position of any ISO committee, or of the PDF Association.

Foreword

Based on further consultations within the PDF technology and web accessibility communities as well as my own review of the 80 comments made public on the ATBCB-2015-0002 docket as of May 28 2015, this document provides additional testimony, and revises my previous suggestions for the regulation’s text. 

Remarks

Executive Summary

In support of my proposals for the regulation’s text, this additional testimony is intended to accomplish four things:

  • Highlight how PDF/UA is intended as a companion to other standards, including WCAG 2.0
  • Provide additional information on the vital role of technically-specific standards in the PDF marketplace
  • Explain the significance and utility of the PDF/UA flag in WCAG 2.0 terms
  • Address the use of PDF/UA in the Section 508 refresh with respect to WCAG 2.0

My previous proposal, while valid, was overly complex. The changes suggested herein follow a simple formula:

“WCAG 2.0 is required for all content. For PDF documents, PDF/UA is also required.”

PDF/UA is a “companion standard”

PDF/UA was not designed to replace or substitute for WCAG 2.0. At stated in the Introduction to ISO 14289:

“PDF/UA is intended as a companion standard, to be used in conjunction with […] other standards as may apply for the purpose of achieving accessibility.”

Unlike a technology-neutral standard such as WCAG 2.0, a technology-specific standard such as PDF/UA includes few generic provisions. Although passing or failing PDF/UA in most cases implies a corresponding pass or fail for WCAG 2.0, PDF/UA is not and should not be considered a substitute for WCAG 2.0. PDF/UA is mostly concerned with the manner in which content is encoded in PDF files, not the nature of the content itself.

PDF/UA provides the technical specificity needed for different PDF developers to achieve a functionally equivalent understanding of accessibility in PDF technology. It is a complement, not as an alternative, to WCAG 2.0.

Making accessibility economically realistic

The purpose of technology standards is to facilitate agreement between different agencies, software developers, trainers, procurement officers, end-users and others on the definition of success in attaining regulated objectives.

Prior to the publication of PDF/UA in 2012, each developer trying to achieve accessible PDF documents was effectively forced to invent their own version of PDF/UA. In such circumstances the chances that different vendors’ software would generate similar results (essential to PDF’s core value-proposition; reliability when shared) were relatively low. This fact was central in limiting almost all investment in making, editing, checking or reading accessible PDF documents and forms to one company – Adobe Systems.

When WCAG 2.0 became available in 2008 (4 years before PDF/UA’s publication) it didn’t change this reality at all. Since WCAG 2.0 doesn’t provide technical requirements for PDF technology, vendors had no way of knowing whether others would respect their interpretation of WCAG 2.0 (or WCAG 1.0, or Section 508, or other) as applied to PDF.

The publication of PDF/UA got a very different response. As I mentioned in my previous testimony, PDF/UA unleashed a wide variety of vendors who began building solutions for accessible PDF, with more announcing their products and services every few months. This level of engagement was unimaginable prior to PDF/UA.

To reliably address accessibility requirements as applied to a complex format whose value depends on interoperability, software developers need a target that’s specific to the format’s purpose, functionality, capabilities and limitations. That’s precisely what PDF/UA, uniquely, provides.

If we are ever to achieve economies of scale in creating accessible (and known to be accessible) PDF documents, we must standardize on PDF/UA for PDF documents and forms in addition to WCAG 2.0.

Is the PDF/UA flag required for accessibility?

Some have noted that if an otherwise-conforming PDF/UA document were to lack PDF/UA conformance metadata (the “flag”) it would nonetheless be accessible. The flag itself, they say, does not make the file any more or less accessible, even if strict conformance with PDF/UA requires it to be present.

In many cases this statement is true, so far as it goes. A PDF may be well tagged or otherwise irrespective of the flag. But what does the flag actually do? It has several key functions, among which is to resolve ambiguities and provide accountability and enable interoperability. The PDF/UA flag is needed, not only for accessibility reasons in some cases, but also for economic reasons in all cases.

What is the “PDF/UA flag”?

Screen shot of PDF/UA conformance claim in Adobe Acrobat.As befits its self-contained nature, PDF technology includes an XML metadata mechanism with a standardized, portable model for assertion of conformance with ISO standards such as PDF/A, PDF/UA, PDF/E, and others. Better PDF viewers report these flags in their user interfaces (see screenshot to see how Acrobat DC does it).

The PDF/UA conformance flag (ISO 14289, clause 5) is the machine-readable assertion by document creation software that PDF/UA’s requirements have been met, allowing PDF/UA-aware software and users to proceed on that basis. The flag establishes the necessary context for maximum interoperability.

Without the PDF/UA flag, reader or AT software has no concrete indication that structure elements are logically ordered and semantically correct, the qualities most critical to accessibility. Unlike HTML, where content ordering within the HTML <main> tag is typically assumed, AT might respond to PDF files lacking the PDF/UA flag with heuristic analysis to find, organize and present content. When the PDF/UA flag is present, however, AT can rely on the PDF’s structure tree without the delay, loss of semantics and conversion errors characteristic of heuristic processes.

The PDF/UA flag has no analog in WCAG 2.0. Unlike PDF/UA, assertions of conformance are not required in order to conform to WCAG 2.0. Although WCAG 2.0 recommends machine-readable conformance metadata, it’s not specified.

In some cases the PDF/UA flag is actually required for conformance with WCAG 2.0. Let’s understand this in detail.

Akin to HTML’s <!DOCTYPE>, and no less required for conformance with WCAG 2.0

As metadata, the PDF/UA flag isn’t part of the file-format’s syntax. Nonetheless, it helps processors understand what to do with the file’s contents. In this sense, the PDF/UA flag is similar to HTML’s <!DOCTYPE>. Although HTML may be parsed without a <!DOCTYPE> declaration, when the lack thereof creates ambiguities then <!DOCTYPE> is required by WCAG 2.0 Success Criteria 4.1.1 (Level A). Likewise, for PDF files, the lack of a PDF/UA flag can affect how PDF content is processed by AT software. Like <!DOCTYPE>, the PDF/UA flag is “only” metadata, but when it resolves ambiguities pertaining to accessibility the flag is necessary to conformance with Success Criteria 4.1.1.

Some examples:

Example 1: headings

Without the PDF/UA flag a structure element of type <H7>, if it is not role-mapped to a standard structure element, cannot be evaluated. It’s a meaningless tag, no different than a structure element of type <Duff>.

When the PDF/UA flag is present, however, <H7>’s role is defined as the 7th heading level, below <H6> and above <H8>. NOTE: PDF and PDF/UA allow more heading levels than HTML because PDF documents can be much longer, and are often far more deeply structured, than individual web pages.

Example 2: role-mapping non-standard elements

Without the PDF/UA flag, non-standard structure elements (which are commonplace in PDF) need not be role-mapped to standard structure elements, or may have a circular mapping. Failing to provide mappings to standard structure elements introduces ambiguities for AT software in the document’s semantic structures, failing not only Success Criteria 4.1.1 but Success Criteria 1.3.1 (also Level A) as well.

When the PDF/UA flag is present, every non-standard structure element must be role-mapped to a standard structure element, guaranteeing the establishment and interoperability of the document’s semantic structure via PDF’s standard structure elements.

In simpler terms, the PDF/UA flag asserts a valid role-mapping to standard structure types for every tag. This allows AT software to process (for example) a non-standard <FancyHeading2> element as standard structure element <H2>.

Example 3: font embedding

Screenshot of a table in which the bottom row of text has been shifted left resulting in light text on a white background and black text on a dark background.Without the PDF/UA flag a processor cannot rely on embedded fonts to ensure conformance with SC 1.4.3 (Level A). The adjacent image illustrates the problem. Here, font substitution adjacent to a similar-color background results in unattractive but legible results for conventional users but present a clear violation of WCAG 2.0 SC 1.4.3 (Level A).

When the PDF/UA flag is present, all resources necessary for stable as-intended rendering must be available, period, eliminating a large class of errors. Beyond legibility, AT developers can use the PDF/UA flag to enable software that leverages embedded fonts and Unicode mappings for text customization and sizing, better reflow experiences, highlighting, and other purposes.

Example 4: Where the lack of PDF/UA has delivered us to-date

Without the PDF/UA flag Kurzweil Education’s superb (and expensive) reading technology treats PDF documents as images, approximating the text, semantics and structure via OCR and other heuristic (and thus lossy) analysis. This is vital when the overwhelming majority of input documents lack even basic accessibility attributes.

When the PDF/UA flag is present, although Kurzweil and similar software provide vital tools for those coping with inaccessible documents, they will not, for years to come, rival the reliability, navigability, interoperability, and rich opportunities for AT and authors in leveraging PDF/UA for documents and viewer software.

Summarizing the examples

Even when the PDF/UA flag is not necessitated (for WCAG 2.0 conformance purposes) by technically ambiguous situations in given PDF files (such as with examples 1 and 2 or other risky situations (as in example 3), failure to recognize the flag negates options based on consistency and functionality; a primary objective in standards adoption.

Regarding arguments in support of making PDF/UA optional

Although acknowledging that PDF/UA offers “better consistency”, some advocate that it’s important for PDF/UA to be optional, and not required, for PDF documents. They generally offer one or more of the following arguments:

Claim Response
WCAG 2.0 alone suffices for PDF accessibility in all cases I have addressed this claim earlier in this document.
WCAG 2.0 alone suffices for PDF accessibility in many cases This is not a good basis for regulation because it can’t be generalized and thus sacrifices the economies to be gained from broad, unified adoption. It’s also confusing, forcing users to determine how requirements are applied in specific cases instead of simply requiring developers to “do the right thing” in all cases.
PDF/UA is not easy to work with PDF/UA is intended for software developers. If both WCAG 2.0 and PDF/UA are required we’d expect conforming software to present requirements to users using WCAG 2.0’s terms in almost every case, keeping PDF/UA “under the hood”. There are few reasons to bring the distinction to the end-user’s attention.
PDF/UA is very technical, and includes many references to 3rd party documents PDF/UA is a “use” of ISO 32000-1, the PDF specification, and therefore references that document many times, as well as other normative documents as appropriate, including WCAG 2.0. This is true of any technical software specification; it’s not specific to PDF/UA (WCAG 2.0, after all, is simply a set of rules used to interpret other lengthy, technical specifications such as HTML 5, CSS 3.0, and JavaScript).
PDF/UA is copyright protected All ISO standards are copyright protected, as is WCAG 2.0. Unlike WCAG 2.0, PDF/UA is not freely available, and that is a significant concern. However:

  • The exact text of PDF/UA will shortly become available at a greatly reduced cost
  • Authoritative 3rd party support documents including the PDF Association’s Matterhorn Protocol provide free access to the critical requirements of PDF/UA
  • The actual population of non-technical individuals who will benefit from possession of the ISO document itself is very small.
PDF/UA-1 (which specifies PDF 1.7) will limit adoption of PDF 2.0, and thus, PDF/UA-2 Developers who have mastered PDF/UA-1 requirements will have little difficulty including a “down-save” option to convert PDF/UA-2 documents to PDF/UA-1, making conformance with the “2015 refresh of Section 508” relatively easy even when state-of-the-art PDF technology has moved on to PDF 2.0.
Requiring PDF/UA and WCAG 2.0 is confusing First and foremost of the tangible benefits of interoperability is that things get simpler for all concerned. As I’ve pointed out above, PDF/UA will go almost totally “under the hood” – but only if it’s required for all “accessible” PDF documents.

The US federal government, with and without a PDF/UA requirement

Based on my 20 years in the PDF industry and 14 years in the PDF accessibility industry, I predict as follows:

Without PDF/UA, and with only WCAG 2.0 to guide creation and use of PDF documents, the following will occur:

  • Features specific to PDF technology such as role-mapping of non-standard structure elements, extended headings, pre-filled forms and more will remain ambiguous, itself a violation of WCAG 2.0 (see above)
  • Documents with accessibility problems not addressed by WCAG Techniques will continue to be produced
  • Document producers, accessibility experts and end users will continue to disagree over whether a given PDF document conforms to WCAG 2.0
  • Development of PDF creation software supporting accessibility (including WCAG 2.0) will slow down. PDF reading software and AT that support tagged PDF will develop more slowly still, as PDF documents remain inconsistent

With PDF/UA operating within Section 508 as a companion standard to WCAG 2.0, the following will occur:

  • In relatively short order, major software developers (Microsoft, Adobe Systems, and others) will join specialist and SDK firms in producing solutions for accessible documents that conform to both WCAG 2.0 and PDF/UA
  • Disagreements over accessibility requirements and outcomes will drop as creation, validation and consuming software and documentation are harmonized and testing software advances
  • A new breed of viewing and AT software will (finally) take advantage of tagged PDF to extract and present alternate “views” of PDF documents in a manner that’s optimized for mobile devices, AT, apps and more
  • The PDF/UA flag will be put to use as a portable and testable assertion of accessibility

A US federal government for which PDF/UA is “optional”

In the case where PDF documents are considered “accessible” without conforming to PDF/UA, I fear a scenario ripe for costly confusion. Let’s look at some diverse examples:

  • Agency A produces a WCAG 2.0 conforming (according to current Techniques) document for posting on Agency B’s site. However the document fails PDF/UA, Agency B’s chosen standard for PDF documents.
  • Agency C produces a newsletter using PDF/UA that Agency D wants to redistribute. However, Agency D doesn’t use PDF/UA, and instead requires all documents for redistribution be certified as conforming to WCAG 2.0.
  • Agency D makes a minor change to Agency C’s document. Since Agency D’s software doesn’t use PDF/UA, it inadvertently eliminates the PDF/UA flag; now it’s invalid for Agency C. Certainly, the document may be remediated, but the problem is avoidable in the first instance by simply requiring both WCAG 2.0 and PDF/UA.
  • Agency E is selecting a vendor for a large customer communications management (CCM) package delivering PDF documents via email. Their review of the marketplace reveals that the vendor best suited to their needs says they’ve adopted WCAG 2.0, but does not claim support for PDF/UA. The document user population, on the other hand, may expect PDF/UA conformance assertions based on documents they receive from other agencies, and they may even possess software that takes advantage of PDF/UA to enhance their experience of the content.
  • Agency F is assembling documents from an interagency task force into a summary report. Agencies vary in their accessibility standards, so some of the files collected assert PDF/UA conformance, some claim PDF/UA but fail WCAG 2.0 and some are said to pass WCAG 2.0 but don’t claim PDF/UA. What’s to be done? At whose expense?

Making PDF/UA affordable

ISO 14289 (PDF/UA) is a copyrighted publication of the ISO. That organization sells copies of PDF/UA for 88 Swiss francs (about $93) while ANSI sells it for $250. For a 24 page document, both prices are… unfortunate.

Responding to calls to reduce this cost, AIIM (the entity which hosted development of PDF/UA) is today performing the steps necessary for adoption of PDF/UA as a US national standard, to be published as ISO/ANSI/AIIM 14289-1.

This process will be completed in a matter of a few months, the result of which will be PDF/UA becoming available for $15. Betsy Fanning, Standards Program Director for AIIM, has provided a comment to this effect.

Conclusion

Simulated file save dialog offering Section 508, WCAG 2.0 and PDF/UA-1 options for accessibility. An asterisk indicates that "Section 508" includes both WCAG 2.0 and PDF/UA-1.As I’ve shown, for certain PDF documents, WCAG 2.0 conformance requires PDF/UA conformance.

Where the PDF/UA flag itself isn’t required, it increases interoperability, reduces friction, and facilitates investment in software and solutions development.

The larger goal of attaining broad-based accessibility in electronic documents clearly requires PDF/UA.

I believe the logical and practical choice is clear.

In my previous testimony I suggested a solution that was unnecessarily complicated.

It’s much simpler to simply require PDF files to conform to both WCAG 2.0 and PDF/UA.

Thank you… and please see my specific proposals for the text below

I’d like to thank the chair and the members of the US Access Board for the opportunity to provide additional comments and suggestions regarding the NPRM for the Section 508 refresh. Consistent with my comments above, the following pages propose specific changes to the regulation’s text, replacing the proposal I offered in March, 2015. 

Suggested changes to the proposed Text of the Rule

The following includes text copied verbatim from the NPRM released on February 18, 2015. Proposed additions or changes are shown with underlined boldface text. Proposed deletions are shown in strikeout text.

C102.6 International Standards Organization (ISO)

[1st paragraph not included for brevity]

ISO 14289-1 Document management applications — Electronic document file format enhancement for accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1), Technical Committee ISO/TC 171, Document Management Applications, Subcommittee SC 2, Application Issues, (2014), IBR proposed for sections C203.1, E205.4 and 602.3.1. The Matterhorn Protocol, a free publication of the PDF Association, identifies all PDF/UA failure conditions.

Rationale: The indicated reference changes correctly identify the IBR proposals as they appear in the February 18, 2015 NPRM. In addition to those sections currently listed in C102.6, I propose (See 5.02x, below) that the Access Board incorporate (IBR) PDF/UA into sections E207, 502.2, 502.3 and 502.4. The Matterhorn Protocol offers valuable informative content regarding the technical requirements of PDF/UA.

NOTE: ANSI and AIIM will shortly (2015 Q2 or Q3) publish “ANSI/AIIM/ISO 14289-1 (PDF/UA)”, an exact copy of ISO 14289-1:2014 but made available at a greatly reduced price. The US Access Board is advised to take care to ensure this version is understood to be acceptable.

C203 Electronic Content

C203.1 General. Regardless of the medium or the method of transmission and storage, electronic content integral to the use of ICT shall conform to Level A and Level AA Success Criteria and Conformance Requirements specified for Web pages, in WCAG 2.0 (incorporated by reference in Chapter 1) or, and for PDF files, shall also conform to ISO 14289-1(PDF/UA-1) (incorporated by reference in Chapter 1).

Rationale: See the suggestion for E205.4 where an identical change and rationale is proposed.

To enhance readability and reduce the potential for confusion, I propose referring to “PDF/UA” consistently, limiting use of the ISO part number to the normative references in C102.6 and E102.6 – the only locations in which the standard’s full name is used.

E102.6 International Standards Organization (ISO)

Advisory E102.6 International Standards Organization (ISO).  Formally known as ISO 14289-1:2014, PDF/UA-1 (Portable Document Format, Universal Accessibility) Document management applications — Electronic document file format enhancement for accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1), this is the International Standard for accessible PDF. PDF/UA provides a technical, interoperable standard for the authoring, remediation and validation of PDF content to ensure accessibility for people with disabilities who use assistive technology such as screen readers, screen magnifiers, and joysticks to navigate and read electronic content. The Matterhorn Protocol, a free publication of the PDF Association, identifies all PDF/UA failure conditions.

Rationale: As it serves a similar reference function, this text is updated to match C102.6.

E205.4 Electronic Content

E205.4 Accessibility Standards. Content shall conform to Level A and Level AA Success Criteria and Conformance Requirements specified for Web pages in WCAG 2.0 (incorporated by reference in Chapter 1) or, and for PDF files, shall also conform toISO 14289-1 (PDF/UA-1) (incorporated by reference in Chapter 1).

Rationale: The example offered in Section V. Major Issues A. Electronic content, makes clear that the Access Board intends to require PDF/UA when PDF documents are used:

The central principle underlying the accessibility requirement for public-facing content is the notion that federal agencies must ensure equal access to electronic information that they themselves directly make available to the general public by posting on a public fora. So, for example, if a federal agency posts a PDF version of a recent settlement agreement on its website as part of a press release, that document would need to comply with PDF/UA-1. [Emphasis added]

Adding “for PDF documents,” to E205.4 makes clear that use of a PDF document triggers the requirement of conformance with PDF/UA, consistent with the example.

As with the proposed change to C203, above, to enhance readability and reduce the potential for confusion, I propose referring to “PDF/UA” consistently, limiting use of the ISO part number to the normative references in C 102.6 and E102.6 – the only locations in which the standard’s full name is used.

E207 Software

[add following E207.2]

E207.3 PDF/UA conformance

Where applicable, user interface components for PDF files shall conform to PDF/UA’s requirements for conforming readers and assistive technology (incorporated by reference in Chapter 1).

Rationale: The ability to use PDF/UA documents depends on consuming software being able to use tagged PDF. Adding this requirement to Section 508 provides clear guidance for those procuring or developing software that displays PDF documents.

504 Authoring Tools

504.2 Content Creation or Editing. Authoring tools shall provide a mode of operation to create or edit content that conforms to all Level A and Level AA Success Criteria and all Conformance Requirements in WCAG 2.0 (incorporated by reference in Chapter 1) for all features and formats supported by the authoring tool. Authoring tools creating or editing PDF files shall provide a mode of operation to produce PDF files that conform to both WCAG 2.0 and PDF/UA (incorporated by reference in Chapter 1). Authoring tools shall permit authors the option of overriding information required for accessibility.

504.3 Prompts. Authoring tools shall provide a mode of operation that prompts authors to create content that conforms to all Level A and Level AA Success Criteria and all Conformance Requirements in WCAG 2.0(incorporated by reference in Chapter 1). If authoring PDF files, tools shall provide a mode of operation that prompts authors to create PDF files that conform to PDF/UA (incorporated by reference in chapter 1). Authoring tools shall provide the option for prompts during initial content creation or when the content is saved.

Rationale: If conformance with PDF/UA is required then PDF authoring tools must be able to produce PDF/UA-conforming documents. Accordingly, the same clear language specifying conformance with PDF/UA for PDF documents is appropriate here as elsewhere in the Rule.

602 Support Documentation

602.3 Electronic Support Documentation. Documentation in electronic format, including Web-based self-service support, shall conform to all Level A and Level AA Success Criteria and all Conformance Requirements in WCAG 2.0 and, for PDF files, shall also conform to PDF/UA (incorporated by reference in Chapter 1), or ISO 14289-1 (PDF/UA-1) (incorporated by reference in Chapter 1).

Suggested changes to the text of the Preamble

NOTE: I wrote, but failed to submit, these proposed updates to the Preamble in time for the comments deadline:

The following proposed changes would update the text of the Preamble to match the changes proposed above for the text of the regulation itself. As above, proposed additions or changes are shown with underlined boldface text while proposed deletions are shown in strikeout text.

II. Executive Summary

Section B, 2nd list item:

…to conform to all Level A and AA Success Criteria in WCAG 2.0 or and ISO 14289-1 (PDF/UA-1) for PDF documents.

…but would newly require compliance with WCAG 2.0 or and PDF/UA-1 for PDF documents.

V. Major Issues, A. Electronic Content

2nd paragraph:

…specified for Web pages or, where applicable, and ISO 14289-1 (PDF/UA-1) for PDF documents.

3rd paragraph:

(i.e., WCAG 2.0 Level A and Level AA Success Criteria or and PDF/UA-1 for PDF documents)

5th paragraph:

(i.e., WCAG 2.0 Level A and Level AA Success Criteria or and PDF/UA-1 for PDF documents)

V. Major Issues, B. WCAG 2.0 Incorporation by Reference

In the first list in this section I believe it is appropriate to reference PDF/UA here in a manner that supports the overall orientation towards WCAG 2.0. Specifically, I would add a 5th bullet to the first list as follows:

Fifth, incorporation of PDF/UA’s technically-specific requirements for PDF technology directly serves the best interests of Americans with disabilities because such specificity helps software developers unambiguously establish the means of creating and using accessible, WCAG 2.0-conforming content in the ubiquitous PDF document format.

VI. Section by Section analysis

In section B, last sentence of the subsection titled “E 102.6 ISO“:

It is offered as an option to WCAG 2.0 for accessible PDFs.

In section B, 3rd paragraph of subsection titled “E 103.4”:

Replace “PDFs” with “PDF documents and forms”.

In section B, 1st paragraph of subsection titled “E205.1”:

…specified for Web pages in WCAG 2.0 or and ISO 14289-1 (PDF/UA-1) for PDF documents

In section B, 1st paragraph of subsection titled “E205.2”:

…specified for Web pages in WCAG 2.0 or, where applicable and ISO 14289-1 (PDF/UA-1) for PDF documents.

In section B, 1st paragraph of subsection titled “E205.3”:

(i.e., WCAG 2.0 Level A and Level AA Success Criteria or and PDF/UA-1 for PDF documents)

In section B, 2nd paragraph of subsection titled “E205.3”:

(and therefore, be required to conform to WCAG 2.0 or and PDF/UA-1 for PDF documents)

In section B, 1st paragraph of subsection titled “C203.1”:

…specified for Web pages in WCAG 2.0 or, and ISO 14289-1 (PDF/UA-1 for PDF documents),…

In section B, 1st paragraph of subsection titled “C203.1”:

…specified for Web pages in WCAG 2.0 or, and ISO 14289-1 (PDF/UA-1 for PDF documents),…

In section B, 1st paragraph of subsection titled “602.1”:

…comply with WCAG 2.0 or, and PDF/UA-1 for PDF documents),…

In section B, 1st paragraph of subsection titled “602.3”:

…to conform to all Level A and AA Success Criteria and Conformance Requirements in WCAG 2.0 or and ISO 14289-1 (PDF/UA-1) for PDF documents

…but the requirement that electronic documentation comply with WCAG 2.0 or and PDF/UA-1 for PDF documents ….

VIII. Regulatory Process Matters, A.4. Benefits of the Proposed Rule

In Table 5, 2nd cell:

Since PDF stands for Portable Document Format, it’s general best practice to refer to “PDF documents” rather than “PDFs”.

VIII. Regulatory Process Matters, F. Paperwork reduction act

In the 2nd paragraph:

(2) electronic support documentation must conform to WCAG 2.0 or and PDF/UA-1, for PDF documents (602.3);

In the 2nd list item under table 12:

The estimate given for “Average response time” is grossly over-stated for the vast majority of PDF documents. In most cases, users with typical software and adequate training can achieve complete remediation of previously untagged PDF documents in a few (usually less than 10, very rarely more than 20) minutes per page, on average.

The work of setting up documents for conversion to tagged PDF is a matter of user education and training rather than additional time required. With respect to ensuring accessible content, training time scales very well not only in terms of the accessibility of the content produced, but in addition, those trained in the use of authoring tools for accessibility purposes tend to produce better documents faster in any event.