[BRLTTY] Is there a feature-compatible text-based browser
Brian Buhrow
buhrow at nfbcal.org
Wed Sep 17 19:00:32 UTC 2025
hello. I realize this is completely anecdoatl, but in my experience, even when using
graphical browsers such as Chrome or Edge, many dynamically generated web sites are virtually
impossible to use. I recently learned this is, in large part, due to UIA, which is how screen
readers get most of their data today, is a single-threaded library which must be accessed from
the root thread of the browser. This is why sighted users can begin interacting with such
pages much sooner than folks using screen readers. Of course, there are different definitions
of "dynamic" and I agree with ken that we should try to specify what we mean. For example,
there are many pages where there are a series of drop down menus and the choices which appear
in a given menu depend on choices made in another menu on the page. If the lynx-like interface
were modified to communicate the menu choices the user made at the time a drop down menu was
closed, as opposed to when the final submit button was pressed, most of the issues with those
types of pages would be resolved. Pages that auto-update dynamically at short intervals, say,
at 5-10 second intervals, would be a problem for every nonvisual interface I can think of
today. For example, stock broker pages which show the running stock ticker running across the
bottom of the page. Mostly the nonvisual user would elect to silence that portion of the page
and ignore it, or grab snapshots of it at much slower refresh rates. Again, however, I think
configuration options could be defined to help users deal with these types of pages in a more
efficient manner and those options could be compatible with the lynx interface paradigm. I'm
thinking about the old DOS screen reader Flipper, which dealt with issues like this by allowing
the user to define "watch" windows which could notify the user when something changed in a
region of the display, or "ignore" windows which could be completely ignored by the screen
reader regardless of what happened in the defined region. There might be a discussion about
whether some of the features should live in the screen reader or the browser, but given how
tightly modern screen readers on Windows are tied to the browser, I don't see a real problem
with making similar ties in a text-based interface.
In either case, Firelynx is an interesting start to this project, as are some of the projects
Ken has alluded to in this thread, assuming some or all of the projects mentioned can be made
more generally available to the blind developer community.
-thanks
-Brian
More information about the BRLTTY
mailing list