Re: ESC meeting minutes: 2022-05-26

[Caolán McNamara <caolanm@xxxxxxxxxx>]

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,
> (X)HTML).

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

> 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
possible.


[1] https://bugs.documentfoundation.org/show_bug.cgi?id=119931 is the
easy hack for those. Genuinely easy with valuable results. Not sure if
its completed by now.