[BRLTTY] Footsteps towards better accessibility in Linux

[Sébastien Hinderer]

Aura Kelloniemi (2025/04/05 23:36 +0300):
> Hi,
> 
> On 2025-04-05 at 13:23 +0200, Sébastien Hinderer <Sebastien.Hinderer at ens-lyon.org> wrote:
>  > Aura Kelloniemi (2025/04/04 15:23 +0300):
>  > > I wonder whether other types of widgets than terminals would be best handled
>  > > by a dedicated screen reader that would communicate with the braille display
>  > > using BrlAPI. BRLTTY is best in handling terminals, and it could do that and
>  > > leave other widgets/interfaces for another tool. Of course there would be
>  > > plenty of possibilities for code sharing, and maybe the BrlAPI server would be
>  > > the right place for such shared code.
> 
>  > For non-terminal widgets, shouldn't we rather focus on improving their
>  > braille rendering as done by Orca?
> 
> Orca has its issues. Foremost, it has issues with responsiviness and
> stability.

I'd assume it to be easier to fix those than to re-do everything from
zero, especially given that I am not sure where the lack of
responsiveness comes from: is it from Orca itself or from AT-SPI?

No strong position here, justsharing thoughts and questions.

> There is already a replacement screen reader in development
> (https://odilia.app/).

Ah I didn'tknow, thanks.

>  > Otherwise I fear there will be work and effort duplication, which we
>  > cannot really afford, IMO.
> 
> I agree, and I don't really care, whether it is Orca, Odilia or BRLTTY that
> interfaces with those widgets that BRLTTY currently does not, as long as the
> screen reader works well.
> 
> Anyways my thoughts on expanding BrlAPI are relevant, regardless of what
> application is going to call it. BrlAPI prvides its clients the same input
> command set that BRLTTY uses. Those are heavily tailored towards terminal use,
> and not all of them are useful in navigating other types of widgets. Also GUIs
> would have use for other types of commands as well, like commands for
> tree-structure navigation, link/button activation, opening context
> menus, etc.

I can see your point in extending BRLTTY's set of commands, but this is
kind of orthogonal to BrlAPI which for themost part is agnostic about
the codes it transports.

And of course if the other widgets are also rendered by BRLTTY this
won't require any particular BrlAPI extension as BRLTTY does not itself
use BrlAPI, except of course in the case of the BrlAPI braille driver
but this use is very low-level and limited.