https://bugs.documentfoundation.org/show_bug.cgi?id=35652
--- Comment #31 from Michael Weghorn <[email protected]> --- (In reply to cwendling from comment #30) > I understand not wanting to add too much platform-specific code, but we'll > at least have to have an internal a11y API for this, won't we? Then indeed, > the per-VCL implementations would need to be written for this to have an > actual effect. Yes, that's correct. > And thus, while I get that you'd rather not see lower level things creep in > even more, having the necessary bits in the VCL implementations seem not so > far fetched to me, e.g. AFAIK the GTK VCL is currently UNIX-specific and not > meant to be used (or even work?) on Windows, is it? Yes, gtk3 and gtk4 vcl plugins are only used on Unix. Technically, GTK 4 could be usable on Windows or macOS and the idea in GTK 4 was to have an abstraction over the platform-specific a11y API (AT-SPI2 for Linux) by dropping ATK. And by now, GTK 4 has an a11y implementation for macOS and Windows as well. So unless there's a really good reason not to, I'd like to stick to the idea of going with the GtkAccessible API instead of falling back to implementing platform-specific logic manually (that might e.g. also break *if* later versions of GTK end up not supporting AT-SPI2 directly any more). > My point is that if it can be a reasonably abstracted part of the code so > that the internal API the core use is not tied to a platform, it would still > make sense to get the benefits from it where it can actually work and make a > difference. And so that this platform-specific code is worth it, especially > if we can hope to replace it with a toolkit API at some point. As written before: If there's no other way to do it, using a platform-specific implementation could be a last resort, but I'd prefer evaluating using (and extending where needed) toolkit API first. > Regarding Qt, I don't know a lot of it's a11y internals, so I have to ask: > do they usually copy the IA2/UIA/AT-SPI/NSAccessibility APIs, or do they > design their own to match them all? If they welcome additions and have more > or less custom APIs, I would think we could come up with something that > could (bene)fit both Qt and LO. It might however take some time I imagine. Qt a11y was originally inspired by IAccessible 2, but newer APIs no longer necessarily are. My experience is that if something makes sense and conceptually exists in multiple platform a11y APIs, that's a strong argument (and there's a good chance) for adding corresponding Qt API that can be mapped/bridged to that. > While I do agree, I would think Michael M. would argue that consistency > isn't needed if it isn't required for the feature to work :) > > This said, I still believe in the create-on-request model (or just > create-everything-at-once one), be it with or without the Collection > optimization, because it allows for that optimization to be just that -- an > optimization -- and not a requirement for all platforms in order to provide > good a11y support. I guess that can still be discussed in more detail once there is an implementation. In general, my experience/feeling is that inconsistencies tend to bring problems with them sooner or later as something relying on consistency will break somehow at some point. (And saying "Yes, but we just don't implement it correctly/consistently" isn't necessarily a good answer to that in my opinion.) But maybe it can be "good enough for now" without it in a first step at least... -- You are receiving this mail because: You are the assignee for the bug.
