Date: prev next · Thread: first prev next last

On Mon, 2022-05-30 at 23:57 +0000, Michael Weghorn wrote:
On 30/05/2022 11.08, Caolán McNamara wrote:
For a11y I don't know what is seen as the major problems, is there
some fundamentally missing pieces (like in the past not having
direct windows IAccessible2 support and needing a java access
bridge). Or are the fundamentals ok and its a matter of a general
malaise. Is the general widgetry ok, but particular components have
poor document level a11y. Or is there an endless amount of fairly
easy entry level problems that there isn't enough people to take
care of.

I don't have a comprehensive overview at this point.
At least from the little experience I have by now, I *tend to think* 
it's mostly the latter, at least as far as root causes for the major 
problems are concerned.

If the overview is there are a thousand little things and not a small
set of large scale specific projects then that's still a useful
overview. We could still sweep them into some general themes.

(I have also *heard* that Base seems to be most problematic in
general, but haven't had much to do with it myself yet.)

I wonder if it's the initial base screen (I think I might have replaced
some custom widgets there with more standard ones which might have
improved matters) or the "design view" rows/columns screen which is a
custom widget, but one I think that does at least have an a11y
implementation. In general custom widgets lead to forgotten a11y, like
the extensions dialog.

How about math? I see a bug 140659 for math still open linked to the
meta bug, which says "formula editor not operable with screenreaders",
but then the commentary seems maybe less bleak

 From what I have seen so far while looking at some a11y issues 
affecting Windows and Linux (gtk3 and qt5/qt6 VCL plugins), the 
fundamentals look fine, and it seems to be mostly that various
smaller issues in LO a11y code of the single components and the
platform integrations (and sometimes in other projects, like the NVDA
screen reader or the Qt library) cause a lack of a11y in the UI (lack
of usability with accessibility technology, like screen readers, e.g.
because not everything is announced) 

Depends of what is being read out of course, missing labels for .ui
widgetry are super trivial to fix[1]. Something not read out from a
document can range from some small missing piece to some difficult
total lack of a11y.

documents (like a11y-related attributes not being properly set in
docs, in particular when exported to other formats like OOXML, PDF,

My feeling is that category of problem is presumably relatively easy to
implement, there's a reasonable amount of general file format knowledge

The a11y meta bug tdf#101912 [1] currently lists ~200 specific
issues. (I also have a ranked list from Richard, CCed, a blind user
who uses the NVDA screen reader on Windows.)

If Richard is ok with sharing that here it could help get a general
feel on what's lacking.

IIUC, the gtk4 VCL plugin currently doesn't have an a11y
implementation yet...

Yeah, right now I don't think there is a way to do it in gtk4. Basic
widgetry works fine and the internal gtk4 a11y looks good, but I don't
see what is possible to supplement it for document a11y. Its the kind
of thing I would probably be able to take care of when it becomes

[1] is the
easy hack for those. Genuinely easy with valuable results. Not sure if
its completed by now.

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.