PDF portfolios and attachments: accessibility

Review a PDF portfolio or attachment package as a complete delivery system: the container, its navigation, every included file, and the software needed to open them. A tagged cover page is only one component. Readers must be able to discover the materials, understand their relationship, and open the appropriate version without guessing which hidden attachment contains the information they need.

Distinguish a portfolio from a merged PDF

Adobe's portfolio overview describes packages containing separate files rather than simply combining all pages into one document. It also warns that browser, email, or other viewers may show a request to open the portfolio in Acrobat or Reader. Do not assume that a successful desktop preview predicts the experience on a public website or phone.

For a fictional consultation package, the components might be a main proposal, a spreadsheet of supporting data, a response form, and a diagram. Decide whether embedding them is necessary or whether an accessible web index with separate downloads better serves the audience. The choice should follow reader tasks, version control, and handling requirements, rather than a preference for sending one file.

Create an inventory before reviewing the container

Illustrative inventory for a consultation package.
Component	Purpose	Review responsibility
Main proposal PDF	Explains the consultation and questions	Document structure, navigation, and content owner
Supporting workbook	Provides detailed values	Spreadsheet accessibility and data owner
Response form	Collects feedback	Labels, validation, completion route, and process owner
Site diagram	Explains the proposed arrangement	Equivalent explanation and subject-matter reviewer

Include file names, formats, versions, owners, and the reason each component is included. Remove obsolete drafts from the release package through an approved editorial decision. A file named 'final-v2-new-final' gives readers little confidence about which content applies. Use descriptive names and provide a readable explanation of the relationships in the main document or publication page.

Make attachments discoverable and understandable

Adobe's attachment instructions include adding descriptions in the Attachments pane. Use such metadata where supported, and also provide visible instructions that do not assume every viewer exposes an identical pane. Explain what each attachment is for and whether a particular application is needed.

Test the route from the publication page into the package and then into each component. Can a keyboard user discover the list, identify the relevant file, and open or save it? Can a reader tell whether a spreadsheet is required to complete the task or merely optional supporting detail? Record the actual behavior in the intended environment rather than relying on the author's familiarity with the editor.

Review each component in its own format

An embedded PDF needs its own structural and reading checks. A workbook needs an appropriate spreadsheet review; a response form needs interaction and error recovery testing. Packaging does not convert those requirements into a single container-level pass. Keep evidence attached to the exact component version so replacing a file does not silently inherit the previous version's approval.

Adobe documents attachment security controls that can block or allow file types. Treat a blocked attachment as a delivery constraint to investigate, not an instruction to weaken the reader's security settings. Consider a permitted, accessible distribution route with the same appropriate access controls.

Test the delivered package and its alternatives

Download the release candidate through the actual publication route and confirm its identity.
Open it in each supported environment, recording portfolio and attachment behavior.
Reach every required component using a keyboard and confirm that names and descriptions are useful.
Review each component's content and accessibility using a format-appropriate process.
Test any separate-download alternative and confirm that its versions match the package.

For public material, an accessible index page can explain the package and offer individual files without requiring portfolio support. For restricted material, preserve the intended permissions on every alternative route. A convenience fallback should not accidentally publish files that were meant for a limited audience.

Keep the inventory and review record with the release. Use the board-packet workflow for editorial assembly, the merge guide when producing one continuous PDF, and the form guide for interactive components. State unresolved viewer limitations clearly instead of describing the entire package as checked because its cover passed.

Frequently asked questions

Does an accessible cover make the attached files accessible?

Each component retains its own content and interaction requirements. Review the cover, container navigation, and every required attachment separately, with evidence tied to the exact versions included in the release.

Will a PDF portfolio work in every browser?

Adobe documents that some browser, email, and other viewers may require opening the portfolio in Acrobat or Reader. Test the intended distribution environments and offer a suitable alternative route when required components are not discoverable or usable.

Should readers disable attachment security to open the package?

A publication workflow should respect the reader's security environment. Investigate blocked file types and provide an appropriate permitted delivery route instead of making weaker attachment security a prerequisite for accessing the content.

Sources

The statements above rest on the primary sources below. Where a source is a law or standard, the version and date named in the text are the ones checked on the review date. This guide is general information, not legal advice.

PDF portfolios and attachments: review the whole delivery