The set of issues reported by the PDF Accessibility checker should be printable or exported to a printable document. The number of issues can be very long (hundreds of items) and can be overwhelming. Also, for logging matters, users may be interested to have a printable document to identify the remaining violations of the PDF/UA-1 after a a11y check round. Outputs can be ODF (ODT) or HTML. An example is the output of veraPDF (*) checker. A "Print report" or "Export report" button in the Accessibility checker would be nice. (*)https://verapdf.org
Created attachment 180033 [details] Example done with Dummy Text Formatted How about Copy rather than Print? And I wonder if users really want a copy whether printed or not of the issues. Re-running is cheap and you get the "Go to Issue" interaction.
(In reply to Heiko Tietze from comment #1) > Created attachment 180033 [details] > Example done with Dummy Text Formatted > > How about Copy rather than Print? And I wonder if users really want a copy > whether printed or not of the issues. Report may be rich text. And could help for review in a later stage (just thinking ..). > Re-running is cheap and you get the "Go to Issue" interaction. True.
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.
(In reply to Christophe Strobbe from comment #3) > The critical thing here is figuring out how to make such a report useful. A lot of very good ideas, in particular the help on each topic. As always, every single item needs a ticket. But what about a print-out?
The topic was on the agenda of the design meeting. The intended workflow is unclear. Why should you want to print issues rather than fixing it? With external tools this might be different but running the check again is cheap and simple. One alternative is to have the issues in a dedicated sidebar tab along with interactions to fix and tips why this is needed (MSO did a great job here). And we could also insert annotations like comments into the document that could be resolved when done. Since the list of issues might be long we would also need a function to remove these annotation, in case the user decides to not make the document fully accessible. So the decision is WF/NAB unless the request is not to print the findings but, for example, to export the inaccessible parts of the documents together with the issue - and to fix it externally. But in this case it needs to be merged back, which is a tricky task. => NEEDINFO
(In reply to Heiko Tietze from comment #5) > So the decision is WF/NAB unless the request is not to print the findings
The use of printing (to paper or PDF) is limited when the report is not clear. So the use of such a feature, depends on improving the report as such. ... separate issue But then, when improving the report, adding a 'goto' button is useful. ... separate issue Still, a pdf-report of the issues, can help with evaluation of the work (learning experience..) @olivier: do you have additional ideas?