Drafting Tender "Improve the accessibility checker for PDF/UA"

Board Discuss
#1

Hello,

one of the approved [1] tenders is the

       Improve the accessibility checker for PDF/UA

The board would like to work together in public with all of you on this tender before it gets officially published. The current draft is therefore shared at

https://nextcloud.documentfoundation.org/s/WE6tsYjAZietK9q

The board is happy to get your feedback and proposals. We'd like to discuss this ideally in the board call on Monday, May 16, at 1800 Berlin time. Please send your feedback to the public board-discuss@documentfoundation.org mailing list. Thanks a lot to all community members involved for working on the tender draft!

Looking forward to your feedback,

Olivier

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00400.html

#2

I wonder why the other tickets from META bug 139007 are excluded (btw, there is kind of duplicate META bug 101912 with a lot more). Bug 149000 is on hold since you asked UX for input (personally I think Print is over-engineering in respect to the workflow). Bug 148971 about the non-modal window could also be handled per sidebar deck, which I prefer over the modality tweak. An alternative is to insert the issues as annotations/comments in the document. On one ticket we discussed the help on each issue, could be an infobutton (question mark icon) that shows a dialog why this tag is needed and what to do. Three weeks seems underestimated if we expect to solve all issues.

Looking at the current UI, I think a bit design work could be beneficial. Some issues are rather warnings (eg. Avoid Footnotes) other are mandatory (No Alt Text). Perhaps we copy the SEO plugin look and feel - or was it the readability checker? - from Wordpress.

As reviewers we could invite Christophe Strobbe who comments a lot on these tickets and there was a lady in the German community call last year... don't remember her name.

PS: Cannot comment on the NC document.

#3

Hallo Heiko,

there was a lady in the German community call last year it was me = Susanne Mohn.
I reportet the bugs 139007, 140617 and 141386.
We need it accessebility free documents for he inplementation of libreoffice in Schleswig-Holstein.
The implementation in LO 7.3 is not complete.

I would be very happy to participate as a reviewer.
An e-mail chain for this is also in the German group- should we continue there?

Sorry about my bad english.

Susanne

#4

there was a lady in the German community call last year it was me = Susanne Mohn.

Yes, Susanne! Awesome that you have picked up this thread.

I would be very happy to participate as a reviewer.
An e-mail chain for this is also in the German group- should we continue there?

The tender circulates first among a committee of experts. Since the board of directors is apparently happy to be involved in this step, the proposal is being discussed on this mailing list.

Cheers,
Heiko

#5

Hi,

On 11. 05. 22 00:36, Olivier Hallot wrote:

Hello,

one of the approved [1] tenders is the

Improve the accessibility checker for PDF/UA

The board would like to work together in public with all of you on this tender before it gets officially published. The current draft is therefore shared at

https://nextcloud.documentfoundation.org/s/WE6tsYjAZietK9q

The board is happy to get your feedback and proposals. We’d like to discuss this ideally in the board call on Monday, May 16, at 1800 Berlin time. Please send your feedback to the public board-discuss@documentfoundation.org mailing list. Thanks a lot to all community members involved for working on the tender draft!

I looked through the draft and it is OK, but I have some comments:

It says “The goal of this task would be to improve that up to the state that it could be enabled in non-experimental mode.” The checker is not in “experimental” since I think 7.1, so that goal is “done”. I would reword that bit… the checker definitely needs to be further improved.

One more objective should also be to implement the accessibility checker also for Impress, Calc and Draw as it needs the ground work for running the checks implemented for those components. If we miss some useful accessibility check then they can easily be added (could be an “interesting” easy hack), but if the ground work is missing, then this is a bigger hurdle that needs an experienced developer to do the work. Also many of the checks are already implemented, if they are using common objects, but without the ground work done, they can’t be run.

Looking forward to your feedback,

Olivier

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00400.html

Best regards,

Tomaž Vajngerl

#6

Hi all

I have updated the tender document with the valuable inputs received.

My gratitude to C. Strobbe, S. Mohn and T. Vajngerl for their comments.

The tender document file is now
https://nextcloud.documentfoundation.org/s/Gxw82TWcCWiXRBq

for more comments and advise.

Regards
Olivier

#7

Hi,

I have updated the tender document with the valuable inputs received.

My gratitude to C. Strobbe, S. Mohn and T. Vajngerl for their comments.

The tender document file is now
https://nextcloud.documentfoundation.org/s/Gxw82TWcCWiXRBq

for more comments and advise.

Sorry for being a bit late.

I like the proposal.
The introduction is very informative and provides the necessary background knowledge.
It also gives a differentiation between 2 parts:

1) "First is to enable PDF/UA support into PDF export, which writes a PDF/UA flag into the PDF document and enables all the required features."

2) "an accessibility check functionality, which traverses the document structure and gathers all possible accessibility issues"

However, I'm a bit confused about the exact scope:
Not being a native English speaker, I would have understood the later section "Scope out of this Tender" as "Out of scope for this tender", i.e. "not to be done as part of this tender".
Is that correct?

If so, my understanding would have been that the tender mostly covers aspect 2) from above, but not actual PDF export, since the "Scope out of this Tender" section contains this:
"Development and bug fixes to the PDF export module (pdfium or equivalent), related to the PDF/UA-1 standard."

But then, it seems to me that issue tdf#148934 listed in the "LibreOffice Upstream fixes" section would presumably require improving PDF export as well.
The same might be true for the requirement that exported documents should pass veraPDF validation (mentioned in section "Acceptance criteria"), unless the set of features used in the sample documents (the ones listed in section "PDF/UA checks"?) is guaranteed to already be covered by the current PDF export implementation just fine.

Can that possibly be clarified? (Maybe I just misunderstand something.)

Depending on the exact scope of this tender, we could also consider making PDF export issues part of the "Fix accessibility issues" tender scheduled for this year:
https://wiki.documentfoundation.org/Development/Budget2022#Fix_accessibility_issues

Which brings me to Heiko's earlier message in this thread:

I wonder why the other tickets from META bug 139007 are excluded (btw, there is
kind of duplicate META bug 101912 with a lot more).
[...]
Three weeks seems underestimated if we expect to solve all issues.

The general a11y meta bug 101912 depends on the PDF a11y meta one, bug 139007. Therefore, dependencies of bug 139007 are listed in the tree view for bug 101912 as well:
https://bugs.documentfoundation.org/showdependencytree.cgi?id=101912&hide_resolved=1

Given that, I think it makes sense to add PDF a11y bugs as explicit dependencies for bug 139007 only. (They'll be shown as transitive dependencies for bug 101912 anyway then.)

Best regards,
Michael

#8

Hi Olivier,

I have updated the tender document with the valuable inputs received.

My gratitude to C. Strobbe, S. Mohn and T. Vajngerl for their comments.

The tender document file is now
https://nextcloud.documentfoundation.org/s/Gxw82TWcCWiXRBq

for more comments and advise.

Thanks for driving this so far and sorry for being late.
In general accessibility check can result in errors, warnings, tips and/or more info. It would be great if this can be included somehow in already mentioned UI improvements.

In the description of the tender, I would appreciate some more nuance.
While it is true that there is clear room for improving the current checker, it is not unreliable for (most) implemented checks and also after the work foreseen, there will be topics for which the check does not give a full reliable outcome. There's so many nuances in a11y.
So "improve to a state where it is useful for preferably all of the situations/documents to check' or something in that direction, would be my suggestion.

Cheers,
Cor

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.