Accessibility checker and PDF/UA export in Collabora Online: what it covers
Collabora Online includes an Accessibility Checker in the Review tab that helps authors create documents according to the PDF/UA standard, published as ISO 14289 in 2012, and tagged PDF export is part of the same authoring workflow. Organizations that must publish accessible documents from a browser editor they host, such as public administrations, universities and schools, and regulated publishers, need this combination: the checker flags problems while the document is being written, and the export carries structure such as headings, reading order and alternative text into the PDF. The Collabora accessibility page describes the feature at this level, and it is the right starting point for the team that owns the document standard.
The checker supports authoring. It does not certify that a PDF conforms to PDF/UA, and it does not replace validation with a PDF/UA-aware validator or an independent accessibility audit. Plan a review step for every document class that carries legal or public obligations, and record who signs off. Ask Collabora or your own test team which checks the Accessibility Checker runs, which it leaves to the author, and how it reports findings in the document languages you use. Collabora 26.04 improved tagged PDF export for links that span multiple lines and for links inside captions and index marks, so test those constructs on your own templates before you rely on them. Your test set should include the document types your staff actually produce, not only sample files from the vendor.
Tagged PDF export toward PDF/UA: what changed in 26.04
Links are one of the constructs that Collabora Online 26.04 handles differently in tagged PDF export. The 26.04 release notes record improvements for links that span multiple lines, so a hyperlink that wraps onto the next line should carry through to the tagged output as one link. Test this in your own templates, because the result depends on how your authors create and format links.
- Single-line links: Confirm that a plain link in body text exports with its link structure and that the link text reads in a sensible order.
- Wrapped links: Check links that break across two or more lines, especially in narrow columns, since this is the case the 26.04 work targets.
- Link text: Make sure link text describes the destination. A bare URL or the phrase "click here" will be read aloud without context.
- Cross-references and contents entries: Test internal references and table of contents entries separately, because they are generated differently from typed links.
Check each link type in a test document, then run the exported file through a PDF/UA validator before you accept the template.
Captions and index marks are the second construct area named in the 26.04 release. Links placed inside a figure or table caption, and links inside index marks, were improved in tagged PDF export. Captions also shape how assistive technology presents figures and tables, so a caption that exports incorrectly can leave the related object hard to understand for a screen reader user.
- Figure and table captions: Confirm that each caption is tagged and associated with its object, and that any link inside the caption is exported.
- Index marks: Generate an index in a test file, then check that entries and their links appear in the tagged structure.
- Automatic numbering: Check captions built with automatic numbering, because the numbers in the tagged output should match what sighted readers see.
- References to captions: Test phrases such as "see Figure 2" to confirm they remain links in the exported file.
Include a sample with many captions and an index in your test set, because these constructs are often missing from templates originally built for print.
Multi-line content covers paragraphs, list items and table cells where text flows across line and page breaks. Tagged PDF depends on the export keeping that text in logical order, so the main question is whether the structure survives reflow, not only how the page looks. The 26.04 notes describe improvements for links in this kind of text, but the flow of ordinary text still needs its own testing in your documents.
- Page breaks: Test paragraphs that split across pages and confirm the text order is preserved in the tag structure.
- Lists: Check nested list items and items whose text wraps onto several lines.
- Tables: Confirm that header cells are tagged as headers and that multi-line cell text stays with the right cell.
- Hyphenation and justification: Test documents with automatic hyphenation, since split words can complicate text extraction and reading.
Validate a long, multi-page sample with lists and tables, because reflow errors often appear only after a document is revised.
Complex layouts include multi-column pages, text boxes, frames, floating images and templates built from several linked objects. The public 26.04 material focuses on links, captions and index marks, so confirm with Collabora which layout constructs the current release handles and which still need manual checks. Decide early whether each layout must export as tagged PDF or whether it can be simplified in the source document.
- Multi-column pages: Check that reading order follows the visual column order, since the tag order can follow the order in which objects were created.
- Text boxes and frames: Confirm that text inside them appears in the tag structure at a logical position.
- Floating images: Check that each meaningful image has alternative text and that decorative images are marked as decorative.
- Forms and templates: Test documents with linked fields or content controls, and record any construct that does not export as expected.
Where a layout fails validation, simplify it in the source document and retest, because a simpler structure is easier to keep accessible through future edits.
Screen reader support and keyboard shortcuts for accessible editing
Tagged output only helps readers who can actually operate the editor, so this section covers the editing side: which screen readers and browsers work with which Collabora Online application, how keyboard-only users move through documents, which shortcuts to review, and how to test with real users. DeployOpen does not hold supplied figures on screen reader coverage, so treat each item below as a test to run in your environment.
Screen reader compatibility by application and client
Screen reader behavior depends on the Collabora Online application (Writer, Calc or Impress), the browser, the operating system and the assistive technology version together, so support cannot be described as one setting. Build a test matrix that lists each combination your users actually run, and record the versions tested. Ask Collabora which combinations it has verified and confirm the results against your own documents, including tables, headings and form fields. Re-run the matrix after each major branch upgrade.
Keyboard-only navigation
Keyboard-only users need to reach the document body, the menus, the Review tab and the Accessibility Check without a pointing device, and to leave any dialog or sidebar without getting trapped. Test focus order across the editor chrome, the document and the integrating platform's frame, because the host page around the embedded editor can break focus flow. Confirm that the Accessibility Check results can be opened and worked through from the keyboard alone.
Shortcut review against your standards
Keyboard shortcuts in a browser-based editor can collide with browser, operating system and assistive technology shortcuts, so a shortcut that works in a desktop office suite may not behave the same way here. Make a list of the shortcuts your staff use daily, such as heading styles, list creation and table navigation, and verify each one in each client. Document any conflicts and the workaround you will publish, and confirm which shortcuts are documented by Collabora before you write internal guidance.
User testing with people who rely on assistive technology
Automated checks cannot tell you whether a document is pleasant to edit with a screen reader. Recruit a small group of editors and reviewers who use assistive technology in their daily work, give them realistic tasks such as creating a form, fixing a heading structure and exporting a tagged PDF, and record where they lose context. Your accessibility lead should own the findings, and the fixes should feed back into templates and training. Set the scope and cost of this testing in your own plan, since no supplied figures exist for it.
Accessibility options and when each fits
This table compares the main configuration choices for accessible documents in Collabora Online, covering who authors and checks, whether the checker gates publication, when tagged PDF export is needed, and which clients the team supports. Read each row against your document types and release process to see which combination fits your team.
| Option | What it asks of the team | When it fits |
|---|---|---|
| Authors check their own documents | Authors run the Accessibility Check in the Review tab and fix flagged items before sharing. Needs a short checklist and some training on heading styles, alt text and table headers. | Low volume internal documents where the author also owns the content and no external publication is planned |
| Dedicated reviewer checks before publication | A named role reviews flagged issues and signs off. Needs an approval step in your document workflow and a record of who checked each file. | Public-facing reports, forms and policies where a second pair of eyes reduces risk |
| Checker as a required pre-publish gate | Documents cannot be released until the check is run and issues are resolved or justified. Needs a written policy, a defined owner for exceptions and evidence kept with each release. | Regulated or public sector publishing where accessibility is a contractual or legal requirement |
| Tagged PDF export for archive or public release | Export PDFs with tags enabled and verify structure in a PDF inspection tool. Needs someone who understands tag trees and can test the output with assistive technology. | Documents that must be distributed or archived as PDF and checked against the PDF/UA standard, published as ISO 14289 |
| Editable source only, no PDF export | Keep DOCX, ODT or PPTX as the accessible deliverable and document how recipients should use them. Needs clear guidance for recipients and a fidelity test of the source files. | Internal collaboration where recipients edit files and PDF is not the required format |
| Chromium-based browsers | Confirm the browser versions your users run with screen readers and test the editor interface with them before rollout. Needs a test matrix maintained by your team. | Organizations standardized on Chrome or Edge on managed desktops |
| Firefox and Safari clients | Test the editor with your chosen screen reader on each browser and operating system in use. Confirm supported combinations with Collabora before committing. | Mixed device estates or public users who cannot be limited to one browser |
| Screen reader and keyboard only users | Document the keyboard shortcuts your staff rely on, verify focus order in the editor and confirm the screen reader setup in a pilot group. | Teams with staff who depend on assistive technology for daily document work |
How to set up accessible document export on your Collabora Online server
This sequence takes a Collabora Online deployment from version confirmation to a documented set of tagged PDF exports checked against PDF/UA, so you can show which documents passed and which still need author fixes.
Confirm the release includes the tagged PDF improvements
Your platform or administrator checks which Collabora Online version your server runs and compares it with the release notes for the version you plan to standardize on. Collabora's 26.04 release notes describe improved tagged PDF export, including links that span multiple lines and links inside captions and index marks, so a server on an older branch may produce different tag structures. Record the exact version string from the server and the release notes you checked. Done when the version and the relevant release note entries are written into your test record. Confirm the exact fixes against the release in use, not from memory.
Enable the Review tab workflow for authors
Work with the team that runs your Nextcloud or other WOPI host to make sure authors open documents in the editor where the Review tab and its Accessibility Check are available. Confirm with your vendor or your own test instance which menu path and any host-side settings apply to your release, because labels and placement can change between versions. Decide who in your organization owns the authoring template and the checklist authors follow. Done when a test author can open the Review tab in an editing session and locate the Accessibility Check command.
Build a test corpus of representative documents
Assemble a small, fixed set of documents that reflects what your organization actually publishes: reports with headings, tables, images with alternative text, hyperlinks, captions, index entries and forms if they are in scope. Keep the originals under version control and label each file with its expected accessibility features. Include a few deliberately flawed files so you can confirm the checker reports problems. Done when the corpus is stored, each file has a purpose note, and the same files can be reopened for every later run.
Run the Accessibility Check on each document
Open each corpus document in the editor, run the Accessibility Check from the Review tab, and save the report output. Authors or a reviewer should note every issue the checker raises, including the location in the document and the rule it cites. Fix the issues in the source document where possible and rerun the check until the remaining items are understood and accepted. Done when every corpus file has a saved check result and a list of open issues with owners.
Export tagged PDF from the checked documents
Export each corrected document to PDF with tagged PDF enabled, using the export options exposed in your release. Keep the export settings identical across the corpus so results are comparable between runs. Confirm the export option names in your release, since they may differ from older documentation. Done when each document has a tagged PDF file generated from the same settings and stored with its source.
Validate the exported PDFs against PDF/UA
Run the tagged PDFs through a PDF/UA validation tool that your team selects and documents. The standard is published as ISO 14289, and you should refer to its title and the tool's rule output rather than copying text from the standard. Record each validator's name, version and rule results. Treat a validator result as technical evidence only, since validation does not replace review by an independent assessor when you need formal conformance claims. Done when every exported file has a validation report attached.
Record results and set the rollout gate
Write a short record for each run that lists the Collabora Online version, the corpus version, the Accessibility Check findings, the export settings, the validator and its results, and the remaining exceptions with owners. Agree with the accessibility and compliance leads which exceptions block rollout and which are accepted for a defined period. Repeat the same sequence after each Collabora Online update, because tagging behavior can change between releases. Done when the record is signed off and the next update trigger is named.
Security and operational considerations for accessible documents
Accessible output is only as trustworthy as the server producing it and the workflow around it. The cards below cover patching, metadata in exported files, confidentiality of documents under review and version drift between authoring and validation, each tied to a step the platform team owns.
Stay on a supported release
Collabora publishes security advisories for Collabora Online, and the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Your platform team should subscribe to advisories, track which branch each server runs, and schedule point releases on a fixed cadence. Confirm with Collabora which branch receives signed security updates for your edition, since a server left on an old branch can keep producing tagged PDFs with known defects.
Review metadata in exported PDFs
A tagged PDF carries structure tags, document language, title and alternative text, and it may also carry author, application and editing metadata. Before a file leaves the organization, decide which fields must be kept for accessibility and which should be stripped or reviewed. Test a sample export from your own templates and inspect it with a PDF metadata tool so that internal author names or file paths do not reach public portals.
Restrict access to confidential drafts
The Accessibility Checker runs on the document while it is open, so anyone who can open a draft can also see its check results and its content. For confidential files, limit which groups can use the editor and which can edit, as the Nextcloud administration manual describes for Nextcloud Office. Restrict WOPI requests to the Collabora server addresses and use HTTPS for the server URL, so that documents and check results do not travel over unprotected channels.
Pin the server and the validator
Accessibility checks and PDF/UA output depend on the Collabora Online version, so an author using a newer build may see warnings that a validator on an older build does not, or the reverse. Record the Collabora Online version used for authoring, the version used for export and the validator used for final checks, and keep them aligned in the change process. Collabora improved tagged PDF export in 26.04, including links spanning multiple lines and links inside captions and index marks, so re-test documents with links after any upgrade.
Keep the checker out of the toolchain alone
The Accessibility Checker helps authors create documents that follow PDF/UA, which is published as ISO 14289, but it does not certify a file. Operationally, the platform team should document which checks are performed in the editor, which are performed by a separate validator, and who signs off a document before publication. Ask the team that owns accessibility policy to define the sign-off step, so that a passing editor check is never mistaken for an audit result.
Questions buyers ask about accessibility checks and PDF/UA export
Does the Collabora Online accessibility checker prove PDF/UA conformance?
No. The Accessibility Check in the Review tab helps authors create documents according to the PDF/UA standard, which is published as ISO 14289, but it does not certify a file as conformant. Conformance is a judgment that needs manual review of reading order, alternative text, language settings, table headers and tagging, and an independent assessment if you need evidence for an audit or a procurement requirement. Ask your accessibility specialist which checks they will run on a sample of output files and which results they will accept as evidence. DeployOpen prepares the workflow, templates and test documents, but does not issue conformance reports or certifications.
What drives the effort and cost of accessibility testing?
Effort follows the number and variety of document types, not the checker itself, which runs inside the editor. The main drivers are:
- The count of templates and document families (reports, forms, contracts, slide decks, spreadsheets) that must export tagged PDF.
- How many authors will create content and how much of the existing archive must be remediated.
- Whether you need manual testing with assistive technology such as screen readers, and how many test passes that requires.
- How much documentation and training your staff need.
Costs split into one-time work (test corpus, templates, fixes, training) and recurring work (re-testing after each Collabora Online upgrade). Ask any provider for a written scope that lists document types, test methods and deliverables, because those items determine the quote.
How long does an accessibility pilot take and what does it need from our team?
The length depends on how many document types the pilot covers and how quickly your team can supply representative files. Collabora's sources do not publish a standard pilot duration, so ask for a timeline in the written scope rather than relying on a generic figure. A useful pilot needs a set of real but non-sensitive documents from each template family, a named owner who can decide what counts as acceptable output, access to a test Collabora Online instance, and one or two reviewers who can test with a screen reader. Plan for the pilot to surface a backlog of template fixes, since those are usually the largest source of recurring defects.
Can our team run accessibility checks and PDF/UA export without outside help?
Often yes for the basic workflow, and no for conformance assurance. Authors can run the Accessibility Check from the Review tab and export tagged PDFs without a partner. Outside help usually matters in three places: setting document templates so that headings, tables and alternative text are correct from the start, validating exports against the standard with a suitable tool and a trained reviewer, and producing evidence for an audit. Many teams split the work, keeping routine checking in-house and bringing in specialist review for high-risk documents. Decide that split before the pilot so the scope reflects who will own each step.
Which skills does the team need for tagged PDF and PDF/UA work?
The work needs a mix of document, accessibility and platform skills:
- Document design skills to build styles, heading hierarchies, table structures and caption use in Writer, Calc and Impress.
- Accessibility review skills to judge reading order, alternative text quality and colour contrast, and to read the PDF/UA requirements in plain terms.
- Assistive technology skills to test exports with at least one screen reader and to use the keyboard shortcuts that the editor supports.
- Platform skills to upgrade Collabora Online, keep its release line current and track fixes in each release, such as the 26.04 improvements to tagged PDF links.
Identify who holds each skill before the pilot starts, and budget training for the gaps.
Do newer Collabora Online releases change tagged PDF output?
They can. Collabora Online 26.04 improved tagged PDF export, including links that span multiple lines and links inside captions and index marks, according to the 26.04 release notes. That means a template that passed review on an earlier branch may produce different tags after an upgrade. Build a regression set of documents that covers links, captions, index marks and tables, export them before and after each upgrade, and compare the tags. Confirm with Collabora which fixes apply to your branch, and treat any change in tagged output as a reason to re-test the affected templates.
What should we ask for in a quote for accessibility work?
Ask for a written scope that names the document families in scope, the Collabora Online version and branch, the test methods (checker only, manual review, screen reader testing), the deliverables (templates, test corpus, guides, training, a remediation log) and the acceptance criteria. Ask whether the quote covers re-testing after upgrades, which is usually a recurring cost. Ask who signs off on acceptance and what evidence they receive. DeployOpen provides fixed-scope engagements agreed in writing before work starts, with ongoing support available as a retainer, and does not publish a price list, so the quote follows from that scope.
How DeployOpen scopes accessibility work for Collabora Online
DeployOpen scopes accessibility work as a written, fixed-scope engagement agreed before any configuration starts. The scope names the Collabora Online version in use, the document types covered (Writer, Calc and Impress, along with any PDF exports that leave the platform), the people who create and review documents, and the deliverables. Most engagements are fixed-scope, so the agreed scope sets what is delivered and what is a change request. A quote follows from that written scope, and DeployOpen does not publish a price list. Ask for the scope to list which Accessibility Check findings are in and out of the agreement, because an automated checker reports a fixed set of issues that still needs human judgment to resolve.
Next, DeployOpen and the client define a test corpus together. The corpus is a set of representative files drawn from the client's own documents: headings-heavy reports, forms, tables, documents with images and captions, and documents with cross-references, links and index marks. Those files are run through the Accessibility Check in the Review tab and exported with tagged PDF export toward PDF/UA (ISO 14289). The results are checked in the client's own infrastructure, against the client's own Collabora Online installation, so no document content leaves their environment. Confirm the Collabora Online version in use before building the corpus, since tagged PDF export behavior changes between releases. The Collabora Online 26.04 release notes list recent improvements to link tagging in captions and index marks, which is a good reason to re-run the corpus after any upgrade.
DeployOpen then delivers documented evidence for compliance assessments: the configuration record, the corpus, the test results, known gaps and the owner of each open item. DeployOpen prepares systems, controls and evidence. It does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. Ongoing support, including re-testing after Collabora Online point releases and new document templates, is available as a retainer, and the retainer terms are agreed in writing like the original scope.
