Download it now!
Bug 45636 - Add support for PDF/UA (PDF/Universal Accessibility) - ISO 14289
Summary: Add support for PDF/UA (PDF/Universal Accessibility) - ISO 14289
Status: NEW
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: 2020-01-09 16:06 UTC (History)
10 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
(In reply to Nicolas Göddel from comment #4)
> Would be nice to see this feature implemented.
Indeed.

> The PDF Accessibility Checker 2.0 still reports some errors and because of
> ...
Thanks for this info.

> Or is the only possibility to hire
> some certified developers or fix it by myself?
Yes. I would expect some people are already looking at possibilities, but..
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.