Created attachment 192786 [details] Example file from Writer with many character DF in a paragraph If there is some character direct formatting applied to the text of a document, there is one entry in the sidebar for all of the instances. In a larger document this can become annoying to oversee (let alone fix), and possibly can cause fatigue of the user. One idea to make this better would be to group these issues by paragraph (or even by document?): one entry in the sidebar, and highlight all of the affected characters, or even the whole paragraph if this is not possible. Another idea is to provide a Fix button to this warning, which would call uno:ResetAttributes (Clear Direct Formatting) on the text belonging to the warning. 1. Open attached document 2. Open the Accessibility sidebar -> Several entries about direct character formatting. Imagine this density of DF in a 100 page long document... Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 74185b8edf7f046a3372319da86a1d8ca0024c87 CPU threads: 15; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: default Started in 7.1 with the first implementation of accessibility check.
Created attachment 192787 [details] Screenshot of the issue in Writer
Agreed, this is too overwhelming and should be handled more gracefully. + 0.5 for grouping by paragraph, +1 for offering an action button. Maybe UX/Design team can chime in? This issue applies to many accessibility warnings, and there could be a solution that applies to most cases. For example: - only show the first X repeated warnings (with their individual Fix It buttons if they exists); - followed by a right-aligned string like "...and X more similar issues." with a "Fix All" button next to it. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f42363c51672a5b3685b0b9b11e932680530dce3 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
+1 for a "Clear" (DF) interaction at the issue. But if this is going to be implemented we cannot merge all DF from one paragraph into the same issue. I would keep every single issue separate. I wonder if "text formatting conveys additional meaning" is the actual problem with DF. Ultimately it's the same whether you apply italic or Emphasis to a word. DF may be used inconsistently however. Other issues: Double-click on a hyperlink is very much unexpected. Text selection is not possible.
Given that the 'accessibility check' feature resident in the SB is to *assist* the author with preparing accessible text, organizing it to do so efficiently makes sense. It is really not performing validation--rather it just indicates some text span that may need consideration. Currently each instance of "Text formatting conveys additional meaning" flag is picked up for *each* DF the author has assigned. Grouping by Paragraph would certainly help the author proceed through the document. But if the author does not want to consider each instance, they can already collapse the 'Formatting' exposure arrow. And doing so "by paragraph" or "by section" would be reasonable improvement and, suited to task of checking document accessibility. However would note that currently assigning a defined 'Character style' (e.g. Emphasis, Strong Emphasis) unlike the DF does not trigger the same additional meaning flag. Why not? -1 for an action button, stripping out the DF in bulk doesn't encourage the author to review the DF impact on accessible content. Beyond that, it is up to the users chosen Assistive Technology tool to consume and respond to document formatting--fonts, attributes, super/subscript, emphasis, highlight/marking, styling and color. Such DF and styling within a document are not incorrect, rather the author should be made aware where they have applied them--and the potential impact their formatting choices can have. Viewed in that context, +1 to organize by Paragraph, -1 to strip out ALL DF in a single pass, but fine to review/process at paragraph or section. And need to consider handling of applied Character styling in an accessible text context.
(In reply to V Stuart Foote from comment #4) > -1 for an action button, stripping out the DF in bulk doesn't encourage the > author to review the DF impact on accessible content. Maybe there's a good opportunity here to link to our new 7.6 "Format > Spotlight > Character Direct Formatting" feature (bug 106556), so the user can review?
We discussed the topic in the design meeting. While adding a button has some charm it depends a lot on the scenario and could also be just "Dismiss" in case of DF. A more complex UI with interactions, filters, batch operations, thinking of how track changes are handled, might be desirable. But simple solutions first. As for the visualization we agreed on a further level in the tree so all DF per paragraph can be shown but collapsed under a node. This idea might be enhanced with another tree level for the pages