Editorial — October 26, 2026. The final check before sending a document is often a glance. Does the logo sit correctly? Did a table spill onto another page? Is the last line missing? Those are worthwhile questions. They are not enough to decide whether the document works.
Mozilla’s Firefox 158 release notes, dated October 13, include an unusually practical improvement: more accessible PDFs when saving pages as PDF and when printing on Linux and macOS. Mozilla also says the change fixes rendering problems, including missing mathematical symbols. This is a release-note claim, not a test of every document a reader might export.
Export is part of publishing
We should pay more attention to changes like this. A browser is not just a window onto someone else’s website. It is also a document factory. People use its print dialog to create meeting papers, reference copies, instructions and records that travel far beyond the original page.
The person receiving that file may never see the website, know which browser produced it or have a useful way to request a better version. The export becomes the publication. A broken reading experience is not made less important because it began with an ordinary menu command.
Our editorial position is that the export deserves its own review. Calling the source accessible, attractive or standards-based cannot substitute for checking the file that actually leaves the organization.
A page has more than one order
The W3C’s PDF reading-order technique explains why structure matters. In tagged PDFs, tag order is central to reading sequence. A multi-column page can look sensible while being read across columns in an incoherent sequence. The guidance recommends checking reading order with assistive technology or an accessibility tool, and checking keyboard navigation through focusable elements. Complex layouts may still need repair after conversion.
That is a useful corrective to the idea that accessibility is something a conversion checkbox completes. Tools can preserve more structure and prevent more failures; they cannot decide whether the story told by a specific document still makes sense in every representation.
Review the experience, not just the screenshot
For a small team, a sensible review can begin with one representative document rather than an intimidating promise to fix the entire archive overnight. Choose something people genuinely depend on: an instruction sheet, a public report or the form that starts a service request.
Give the exported version to someone who did not make it. Ask whether the important information is findable, whether links make sense outside their surrounding paragraph and whether the intended reading sequence survives. Where the team lacks accessibility-testing experience, get help rather than treating a quick visual inspection as certification.
These are proposed working habits, not a complete compliance checklist. The point is to give someone responsibility for the delivered experience. A file that passes a superficial review can still leave a reader doing unnecessary reconstruction.
Keep a usable alternative
There is also a product decision before the PDF exists: does this information need to be a file at all? Sometimes a stable, readable web page is the better primary version, with a download offered for people who need it. Sometimes a document is necessary. Teams should make that choice deliberately instead of treating the attachment as the default form of seriousness.
When there are two versions, keep their meaning aligned and make the alternative easy to find. A neglected web copy is not a useful accessibility strategy, just as an elegant PDF is not useful if readers cannot navigate it.
Firefox’s improvement is welcome because better defaults reduce the work required to do the right thing. But defaults should start the quality process, not end it. A document is finished when its intended readers can use it—not merely when its author likes the preview.
Featured photo: Andrew Neel / Unsplash, used under the Unsplash License. Illustrative stock photograph.
