Description: It would be ideal to add a new sidebar focused on accessibility. This enhancement request is probably most relevant for Writer, but would also be useful for Impress and Calc (as they are commonly used to create reports and presentations shared in a variety of formats, like PDF and HTML). The sidebar could include: - The contents of the Accessibility Check, with buttons to jump to the location of the issue, and buttons to fix the issue (if there is a straight forward was to do so) - The "Alternative (Text only)" field to fill in the the alt text of images (when an image is selected) - A button to directly export as HTML or PDF/UA (and other recommended formats for optimal accessibility) - more ideas? This would allow users to more easily fix accessibility issues, and review a whole document without having to switch between dialogues. Steps to Reproduce: Try: - giving alternative text to numerous images - checking accessibility with Tools > Accessibility check - Exporting / saving to a format without necessarily knowing which option is recommended Actual Results: You have to navigate to a few different menus and dialogues. Expected Results: One centralised location for accessibility-related features would allow the user to focus on getting the document ready, without missing features they wouldn't have found otherwise. Reproducible: Always User Profile Reset: No Additional Info: Not available in 7.0.6.2, 7.1.4, 7.2 beta1 and: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: e3086b58eb5427d520b86c185f9d911bb6f7a3a0 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-21_15:37:11 Calc: threaded But assumed that it was never available.
Not a bad idea for a SB deck--but probably better packaged as a bundled extension. Optional during installation like the 'Solver for Nonlinear Programming', 'MediaWiki Publisher' and BeanShell and JavaScript script providers.
Extension was my first idea too.
@Tomaž, some UI work to round out your PDF/UA and PDF accessibility checker gems?
I think there is clearly room too, for people stepping in extending the current accessibility check. Having said that: we do have the dialog, so why not present the same in the sidebar indeed, and put that in an extension?
We discussed this topic in the design meeting and agreed that it would be a welcome extension. Resolved/moved to extension.
Where are extension tracked? Could we have a link to the relevant place this was moved to?
(In reply to stragu from comment #6) > Where are extension tracked? Could we have a link to the relevant place this > was moved to? As third-party content we do not track extensions yet. Would be nice- and maybe a question to QA whether or not we want a category in addition to the existing "Extensions" component that is meant for dealing with extensions via code.
We can't just "make it an extension" .. there is zero functionality exposed as UNO and I don't think there would be much sense to make wrappers so that somebody, sometime, somewhere will implement a sidebar - that's not how this works. If we have a clear use case why users would need access to accessibility checker structures then we can add it to UNO and cement the API, but until then - just to make an sidebar is not worth the trouble and long-term implications.
Also... making it into the sidebar changes the expectation from "check and show the result in dialog", to "check when the document changes", which is not how the accessibility check works as it always checks the whole document model only.
Given quikee's perspective, and current state of things, this becomes a clear => WF. But, I still beleive an assistive technology tool feature like this would be helpful--and that it *needs* to be driven by TDF "Tender", not wait for 3rd party dev interest. And if implemented (by dialog(s), or the UNO and the SB GUI work) it must be maintained and distributed with LO core! Whether it gets packaged as an extension, or not, and just extends dialog(s) is secondary to LibreOffice producing accessible ODF documents, or fully supporting export to accessible formats (e.g. PDF/UA, or WCAG 2.1 compliant XHTML). Those aspects remains valid.
(In reply to Tomaz Vajngerl from comment #9) > Also... making it into the sidebar changes the expectation from "check and > show the result in dialog", to "check when the document changes", which is > not how the accessibility check works as it always checks the whole document > model only. Ah, good point that I didn't think of. Thx
Thanks everyone. Agree with Stuart that an accessibility-focused tender would be wonderful - and potentially an overdue strategic move as more and more legislation enforces accessibility requirements in software choices made by businesses and public institutions.