On 2024-06-15 20:31, Michael Weghorn wrote:
On 2024-06-15 14:55, Jason J.G. White wrote:
My limited understanding of the new protocol proposed for Linux by the
GNOME Foundation is that it is expected to use pipes for data
transfer, giving better performance than DBus calls. So my naive
Hi Michael,
On 2024-06-13 14:49, Michael Meeks wrote:
AT-SPI's flows-from and flows-to relations (and ARIA's aria-flowto)
seem somewhat similar to the UIA Navigation API you mention.
=) Ultimately we dynamically create peers as these methods are
called currently I imagine.
Yes, but
Hi Michael,
On 12/06/2024 15:55, Michael Weghorn wrote:
No need to apologize - thanks a lot for your valuable input! :-)
Ah - if you encourage me you get more ;-)
There, the Table interface also only exposes the same amount of cells as
are exposed via the a11y tree.
Fair
On 2024-06-12 16:55, Michael Weghorn wrote:
to look into at some point. My idea so far is to also expose pages on
the a11y level, which should avoid the problem of a single object
(the document) having an enormous amount of children due to that.
If there any general concerns about that, please
Hi,
On Wed, Jun 12, 2024 at 02:55:50PM +, Michael Weghorn
wrote:
> Is there an easy way to test COOL a11y web and impacts of potential changes?
>
> (I just opened a sample Writer doc on nextcloud.documentfoundation.org and
> couldn't find the doc content via Accerciser in a quick test, but
Hi Michael,
On 2024-06-11 11:40, Michael Meeks wrote:
Some great questions and points here; forgive my intruding into the
space again =)
No need to apologize - thanks a lot for your valuable input! :-)
* How do other interfaces (like AT-SPI Table, TableCell and Selection)
expose
Hi Michael,
Some great questions and points here; forgive my intruding into the
space again =)
On 11/06/2024 08:55, Michael Weghorn wrote:
Limiting children to the to "close to visible" cells sounds like a
potential approach.
For a performant, caching AT I would argue this
On 2024-06-11 10:48, Michael Weghorn wrote:
On 2024-06-11 10:07, Samuel Thibault wrote:
Michael Weghorn, le mar. 11 juin 2024 07:55:47 +, a ecrit:
The feedback I've received from a11y experts so far is that
off-screen doc
content should *generally* be exposed on the a11y level, and
On 2024-06-11 10:07, Samuel Thibault wrote:
Michael Weghorn, le mar. 11 juin 2024 07:55:47 +, a ecrit:
The feedback I've received from a11y experts so far is that off-screen doc
content should *generally* be exposed on the a11y level, and limiting Calc
to not do that with its huge amount of
Hi,
thanks for sharing your thoughts!
On 2024-06-10 16:37, Michael Meeks wrote:
Let me add my 2 cents; a spreadsheet can have 10^20 rows, and 2^14
columns - that's 34 bits already - so even in the case that you thought
you wanted to iterate them all over a remote bus - you don't.
True.
On 10-06-2024 16:37, Michael Meeks wrote:
Hi all,
On 07/06/2024 14:20, Luuk van der Duim wrote:
Thanks for your thoughts! I will gladly expand a bit.
Let me add my 2 cents; a spreadsheet can have 10^20 rows, and 2^14
columns - that's 34 bits already - so even in the case that you
> On Jun 10, 2024, at 10:37 AM, Michael Meeks
> wrote:
>
> My attempts to encourage people to expose only the visible (or near visible)
> items in the past were not that productive; but I still firmly believe this
> is the only sensible way to do this.
FWIW, on macOS asks for the full
I've submitted a merge request to at-spi2-core to limit the maximum
amount of children to return, similar to what an earlier change did
when using the Collection interface:
https://gitlab.gnome.org/GNOME/at-spi2-core/-/merge_requests/159
Does that help?
I think it will - at least in the
Hi all,
On 07/06/2024 14:20, Luuk van der Duim wrote:
Thanks for your thoughts! I will gladly expand a bit.
Let me add my 2 cents; a spreadsheet can have 10^20 rows, and 2^14
columns - that's 34 bits already - so even in the case that you thought
you wanted to iterate them all over a
Thanks for the additional explanations!
On 2024-06-07 15:20, Luuk van der Duim wrote:
What any screen-reader/AT would like is to offer best response times to
users by caching objects up-front to minimize IPC round trips between AT
and application.
For `atspi` we would like to offer a cache
Thanks for your thoughts! I will gladly expand a bit.
LibreOffice doesn't proactively send a list of all cells, so one
question could be why the screen reader/AT is querying all of the
children (cells) in the first place, rather than only those it's
interested in for some reason, e.g.
*
Hi,
thanks for bringing this up.
On 2024-06-06 23:44, Luuk van der Duim wrote:
While working on fama11y-tree [1], an AT-SPI2-bus objects tree example,
I found that LibreOffice Calc has an object that exposes 2^31 children
on its `Accessible` interface.
(LO version: 24.2.3.2 x86_64, xubuntu
Hi!
While working on fama11y-tree [1], an AT-SPI2-bus objects tree example,
I found that LibreOffice Calc has an object that exposes 2^31 children
on its `Accessible` interface.
(LO version: 24.2.3.2 x86_64, xubuntu 24.04)
The object:
Inspecting object with high child count
Object: name:
Hi!
While working on fama11y-tree [1], an AT-SPI2-bus objects tree example,
I found that LibreOffice Calc has an object that exposes 2^31 children
on its `Accessible` interface.
(LO version: 24.2.3.2 x86_64, xubuntu 24.04)
The object:
Inspecting object with high child count
Object: name:
19 matches
Mail list logo
