Section 508 Document Remediation Services: A Procurement Guide for Accessible PDFs and Digital Content

Section 508 Document Remediation Services: A Procurement Guide for Accessible PDFs

A PDF can look perfectly usable and still be difficult—or impossible—for someone using a screen reader, keyboard navigation or another assistive technology.

A heading may only look like a heading.

A table may make sense visually while exposing no usable relationship between headers and data.

A scanned PDF may contain readable-looking pages that are effectively images with little or no meaningful structure.

And an automated accessibility checker may report fewer errors while real usability problems remain.

For U.S. federal agencies and organisations producing digital content for them, these issues can become more than document-quality problems. They can affect Section 508 procurement, testing and acceptance.

The stronger approach is therefore not:

Create → Find Problems → Repair Later

It is:

Define → Audit → Remediate → Validate → Human Test → Retest → Accept

That lifecycle is already central to Gentize's existing Section 508 article.

Quick Answer: What Is Section 508 Document Remediation?

Section 508 document remediation is the process of identifying and correcting accessibility barriers in applicable electronic documents so people with disabilities can access the same information and functionality.

Depending on the document, remediation may address:

• Semantic structure
• Heading hierarchy
• Logical reading order
• Alternative text
• Accessible tables
• Lists
• Links and navigation
• Accessible forms
• Document language
• Metadata
• Accessibility validation
• Human QA
• Assistive-technology testing

These areas are already part of the current Gentize remediation scope.

For buyers, one principle matters most:

Define accessibility requirements, testing methods and acceptance evidence before remediation begins.

What Does Section 508 Cover?

Section 508 of the Rehabilitation Act addresses accessibility of information and communication technology used by U.S. federal agencies.

The Revised Section 508 Standards apply to ICT that agencies develop, procure, maintain or use. Electronic content is part of that scope.

Relevant content can include:

• PDF documents
• Reports
• Electronic forms
• Presentations
• Spreadsheets
• Training materials
• Policies
• Electronic publications
• Support documentation

For procurement teams, that leads to an important rule:

Accessibility should be treated as a deliverable requirement—not as an optional QA activity after delivery.

That principle is also stated directly in the current Gentize article.

Section 508 vs WCAG vs PDF/UA

Accessibility terminology often becomes confusing because Section 508, WCAG and PDF/UA are frequently discussed together.

They are related, but they serve different purposes.

The current Revised Section 508 Standards incorporate WCAG 2.0 Level A and Level AA criteria for applicable electronic content, subject to the relevant provisions.

This means procurement language should avoid vague requirements such as:

“Make the PDF compliant.”

Instead, define:

• Applicable Section 508 requirements
• Any additional WCAG expectations
• Whether PDF/UA is part of the specification
• Required testing methodology
• Acceptance criteria
• Required accessibility evidence

Key Point

Section 508, WCAG and PDF/UA can work together, but they should not be presented as interchangeable standards.

Section 508 PDF Remediation Is More Than Adding Tags

One of the most common misconceptions about accessible PDFs is:

“Add tags and run an accessibility checker.”

Tags are important.

But accessibility depends on whether the structure represented by those tags is meaningful.

A document can contain tags and still have:

• Incorrect heading levels
• Poor reading order
• Weak image descriptions
• Inaccessible tables
• Unhelpful links
• Incorrectly marked decorative content
• Difficult navigation

The current Gentize article makes this distinction clearly: the real question is whether document structure communicates the same meaning that the visual presentation provides.

What Should Section 508 PDF Remediation Include?

1. Semantic Structure

A document should expose meaningful elements such as:

• Headings
• Paragraphs
• Lists
• Figures
• Captions
• Tables
• Links

Visual formatting alone is not enough.

Assistive technologies need meaningful document structure to understand how the content is organised.

2. Heading Hierarchy

Headings allow readers to understand and navigate a long document efficiently.

Remediation should verify that:

• Headings are correctly tagged
• Levels follow a logical hierarchy
• Heading text describes the section
• Navigation remains predictable

A line that is simply larger or bold is not automatically a semantic heading.

3. Logical Reading Order

Sighted readers often understand a page through visual placement.

Assistive technologies may encounter the same page sequentially.

That becomes important when documents contain:

• Multiple columns
• Sidebars
• Captions
• Floating images
• Footnotes
• Complex visual layouts

The underlying reading sequence should preserve meaning rather than simply follow visual coordinates.

4. Meaningful Alternative Text

Alternative text should communicate information that would otherwise be unavailable to the reader.

Accessibility QA should consider:

• Whether an image is meaningful or decorative
• What information the image contributes
• Whether short alt text is sufficient
• Whether a longer description is necessary
• Whether surrounding text already provides the same information

For example:

Weak:
“Image of chart.”

Better approach:
Describe the important trend, comparison or conclusion represented by the chart.

Alt text requires context—not merely image recognition.

This principle is already highlighted in the current article.

5. Accessible Tables

Tables are often among the most difficult document structures to remediate correctly.

Review should consider:

• Row and column headers
• Header relationships
• Merged cells
• Multi-level headers
• Reading sequence
• Captions
• Notes

