Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REQ 3b: Turning turn off of 'mute' of non-critical messaging could be problematic #37

Open
cdpatnoe opened this issue Mar 30, 2020 · 2 comments
Assignees
Labels
enhancement New feature or request XAUR

Comments

@cdpatnoe
Copy link

If we mute notifications, one is at risk of losing information that could be important (even if non-critical).

I know we don't want to be too prescriptive, but having access to notifications later would be important. Not having access to a "stream" or "notification hub" could be moral equivalent to data loss.

@RealJoshue108 RealJoshue108 self-assigned this Apr 1, 2020
@RealJoshue108
Copy link
Contributor

@cdpatnoe The idea behind the requirement is largely around user control. This is however, an interesting point. There may be a requirement around the need for 'caching' or delaying notification - and having the ability to choose when to review them. Worth further discussion, so I'm flagging this in APA.

@RealJoshue108
Copy link
Contributor

RealJoshue108 commented Apr 15, 2020

@cdpatnoe We have discussed this in RQTF and it is was mooted that this is an argument for more granular control of message type similar in screen readers. Where the user can skim by hearing the beginning of things on a page and explore further if they wish.

The user should be able choose what that preference is rather like a verbosity setting.

@RealJoshue108 RealJoshue108 added the enhancement New feature or request label Apr 15, 2020
@ruoxiran ruoxiran transferred this issue from w3c/apa Mar 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request XAUR
Projects
None yet
Development

No branches or pull requests

2 participants