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
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: accessibility
Depends on:
Blocks: a11y PDF-Export
  Show dependency treegraph
 
Reported: 2012-02-04 23:38 UTC by Jaap van de Putte
Modified: 2019-05-18 09:06 UTC (History)
8 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.