Plural accessibility in voice and text

(#947) Feature Under consideration accessibility profiles

Thread

Comment by @bunnikyuube
RexSystem 1 vote originally by @bunnikyuube on GitHub 2 replies
I'd actually like to refer to a Discussion under Stoat's git for a few reasons: https://github.com/orgs/stoatchat/discussions/76 One, on the topic of use for plural communities, i actually think the option to basically include multiple Profiles as senders of the same message is a critical quality of life feature. It's incredibly common for systems using Pluralkit, Tupperbox, etc. to have proxies dedicated to sending a message when they're kind of unsure of the active fronter, or when multiple members are active in a discussion and have the same thing to contribute collectively. I'd also like to point to this discussion because of the ways it specifically targets transparency of the host account the messages are being sent through. It's a major concern that people have when it comes to moderation, after all. Additionally, i think an implementation not unlike this, where the original account is inextricably linked with the sent message, also likely solves the issue of being unable to block users. As a result of this design, it'd be sensible that blocking the host account would block all messages from it. I don't think this is an accessibility issue, i think it stands to reason most users would not have a reason to block specific system members/profiles whilst not blocking the host account, and this sentiment has largely been echoed by others i've been around.
Comment by @bunnikyuube
RexSystem 1 vote originally by @bunnikyuube on GitHub
The only thing is that multiple personas used at once comes with a bit of UX baggage, ie: what persona is prioritized for display name & avatar, what methods of displaying all senders is available, and the like. Thinking maybe clicking/tapping the PFP opens a pull-up menu with the senders of the message, as well as the author account at the top. Display priority is given to the first persona enabled, with a +1/2/3, whatever number appended, etc etc. It's a bit of a niche case, but i think if we're going to be considering native implementation for the sake of accessibility, as one of the first platforms doing it, it's the kind of thing that i think should be considered
Comment by @haileyscommit
RexSystem 1 vote originally by @haileyscommit on GitHub
I'm thinking about having a different metadata field for the "other" contributing personas/subprofiles, so that the first one can be looked up and used for the nickname/avatar, with an indicator that there are more somewhere (and if there are two, perhaps both names will be shown, if possible; this gets weird at 3 or more). This would be a later extension of the feature, though, so that the feature can exist first.