The most useful QA question is:

Can a reader understand the relationships inside this table without depending on visual position alone?

6. Lists

Lists should use actual list structure rather than paragraphs beginning with visual bullet characters.

Correct structure is especially important for:

• Numbered procedures
• Nested lists
• Multi-level outlines
• Step-by-step instructions

Proper list structure helps assistive technologies communicate hierarchy and sequence.

7. Links and Navigation

Accessible documents should make navigation efficient and predictable.

Useful elements can include:

• Descriptive links
• Bookmarks
• Table-of-contents links
• Internal document destinations
• Meaningful document titles

Avoid vague link text such as:

“Click here.”

Prefer wording that explains the destination:

“Download the Section 508 testing guide.”

8. Accessible Forms

Forms introduce additional accessibility requirements because users must not only read the document—they must interact with it.

Important considerations include:

• Clear field labels
• Programmatic relationships
• Logical keyboard navigation
• Required-field identification
• Useful instructions
• Accessible controls
• Error identification
• Predictable focus order

The existing article already identifies form labels, keyboard sequence, required fields, instructions, error handling and common form controls as remediation concerns.

INSERT IMAGE HERE

Image Heading:
What Makes a PDF Form Accessible?

Do not add a written form layout inside the article. Use the separate visual showing an example accessible form and accessibility callouts.

Image Alt Text:
Accessible PDF form example showing clear labels, required-field identification, logical keyboard navigation, grouped controls, instructions, visible focus and accessible error handling.

Image Caption:
An accessible PDF form combines clear labels, logical keyboard navigation, correctly structured controls, helpful instructions and understandable error feedback.

Suggested Filename:
section-508-accessible-pdf-form-example-gentize.webp

Automated Testing vs Human Accessibility QA

Automated accessibility testing is valuable.

It can identify technical problems quickly and consistently.

But automation cannot evaluate every accessibility issue.

The existing Gentize article makes the same distinction: automated testing identifies technical conditions, while human QA evaluates meaning, reading order, usability and assistive-technology behaviour.

The strongest approach combines:

Automated Validation + Human Review + Assistive-Technology Testing

Automation identifies patterns.

Human testing determines whether the content actually works.

A Scalable Section 508 Document Remediation Workflow

Large document backlogs should not begin with random file-by-file remediation.

A professional programme starts by understanding the collection.

Stage 1 — Inventory

Build a basic inventory covering:

• File format
• Page count
• Source-file availability
• Document owner
• Publication status
• Scanned pages
• Tables
• Images
• Forms

This establishes the true scope of the project.

Stage 2 — Determine Requirements

Before production begins, determine what the finished document actually needs to meet.

Define:

• Applicable accessibility requirements
• Contract requirements
• Testing methodology
• Acceptance criteria
• Required documentation

The goal is to answer:

What exactly does this deliverable need to meet?

before remediation starts.

Stage 3 — Sample the Collection

Do not estimate thousands of documents based on one straightforward PDF.

Select representative samples containing:

• Simple documents
• Scanned PDFs
• Table-heavy reports
• Image-rich publications
• Forms
• Long technical files
• Older legacy documents

Sampling helps reveal recurring accessibility patterns.

Stage 4 — Classify Complexity

Not every PDF requires the same amount of remediation.

A practical classification model can include:

Simple

Mostly text with straightforward headings and limited imagery.

Moderate

Includes lists, images, links and basic tables.

Complex

Includes advanced tables, charts, forms, multiple columns or complicated page layouts.

Specialist

Contains mathematical, scientific, multilingual or highly visual content.

This makes production estimates more realistic.

Stage 5 — Define Remediation Rules

When recurring issues are identified, define how the production team should handle them.

Examples include:

• Heading hierarchy
• Table treatment
• Decorative imagery
• Alt-text workflow
• Bookmarks
• Scanned content
• Form controls

This improves consistency when multiple files or production specialists are involved.

Stage 6 — Remediate and Validate

Apply the approved accessibility corrections.

Then perform the required technical validation.

The objective should not be:

Reduce the number of checker errors.

It should be:

Create a document with meaningful and usable accessibility structure.

Validation provides important technical evidence, but it should not automatically be treated as final accessibility sign-off.

Stage 7 — Human and Assistive-Technology QA

Representative human testing should examine:

• Navigation
• Reading sequence
• Headings
• Tables
• Image descriptions
• Links
• Forms

Where appropriate, assistive-technology testing can provide additional evidence of practical usability.

Stage 8 — Correct, Retest and Deliver

Accessibility defects should complete a full QA cycle:

Identify → Correct → Retest → Approve

Final delivery can then include the required documentation and QA evidence.

Retesting matters because fixing one part of document structure can affect another.

Why Accessibility Requirements Belong in Procurement

Accessibility becomes much easier to manage when it is defined before work begins.

A procurement specification should clearly identify:

• Content in scope
• Applicable accessibility requirements
• Required file formats
• Testing methodology
• Acceptance criteria
• Required accessibility evidence
• Responsibility for remediation
• Retesting requirements
• Handling of unresolved issues

