Re: Alternative defaults for visually impaired users? (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: rms@gnu.org, jonas@bernoul.li, samologist@gmail.com,
>  emacs-devel@gnu.org, karthikchikmagalur@gmail.com, visuweshm@gmail.com,
>  raman@google.com
> Date: Sun, 22 Dec 2024 18:17:40 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> ... I meant support and maintenance in Emacs
> >> core. IMHO, these features are too important for third-party package that
> >> might be abandoned.
> >> ... 
> >
> > We do want to have accessibility features in Emacs, if that is what
> > you are asking.  (In some cases we already do: e.g., see the
> > Windows-specific variable w32-use-visible-system-caret, which aims
> > specifically at aiding screen-reading software.)
> 
> Thanks for the clarification. Then, let me expand on the idea I have.
> 
> I imagine adding "alternative" default value to `defcustom':
> 
> (defcustom variable default-value
>   :alt-default
>     (("blind" . value2)
>      ("large-fonts" . value3))
>   ...)
> 
> Then, consider custom options like
> 
> (defcustom accessibility-blind nil
>  "When non-nil, Emacs will use defaults suitable for blind users.")
> (defcustom accessibility-large-fonts nil
>  "When non-nil, Emacs will use defaults suitable for large font sizes.")
> 
> If any of the above options is non-nil, and custom variable has its
> default value (not changed by user explicitly), instead of
> "default-value" a suitable alternative value is used.
> 
> Third-party packages will also be able to make use of this semantics,
> providing better defaults if necessary.
> 
> Elisp manual should also encourage package authors to keep these
> alternatives in mind.
> 
> WDYT?

If this means that, for example, each face and defcustom we define
will need to have such alternatives defined in advance, I think it's a
non-starter.  People will forget to define those, and having such a
definition for each face/defcustom is extremely inconvenient and hard
to maintain.

(We had a similar problem long ago, when TTY frames learned to display
colors, back when they only supported 8 colors.  Originally, the idea
was that each face will have a separate definition for TTYs, but this
idea crashed and burned very fast, and instead we added transparent
conversion of X colors to TTY colors, see tty-colors.el.)

If you mean something else, please explain how (via which mechanisms)
will accessibility-* options affect Emacs, once turned on.

What I think we need is some infrastructure which will automatically
react to a setting from the accessibility set.  For "large fonts",
this is almost trivial, but other settings might be harder.

Perhaps a useful first step would be for someone to see what other
systems and applications offer in this department, and post the
findings.  Then we could discuss how to incorporate the relevant parts
into Emacs.