Bug 45636 - Add support for PDF/UA (PDF/Universal Accessibility) - ISO 14289
Summary: Add support for PDF/UA (PDF/Universal Accessibility) - ISO 14289
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
3.4.5 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA target:6.5.0
Keywords: accessibility
Depends on:
Blocks: a11y PDF-Export
  Show dependency treegraph
 
Reported: 2012-02-04 23:38 UTC by Jaap van de Putte
Modified: 2021-01-28 06:05 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaap van de Putte 2012-02-04 23:38:18 UTC
I do not have a bug, but I have a future request. In our discussion group accessibility I was advised to use this bug-report. If it is the wrong place I'm sorry.

I'm from the Netherlands. For websites the government in the Netherlands follows the accessibility guidelines from the W3C, the Web Content Accessibiliy Guidelines (WCAG). There are 3 levels of compliance and we will follow level AA. Also have we extended these guidelines with a number of extra rules. Together they form the Web Guidelines (Webrichtlijnen in Dutch).

According to these Web Guidelines, government sites are obliged to offer their documents in an open and accessible format. For now the possibilities of LibreOffice in exporting a file are sufficient: you have to export it to PDF/A-1a. In the near futere it will be necessary to use a new subversion of PDF, PDF/UA (Universal Accessibility). PDF/UA is more accessible than PDF/A-1a. More about this format you can read on ow.ly/8RxcQ.

I am curious if new versions of LibreOffice will make it possible to export files to PDF/UA. If LibreOffice is going to support this format, it will make a huge difference when LibreOffice is compared to other office suites.  And it wil be must easier to promote LibreOffice to be used by government organizations. 

I'm seeing forward for your answer

Kind regards, Jaap van de Putte
Comment 1 Christophe Strobbe 2012-02-08 06:33:40 UTC
At the time of writing ISO 14289 has not yet been published as an ISO standard; this is expected to happen in 2012. 

"PDF/Universal Accessibility" could be a checkbox on the "General" tab of the PDF Options, probably between "PDF/A-1a" and "tagged PDF". 

(I turned this bug into an enhancement request.)
Comment 2 sasha.libreoffice 2012-05-15 03:22:01 UTC
Thanks for new idea. In 3.5.3 I can not find option PDF/UA.
Suppose that not implemented yet and change status to NEW.
Comment 3 Christophe Strobbe 2013-08-06 19:19:23 UTC
As a follow-up to my previous comment: the standard defining PDF/UA (Universal Accessibility) was published last year as ISO 14289-1:2012. Perhaps more useful is the technical implementation guide at http://www.aiim.org/Research-and-Publications/standards/committees/PDFUA/Technical-Implementation-Guide. 

The closest counterpart of this bug in the Apache OpenOffice bugtracker is https://issues.apache.org/ooo/show_bug.cgi?id=31324.
Comment 4 Nicolas Göddel 2019-05-15 11:44:36 UTC
Would be nice to see this feature implemented.

The PDF Accessibility Checker 2.0 still reports some errors and because of that the created PDF is only partially accessible. You can find the tool here: https://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac.html

When creating a simple document with one title, two headlines and some metadata there are only a few errors:

- Structure type 'Document' is mapped in a circular fashion
- Structure type 'H1' is mapped in a circular fashion
- Structure type 'H2' is mapped in a circular fashion
- XMP metadata stream missing in document
- PDF/UA identifier missing
- «dc:title» entry missing in document's XMP metadata

I guess there will be popping up more errors if the document has more content and perhaps also images and so on.