The current article also stresses that accessibility expectations should be defined in procurement documents rather than after delivery.

The principle is simple:

Do not wait until delivery to define what “accessible” means.

VPAT vs ACR: What Buyers Need to Know

The terms VPAT and ACR are frequently used as though they mean the same thing.

They do not.

VPAT

VPAT stands for Voluntary Product Accessibility Template.

It is a template used to document how a product or service addresses accessibility requirements.

ACR

An Accessibility Conformance Report is the completed accessibility report produced using an appropriate reporting template.

The easiest way to remember the difference is:

VPAT = Template
ACR = Completed Report

An ACR can provide useful procurement evidence.

But it should not be treated as a blanket accessibility certification guaranteeing that every aspect of a product or service is accessible.

Accessibility Evidence Matters More Than a Single Claim

Procurement teams should move beyond asking only:

“Does the vendor have an ACR?”

A stronger question is:

“What evidence supports the accessibility claims, and what barriers remain?”

Useful evidence may include:

• Accessibility evaluation methods
• Technical validation results
• Human QA findings
• Assistive-technology testing results
• Accessibility issue reports
• Known limitations
• Remediation evidence
• Retesting results

This approach makes accessibility measurable instead of relying on general compliance language.

Questions to Ask a Section 508 Remediation Partner

A remediation vendor should be able to explain the complete production process.

Standards and Scope

• Which accessibility requirements will you evaluate against?
• Which file formats can you remediate?
• How do you determine the applicable requirements?

Remediation

• How are complex tables handled?
• How are scanned PDFs processed?
• How is alt-text quality reviewed?
• How are interactive forms evaluated?

Testing

• Which checks are automated?
• Which issues receive human review?
• Which assistive technologies are used?
• Are corrected documents retested?

Quality and Delivery

• How do you maintain consistency across large volumes?
• What evidence accompanies delivery?
• How are unresolved accessibility issues documented?

The current Gentize article already includes these vendor-evaluation themes.

Red Flags When Choosing a Remediation Partner

Be cautious when a vendor makes claims such as:

“Accessibility can be guaranteed automatically.”

Many accessibility decisions depend on context and human judgment.

“If the checker passes, the PDF is accessible.”

A technical validation result does not automatically prove practical usability.

“Every PDF requires roughly the same amount of work.”

A simple two-page policy and a 200-page technical report containing tables, forms and charts can require very different remediation effort.

“AI-generated alt text never needs review.”

Automation can help, but meaningful descriptions still require context.

“Corrected documents do not need retesting.”

Without retesting, the final result remains unverified.

These same risks are identified in the existing article.

Section 508 Document Acceptance Points

Before accepting a remediation delivery, confirm that:

• Applicable requirements are documented
• Representative documents were audited
• Document complexity was considered
• Heading hierarchy is meaningful
• Reading order is logical
• Images have appropriate alternatives
• Tables expose meaningful relationships
• Lists are structurally correct
• Links provide useful context
• Forms are accessible where applicable
• Automated validation has been completed
• Human accessibility QA has been performed
• Assistive-technology testing is included where appropriate
• Corrections have been retested
• Final accessibility evidence is documented

These acceptance areas are also present in the current Gentize article.

Why Post-Award Accessibility Verification Matters

Writing accessibility requirements into a contract or RFP is only part of the process.

The delivered content still needs to be verified.

A strong accessibility procurement lifecycle connects:

Requirement → Vendor Evidence → Production → Testing → Acceptance

Without verification, accessibility requirements risk becoming promises rather than confirmed outcomes.

The current article specifically emphasizes post-award verification, testing and final acceptance.

How Gentize Innovations Supports Accessible Document Production

Gentize Innovations supports organisations managing accessibility across PDFs, EPUBs and broader digital-content workflows.

The current Gentize article lists capabilities including:

• PDF/UA and accessible EPUB remediation
• WCAG auditing and remediation
• Screen-reader testing using NVDA, JAWS and VoiceOver
• Section 508 and EN 301 549 work
• VPAT and ACR documentation
• Alt-text and structural tagging
• EPUB and ONIX accessibility metadata
• Accessibility documentation and monitoring

Gentize's published workflow is:

Audit → Remediate → Test & Sign-off → Document & Monitor

The current article also references a 35,000-title accessible EPUB backlist programme, demonstrating experience operating accessibility within a large publishing-production workflow.

For organisations managing a large document backlog, the goal should therefore not simply be:

Remediate more files.

It should be:

Build a repeatable accessibility-production process that maintains quality as volume increases.

Final Takeaway

Section 508 document remediation is more than fixing PDF tags.

It connects:

• Accessibility requirements
• Document structure
• Human usability
• Assistive-technology testing
• Procurement evidence
• QA
• Final acceptance

For large document collections, a stronger approach is:

Define → Audit → Classify → Remediate → Validate → Human Test → Retest → Accept

That creates clearer expectations for procurement teams, more consistent production for remediation partners and more usable information for people with disabilities.

Most importantly:

Do not define accessibility after the documents have already been delivered. Build it into the requirement, production workflow and acceptance process from the beginning.