Collabora Online accessibility for EN 301 549 and WCAG 2.2: where the platform helps and where it stops
Collabora Online is a self-hosted editor, and its accessibility conformance against EN 301 549 and WCAG 2.2 must be tested by the buyer, not assumed from the product name. A public body or supplier facing an accessibility clause in a tender needs evidence for the specific deployment, including the browser, the assistive technology, the document types and the host platform the editor runs inside. The supplied facts do not establish a conformance level for Collabora Online, so ask the vendor for its current accessibility documentation and any published test results for the release you plan to run, and confirm which version those results cover.
The platform touches the requirement in three places. The editor's own interface and document features, including Writer's handling of headings, structure and the built-in accessibility checker, are the first. PDF/UA export is the second, since it bears on whether documents leaving the editor remain usable with assistive technology, though the export result still needs checking with a PDF/UA validator. The third is everything the platform does not control: the WOPI host page that embeds the editor, the login flow, the file browser, the document authoring habits of your staff and the content of files created before rollout. Those parts sit in the host's conformance scope and in your own content process.
DeployOpen prepares test records for this work but does not issue conformance statements. A practical plan is to define the user journeys in scope, run the checker and manual tests against Writer and exported PDFs in your chosen browsers, record each WCAG 2.2 success criterion as pass, fail or not applicable with the evidence, and hand the results to the people who publish the accessibility statement. The statement and any independent review remain your responsibility or that of an accredited assessor. Expect the test scope, and therefore the effort, to grow with the number of host integrations and document types you commit to.
Mapping requirements to Collabora Online capabilities and configuration
This table maps the accessibility obligations that public bodies face to what Collabora Online can contribute and how to configure it. Read the middle column as what is documented or expected, and treat every cell marked for vendor confirmation as an open question to close before you commit to a conformance claim. The main takeaway is that the editor only produces part of the evidence, and the document content and the audit scope remain your responsibility.
| Requirement | Platform capability | Configuration |
|---|---|---|
| ADA Title II WCAG 2.1 Level A and AA deadline | Applies to state and local government web content and mobile apps, including content provided through contracts or licenses. Collabora Online's conformance to WCAG 2.1 must be confirmed with the vendor. | Confirm the 26 April 2027 (50,000 or more people) or 26 April 2028 (smaller entities) date that applies to your entity, then record which editor version you assessed. |
| Contracted-service obligation | The obligation can pass through to a hosted or licensed editor, so the public body remains answerable for the accessible experience it offers. Vendor accessibility documentation is not confirmed by this table. | Request the vendor's accessibility statement and conformance report in writing, and add accessibility terms and update obligations to your contract or support agreement. |
| Document formats (docx, xlsx, pptx, PDF, ODF) | Collabora Online supports OpenDocument and Microsoft formats including docx, xlsx and pptx, plus PDF. Accessibility of each format's content depends on how the author built it. | Define the formats in scope, then test representative files for headings, alt text, table headers and reading order before and after rollout. |
| Writer accessibility checker | Writer's accessibility checker is a LibreOffice feature. Whether and how it runs in the browser editor must be confirmed with the vendor for your version. | Confirm the checker is available in your deployed version, then document how authors run it and how results are recorded. |
| PDF/UA output | PDF export is supported. Whether exported files meet PDF/UA (ISO 14289) structure requirements must be confirmed and tested, not assumed. | Export test documents to PDF, validate them with an external PDF/UA checker, and record the results per document type. |
| WCAG 2.2 as the audit target | WCAG 2.2 is the newer criteria set and the target for many procurements. Collabora's conformance to WCAG 2.2 must be confirmed with the vendor. | Scope the audit to the editor interface, the document content and the WOPI host integration, and state which success criteria were tested and with which assistive technologies. |
What the Writer accessibility audit should cover
Start with the editing surface that users touch directly. Test whether every editing function can be reached without a pointer, whether focus order follows the visual layout, and whether a screen reader announces menus, dialogs and document content in the browser. Record the browsers, assistive technologies and operating systems you tested, because a result for one combination does not carry over to another.
- Keyboard-only operation: Open, edit, format, save and close a document using only the keyboard, including toolbar and menu access.
- Focus visibility and order: Confirm that focus indicators are visible on every control and that focus moves in a logical sequence through dialogs.
- Screen reader announcements: Check that the editing region, dialogs and status messages expose usable names and roles in each screen reader you support.
- Zoom and contrast: Test magnification and high-contrast settings for legibility of toolbars, sidebars and document text.
A pass here means the listed tasks worked for the listed combinations on the dates tested. Confirm the exact test matrix your buyer expects before you describe the result as conformance.
Writer documents carry accessibility through their structure: headings, alternative text, table headers, lists, language settings and reading order. Run the built-in accessibility checker on a representative set of documents, then compare its output with a manual review, because automated checks do not judge every failure. Keep the input files, the checker version and the findings as evidence.
- Heading hierarchy: Verify that headings use defined styles in sequence, with no skipped levels.
- Alternative text: Check that informative images and charts carry text descriptions, and that decorative images are marked as decorative.
- Tables: Confirm that header rows are identified and that complex tables remain understandable when read in sequence.
- Language and metadata: Check that the document language and title properties are set.
- Checker coverage: Record which findings the checker reports, which it cannot judge, and which you reviewed by hand.
Before you report a result, check that every finding is fixed, explained or assigned to an owner. Ask the vendor which checks the current release performs, since the coverage list determines how much of the review is manual.
Export is a separate test. A document can pass in the editor and still produce a PDF with missing tags, an incorrect reading order or unlabeled form content. Validate the exported files against the PDF/UA requirements with a PDF validator, then check them with a screen reader. Confirm which export options your deployment exposes, since the settings chosen at export change the tagged result.
- Tagging: Open exported files in a PDF validator and check the tag tree for headings, lists, tables and figures.
- Reading order: Compare the tagged order with the visual order on multi-column pages and table-heavy pages.
- Alternative text in PDF: Confirm that image descriptions from the source document appear in the tag structure.
- Export settings: Record which PDF options were enabled for each test run, because each option can affect tagging.
- Forms and links: Test any form fields and hyperlinks in the output for accessible names and logical focus order.
Before you state a result, confirm with the vendor and your validator vendor which PDF/UA version your tests target. A validator report is evidence of the file's structure, but it does not replace a screen reader test of the exported file.
The editor runs inside a host application, and the audit must cover the surrounding page as well. In a Nextcloud deployment, the file list, sharing dialogs, the open and close flow for documents, and the error messages belong to the host, not the editor. Public bodies that provide web content through contracts or licenses carry the same accessibility obligations for that content, so the host shell belongs in the same record as the editor. The eCFR text of 28 CFR Part 35 Subpart H sets out the US state and local government rule, which applies WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people and from 26 April 2028 for smaller entities and special districts.
- Editor launch and exit: Test opening a document from the file list and returning to the file list using only the keyboard and a screen reader.
- Host navigation: Apply the same criteria to the file list, sharing and permission pages around the editor.
- Error and status messages: Trigger a failed open or an expired session, and confirm the message is announced and understandable.
- Access settings: Nextcloud Office lets administrators limit which groups can use the editor and which can edit, so test those restrictions with users in each group.
- Configuration record: Keep the host version, the Collabora Online version and the server URL settings with the test results.
Ask which party under your contract is responsible for each host component before you sign off the record, since the answer decides who must fix a failure.
What evidence an accessibility audit file should hold
An accessibility audit file is only as useful as its link to a specific build and configuration. Each item below should name the Collabora Online release it covers, so that a reviewer can tell which findings still apply after an upgrade.
Tested version and branch
Record the exact Collabora Online release that was tested, including the point release number, not just the branch. The supported branches in the supplied material are 26.04, announced on July 23, 2026, and 25.04, whose point releases continued into 2026. If your deployment runs 25.04, state that explicitly, because the accessibility checker and export behavior may differ between branches. Confirm the version string from the running server and the Nextcloud or other WOPI host version it was tested with.
Test method and assistive technology list
Document the test approach: which WCAG 2.2 success criteria and EN 301 549 clauses were checked, whether tests were manual or automated, and which assistive technologies and browsers were used. Name the screen reader and version, the keyboard-only walkthrough, and the zoom and high-contrast settings. Record who tested and their role, so a reviewer can judge independence. Mark which criteria were not tested and why.
Accessibility checker reports
Keep the raw output of the Writer accessibility checker for each sample document, saved with the document name, hash and date. Checker results are a starting point, not a verdict, so pair each reported issue with the manual outcome and the fix or accepted risk. Note the document types covered, such as headings-heavy reports, forms and tables, because an empty report for one type says little about another.
PDF/UA validation output
Where users export tagged PDFs, store the validator output for each export configuration you rely on. Record the validator name and version, the export settings, and the source document. A clean validation on one document does not cover structures such as complex tables or form fields, so list those samples separately. Re-run validation after any change to the export path or the Collabora Online version.
Host configuration showing editing rights
Export the WOPI host settings that control who can open and edit documents, such as the group limits for the editor and for editing rather than viewing in Nextcloud Office. Accessibility findings often depend on whether a user can edit the content they are assessing, so this record links the test to real access. Keep a dated copy and note the Collabora server URL and the protocol used.
Dated change record and re-test trigger
Maintain a dated log of every Collabora Online upgrade, configuration change and WOPI host update, with the reviewer who approved it. Define which changes trigger a targeted re-test, such as a branch move, a new export setting or a new assistive technology version. Review the whole file on a fixed schedule set by your procurement or compliance owner, and confirm that schedule against the accessibility requirements that apply to your organization.
Sequence for an accessibility evidence program
This sequence turns a one-off accessibility check into a repeatable record that a buyer's assessor can review, tying every test result to a named Collabora Online release and a fixed document set. It is designed so that each upgrade produces a new, comparable set of results rather than an unexplained change.
Confirm the governing standard edition
Before any testing, ask the buyer which edition of EN 301 549 and which WCAG 2.2 conformance level their procurement or regulatory text names, and whether they also need to address BITV 2.0 or the ADA Title II timelines that apply to their entity. Record the answer in writing, since it determines which success criteria the tests must cover. The step is complete when the buyer has confirmed the standard, edition and level in an email or procurement document that is filed with the evidence.
Pin the tested Collabora Online release
Record the exact Collabora Online version, the packaging method (Docker image, system package or Kubernetes chart), and the host platform version, such as the Nextcloud release that embeds the editor. Accessibility results apply to that combination only, so a later upgrade is a new test target. The step closes when a configuration record names every version and is stored alongside the test plan, so the assessor can see what was actually tested.
Define the document corpus
Assemble a fixed set of representative files that reflects the buyer's real work: text documents with headings, tables, lists, images, and form fields, plus spreadsheets and presentations if they are in scope. Include both native OpenDocument files and the Microsoft formats the organization actually exchanges. Keep the corpus under version control so the same files are used each time. The step is complete when the corpus list, with file checksums and a short note on what each file is designed to exercise, is approved by the buyer.
Run checker and PDF/UA tests
Run the accessibility checker inside Writer, Calc and Impress against each file in the corpus, then export tagged PDF output and validate it with a PDF/UA-aware tool. Capture the checker reports, the validator output and screenshots of any screen reader or keyboard tests the buyer requires, noting that the checker is a helper and does not replace manual review. The step closes when every corpus file has a dated result for each test, with the tester's name attached.
Log gaps against success criteria
Map each finding to the relevant WCAG 2.2 success criterion and EN 301 549 clause, then record its severity, the affected file, whether it is a Collabora Online behavior, a host platform behavior or a document authoring issue, and a proposed owner. Mark items that cannot be verified with the tools available, such as complex assistive technology interactions, as untested rather than passed. The step is complete when the gap log is reviewed with the buyer and every item has a disposition.
Repeat tests after each upgrade
Whenever Collabora Online or the host platform is updated, rerun the same corpus and checks against the new release, then compare the results with the previous baseline. Note regressions and improvements, and confirm whether any previously open gap has closed. Because upgrades follow the vendor's release branches, the buyer should agree in advance who runs this retest and how often it happens. The step closes with a dated comparison record linked to the new pinned version.
Hand the record to the buyer's assessor
Package the standard confirmation, release pin, corpus, test results, gap log and retest history into one evidence set, and state clearly what was tested, by whom and against which edition. DeployOpen prepares this record but does not issue accessibility conformance reports or certifications, so the buyer's independent assessor or procurement reviewer makes the determination. The step is complete when the assessor confirms receipt and records any questions or additional tests they require.
Questions buyers ask before testing Collabora Online accessibility
Is Collabora Online WCAG 2.2 conformant?
No supplied evidence establishes that Collabora Online is WCAG 2.2 conformant, so you should not assume it is. Conformance depends on the specific editor features, document types and workflows you use, and it has to be tested against WCAG 2.2 success criteria and EN 301 549 clauses in your own environment. Ask Collabora for any accessibility documentation it holds for the version you plan to run, then treat that material as a starting point for your own test plan rather than as proof. The Writer application is the main focus here, since public procurement requests usually target document editing, and you should test the accessibility checker, keyboard navigation, screen reader behavior and PDF/UA export as separate items.
What does an accessibility test of Collabora Online cost?
The cost is driven by scope, not by a fixed package. The main drivers are the size of your document corpus, the number of WOPI hosts such as Nextcloud or other platforms that embed the editor, the number of document types in scope, and how much remediation you expect after findings. Testing is typically a one-time cost, while the upgrade retests and the monitoring of new releases recur each time you move to a new branch. DeployOpen does not publish prices. A quote follows from a written scope, so ask each bidder to itemize test planning, test execution with assistive technology, findings reporting, remediation guidance and retesting, and to state which items are fixed and which are estimated. Ask who pays for any fixes made in the Collabora code, since that work sits with the upstream project rather than your deployment.
How long does an accessibility assessment take?
The duration depends on the agreed scope, and DeployOpen confirms it in writing before work starts. A narrow assessment covering a few document templates in one host takes far less time than a full assessment of Writer, Calc and Impress across several hosts with assistive technology testing and retesting. Ask the provider to split the schedule into test preparation, execution, reporting and retest windows, and to state which of your staff must be available for reviews. Your own procurement deadlines, such as the ADA Title II dates for state and local government web content and mobile apps, may set the outer limit, so confirm early whether your scope must be complete before a specific date.
What must we provide before an accessibility test starts?
The test cannot produce useful findings without inputs from your organization. Prepare a representative set of test documents that reflects what users actually create, including templates with headings, tables, images with alternative text, forms and tracked changes. Share the accessibility clauses from your procurement text so the test maps to the requirements you must meet, and identify the target standard and version. Provide access to a staging WOPI host that matches your production configuration, with the same Collabora Online version, TLS settings and user roles. You should also name a contact who can make decisions on findings, and confirm which assistive technologies your users rely on, so testers use the same screen readers and browsers.
Can our own team test Collabora Online accessibility in-house?
Yes, an internal team can run parts of the assessment, and many organizations do. Internal staff are well placed to build the document corpus, check the host configuration and track findings over time. The harder parts are consistent testing with assistive technology, interpretation of WCAG 2.2 and EN 301 549 success criteria, and documenting results in a form your auditors or procurement office will accept. Whichever route you choose, record who tested, which versions and browsers were used, and which criteria were checked and how. Separating the work into internal preparation and external execution is a common compromise, but your choice should follow the skills you have and the evidence your buyer requires.
Who issues the accessibility conformance statement?
The organization that operates the system issues its own accessibility statement, and it must be based on evidence from testing. DeployOpen prepares test results, documentation and remediation records, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those functions where a formal assessment is required. Procurement teams often ask for a Voluntary Product Accessibility Template or a similar conformance report from the vendor, so check whether Collabora supplies one for the version you plan to run, and state clearly which parts of the statement come from your own tests. Treat any statement that claims conformance without a documented test scope as a red flag during review.
How DeployOpen scopes accessibility evidence work
DeployOpen plans and runs the configuration, test preparation and evidence collection for Collabora Online on infrastructure you control, under a fixed scope agreed in writing before work starts. In practice that means the deployment settings that affect accessibility output, the test documents and document sets used for Writer checks, the accessibility checker runs, the PDF/UA export trials and a dated record of what was configured and tested. The scope also states which parts are not covered, such as assistive technology testing with specific screen readers or user testing with people with disabilities, so the evidence set is clear about its limits from the start.
The conformance report itself does not come from DeployOpen. A conformance statement against EN 301 549 and WCAG 2.2 must be produced by an independent assessor, and DeployOpen prepares the material that assessor will need: the version and branch under test, the browser and assistive technology combinations, the document corpus, and the known gaps list. Ask any partner, including us, to confirm in writing which of these artifacts are delivered and which remain the assessor's responsibility, so procurement does not read preparation work as an audit result.
Accessibility evidence goes stale when the editor changes. Collabora Online ships new branches and point releases, so a conformance statement tied to one version needs a retest plan. DeployOpen offers retainers that cover retesting after upgrades if you want continuous evidence rather than a single snapshot. Confirm with us whether the retainer includes re-running the document corpus, how changes are logged, and who decides whether a regression blocks a rollout.