Also this bug is very old now but still marked as NEW. Is it possible to push it somehow so it gets fixed faster? Or is the only possibility to hire some certified developers or fix it by myself?
Comment 5 Alex ARNAUD 2019-05-15 12:53:12 UTC
(In reply to Nicolas Göddel from comment #4)
> Also this bug is very old now but still marked as NEW. Is it possible to
> push it somehow so it gets fixed faster? Or is the only possibility to hire
> some certified developers or fix it by myself?

As I understand, the most probable way to get this issue fixed is to hire developer or fix it yourself.

Best regards,
Alex.
Comment 6 Cor Nouws 2019-05-16 11:21:41 UTC Comment hidden (obsolete)
Comment 7 johann.klocker 2019-05-18 09:06:50 UTC
I am looking for a good tool to produce accessible PDFs too. And I found another bug regarding the accessibility of the PDFs exported by swriter. If the document contains form fields, these document parts are listed in the tag-list of the PDF at a wrong place. They are listed after all normal text of a page.

Example:
The document:
paragraph1
formfield1
paragraph2
formfield2
paragraph3

results in this tag-list in the exported PDF:
<P>
    paragraph1
<P>
<P>
    paragraph2
<P>
<P>
    paragraph3
<P>
<Form>
<Form>

I tried some other objects, which can be part of or anchored in a paragraph like textboxes. They are listed in the tag-list at the end of a page too. In contrast, images seem to be listed in the right order.
Comment 8 Xisco Faulí 2019-11-29 13:29:39 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 9 Samuel Thibault 2019-11-29 13:34:11 UTC
Counting the number of duplicates is not a good metric here: the number of people who need the feature (the disabled people) is by construction quite small, so it's not surprising to see few duplicates. But compared to the number of people who have to use the feature, it is quite high.
Comment 10 Christophe Strobbe 2019-11-29 18:02:31 UTC
@Xisco Faulí I don't understand the reasoning behind the change in priority.

First, I don't understand what "duplicates" refers to. (Duplicates of what?)

Second, I don't understand the lack of awareness about the increasing importance of digital accessibility. The EU Accessibility Directive, which applies to public sector bodies, has been in force since September 2018. The European Accessibility Ac, which was approved this year, will also apply to industry. As a consequence, tools that don't produce accessible PDF will lose users in both public sector bodies and in industry. That is not the direction we want to move in with LibreOffice. In fact, the priority of all LibreOffice accessibility bugs should be increased, not decreased, due to the above changes in EU legislation.
Comment 11 Miklos Vajna 2019-12-02 08:20:52 UTC
Tomaz (Collabora) recently started some work in this area. I would like to mention that government legislation does not magically create money to write open source code (sadly).  We really welcome people who contribute to fixing / improving things, are happy to mentor those who want to get involved; but our resources are limited & there are plenty of important things to improve.
Comment 12 Commit Notification 2020-01-09 16:06:18 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/08886d9d01eb5d3356290ba6d8eeca899cde45cc

tdf#45636 trigger accessibility check when exporting as PDF/UA

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2020-01-09 16:06:32 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/912cd707b5128c5ef9d365d8179cf2b65aeaaa1d

tdf#45636: test for no-alt and table split/merge access. check

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 stragu 2020-06-04 05:40:44 UTC
This is Tomaz's blog post about the new features in LibreOffice 7.0 (6.5 became 7.0). We now have an accessibility check tool as well as PDF/UA export.

https://tomazvajngerl.blogspot.com/2020/01/accessibility-checker-and-support-for.html

I think this can now be closed, and more precise issues can be described in new bug reports, like for specific potentially missing accessibility tests?
Comment 15 Thomas Lendo 2020-10-13 19:50:31 UTC
Closing this bug report according to the linked blog post in comment 14, the commits linked in comment 12 and 13 and the long time without an answer. Follow-up bugs should be addressed in another bugs.
Comment 16 Dustin Matzel 2020-12-11 11:42:21 UTC
Hello,
I am wondering that this bug is closed because I cannot see this feature on any platform, with the current 7.0.3.1 version of LibreOffice. Should this feature not be included in version?
At the moment I do not have the "Accessibility check..." option in the "Tools" menu in Linux and Windows, in macOS I have the button but cannot click it. The "Universal Accessability [PDF/UA]" option in the PDF export dialog cannot be found on Windows, macOS and Linux.
Am I missing something or why can I not see these options?
Comment 17 Samuel Thibault 2020-12-11 11:46:30 UTC
As additional information: on LO 7.0.3.1 from Debian bullseye, I do have the accessibility check option in the tools menu, which for instance on a blank document tells me that it is missing a title. The PDF export dialog also has a "Universal Accessability [PDF/UA]" checkbox.

So perhaps your LO build is somehow missing some options to get this enabled?
Comment 18 Timur 2020-12-11 17:07:53 UTC
If I read correctly, blog says this is done for Writer only. 
If so, there should be a bug for Calc and Impress, I guess.
Comment 19 Christophe Strobbe 2020-12-11 18:30:43 UTC
@Dustin Matzel 

This does not seem not be the right bug to report on the accessibility checking function (currently an experimental features in Writer 7).
Exporting as PDF/UA is possible, for example in LibreOffice 7.0.3.1, without enabling experimental features. Not just in Writer but also in Impress, Calc, Math and Draw . (It may be of limited use in Draw, but that's a different discussion.) In each of these applications, you go to File, then Export As, Export as PDF, and then check the checkbox "Universal Accessibility (PDF/UA)" on the "General" tab.
Comment 20 Dustin Matzel 2020-12-16 08:48:27 UTC
I missed that this is an experimental feature. As soon as I enabled the experimental features option, the accessbility checker and the PDF/UA export option where visible (and clickable).
I will make seperate bugs for the issues I found.
Thanks for clarifying.
Comment 21 BogdanB 2021-01-28 06:05:24 UTC
Verified in
Version: 7.0.4.2
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

But before I enabled Experimental feature.


Verified also in
Version: 7.1.0.1.0+
Build ID: e98c4be2c87ba5b3f4aedc31388014b320588d4b
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

But here we don't need Experimental feature to be activated. It's in the default format of LibreOffice.