[BRLTTY] Footsteps towards better accessibility in Linux
Aura Kelloniemi
kaura.dev at sange.fi
Tue May 6 20:11:47 UTC 2025
Hello,
On 2025-05-06 at 08:01 -0400, <kperry at blinksoft.com> wrote:
> Well more a Braille framework rather than a goal. It could be based on
> BRLTTY but it is hard to create the same kind of access since the BRLTTY has
> a one to one corispondence to a console based app.
BRLTTY currently has a double role. On one hand it acts as a driver for
braille displays – abstracting over the different communication protocols used
by different display models. On the other hand BRLTTY is a screen reader.
I think that we could discuss decopuling these activites – i.e. separating
BrlAPI server out of BRLTTY (possibly together with some additional features).
BRLTTY would then always communicate with the display(s) through BrlAPI.
(BRLTTY could still of course support embedding the braille drivers to the
main BRLTTY binary for use in constrained environments, like initramfs.)
Anyways, my current view is that we should build APIs that are generic and
screen-reader agnostic. APIs which can be speech or braille specific, or
useful for both of these technologies. AT-SPI needs fixing in some places, and
maybe it is not a whole lot of work, I don't know. Maybe Samuel (or somebody
else, who knows about AT-SPI) could elaborate on whether AT-SPI is worth
expanding, or do you think it should be replaced by something else?
Of course we could look for funding to improve braille support of Orca or to
get braille support into Odilia (if Odilia seems like it could replace Orca),
but I think that infrastructural questions should be decided upon first.
I have tried not to bring too many of my concrete ideas into this discussion,
as I felt it is too early, but maybe it is not too early any more.
--
Aura
More information about the BRLTTY
mailing list