A student uploads an application PDF minutes before a deadline. The page turns red and says “Invalid file”. Is the document too large, the wrong format, or has the session expired? Without an explanation, the next attempt is guesswork. For teams building document-submission forms, the error message is part of the workflow—not a decorative afterthought.
New guidance puts recovery first
On 15 October 2026, the US General Services Administration's Section508.gov published new Accessibility Bytes guidance on clear form instructions and error messages. It recommends explaining requirements before people enter information, identifying what went wrong and how to correct it, and avoiding colour-only signals or technical jargon.
This is practical accessibility guidance, not a new PDF format or a new legal requirement. Its value for document portals is straightforward: users should not have to reverse-engineer a failed submission.
Explain the rules before the file picker
Write down the restrictions the upload service actually enforces. These might include file type, maximum size per file, total attachment size, file count, or whether password-protected documents are accepted. Do not display restrictions that the service does not have.
For a fictional application portal, an instruction could read: “Attach up to three PDF files. Each file must be 5 MB or smaller.” That is clearer than “Upload supporting documents” followed by an unexplained rejection. These example limits are not FileStation's limits.
Place essential instructions next to the relevant control. A long help page elsewhere is not a substitute for information people need at the moment they choose a file.
Match the message to the failure
Different failures need different next steps. If the service can establish the cause, a useful response might be:
- Oversized file: “Report.pdf is 7.2 MB. The limit is 5 MB per file. Choose a smaller copy.”
- Wrong format: “This file is a Word document. This form accepts PDF files. Export a PDF copy and try again.”
- Service problem: “The upload could not finish. Your file has not been submitted. Try again.”
These are illustrative messages, not universal templates. Never claim to know the cause when the system cannot distinguish it. Compressing a document will not solve a server outage, and repeatedly renaming its extension will not convert its format.
Where possible, retain completed form entries after an upload fails. Show which attachment needs attention instead of forcing someone to start the whole application again.
Confirm what actually happened
The W3C forms notification tutorial distinguishes feedback near individual fields from overall submission feedback and highlights the importance of success notifications.
For a document portal, “File attached” and “Application submitted” should mean different things. Show the selected filename and a clear state, then provide a separate confirmation when the final submission succeeds. A green border alone is not enough information.
Test incorrect formats, oversize files and interrupted uploads deliberately. Check the experience on a narrow phone screen, with enlarged text, keyboard navigation and a screen reader. These checks can expose problems; they do not certify accessibility or replace testing with disabled users.
A useful next step for PDF users
If a portal gives a genuine size-limit error, FileStation's Compress PDF can help prepare a smaller copy. Keep the original and inspect the result with PDF Reader before submitting it. Compression cannot guarantee a particular target size or acceptance by another website.
Clear upload messages help people recover from errors. They do not, by themselves, make the uploaded PDF accessible or establish Section 508 compliance.