[Libreoffice-ux-advise] [Bug 149000] PDF Accessibility: Checker dialog should have a "Print report" button

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=149000

--- Comment #3 from Christophe Strobbe <c_strobbe-fdo at yahoo.co.uk> ---
The critical thing here is figuring out how to make such a report useful. (The
same applies to the current UI.)
To users who are not accessibility experts, a text version of what the checker
displays in its UI is of limited usefulness. (This comment applies to each of
the issues in the screenshot uploaded by Heiko Tietze.) In order to be really
helpful, we need:

1. Accurate and up-to-date information on how to fix accessibility issues in
Libreoffice's online help. "How to Create Accessible LibreOffice files" at
https://wiki.documentfoundation.org/Accessibility/Creating_Accessible_LibreOffice_Files
is still based on LibreOffice 5.2 and needs to be checked for completeness,
especially for people who want to create documents that meet the accessibility
criteria in the European standard EN 301 549.
2. A mechanism to refer users from a specific issue to the appropriate section
in the above documentation
2.a. both in the UI
2.b. and in the exported accessibility report.
3. A concept for organizing the accessibility issues in the report: should the
issues be listed in the order they occur in the source document, by type of
content (images, tables, headings, ...) or by a specific set of accessibility
criteria from a standards such as EN 301 549? (Or all of them in specific
sections of the report? Or provide a setting that allows the user what type of
structure to use?)
4. Above all, the checker should not be limited to a function that is invoked
by the PDF export function but one that is available at any moment, so authors
can check the accessibility of a document while writing it. (AccessODF, an
extension for OpenOffice.org and LibreOffice 3.3, worked in this way. The
extension still exists - see http://accessodf.sourceforge.net/ - but became
incompatible with OOo and LibO when the side panel was introduced.)

I realise that some if the above issues need to be relegated to separate
issues.

P.S.: Rich text (Microsoft's RTF format) would be a bad choice from an
accessibility point of view due to its limited accessibility features. An
accessible ODT file would be a much better choice. (AccessODF did not export a
report but saved checking results in EARL Schema:
https://www.w3.org/TR/EARL10-Schema/ )
P.P.S.: The usefulness of a report is limited by the fact that automated
accessibility checks can catch less than a third of all types of accessibility
issues. Authors may erroneously think they have solved all accessibility issues
when they have addressed those that have been reported by the tool. An exported
report would not to point out that this is not the case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.