At least if a Braille Display is connected, accessibility resources should be enabled. Also, I don’t think desktops and such should have an accessibility toggle. If it doesn’t bother the visuals, accessibility setting for the desktop GUI itself, not Orca and such, should always be set to on. That way, if a blind person does turn on Orca, the desktop will be accessible. Also, if Fenrir becomes a standard, built into distributions, perhaps have a hotkey to turn it on at this log in, and have a way to set that as default. Also, desktops should come with a key binding for Orca, and display that there is one, and what it is, prominently on their help pages.
> On Mar 11, 2020, at 10:35 PM, Jude DaShiell <jdash...@panix.com> wrote: > > full circle, solutions zero. > > On Thu, 5 Mar 2020, Rich Morin wrote: > >> Date: Thu, 5 Mar 2020 23:54:14 >> From: Rich Morin <r...@cfcl.com> >> To: debian-boot@lists.debian.org >> Cc: debian-accessibil...@lists.debian.org >> Subject: Re: boot-time accessibility issues >> Resent-Date: Thu, 12 Mar 2020 02:07:16 +0000 (UTC) >> Resent-From: debian-accessibil...@lists.debian.org >> >> Jude DaShiell said: >> >>> If dummy was used for monitor type, the screen reader could come up talking >>> without any monitor attached. ... >> >> I can think of a couple of issues with this approach. First, there are >> various reasons for leaving a monitor off a system. For example, if a RasPi >> is being used as a server, running it "headless" might be a normal strategy, >> having nothing to do with blindness. >> >> Contrariwise, there are various reasons a blind user might want to keep an >> active monitor. They might have a sighted associate with whom they >> occasionally collaborate. Alternatively, they might want to run a touch >> screen (e.g., to type on). >> >> The fundamental problem is that keying off the presence of a monitor >> complects two separate and otherwise independent phenomena. So, it's just >> asking for conflicts. >> >> -r >> >> > > -- >
