notifications
notifications copied to clipboard
whatwg
Defer & Queue
The Accessible Platform Architectures (APA) Working Group at the W3C believes there are significant use cases requiring API support for "Do Not Disturb" functionality in various web applications, whether accessed via mobile device or desktop browser. We are advised by W3C colleagues that the appropriate locus for our feature request is the Notification specification.
One such use case is the conclusion of a financial transaction where it is critical that the key terms of the transaction can be completed without distracting interruptions--which could also trigger timeouts that would exaserbate the user's ability to complete the transaction. The key juncture of a financial transaction might include the screen where payment is finally authorized, a digital signature is applied, and an accessible receipt is recieved.
Another use case is to prevent a list of items from scrolling while a screen reader user is iterating through the list. Push actions which result in scrolling exaserbate the user's ability to function smoothly by causing the focus to shift outside the user's control.
We note this kind of functionality is available heuristically on mobile platforms. An example Android application providing similar functionality is: https://play.google.com/store/apps/details?id=com.tryagent
However, what is needed is the ability to temporarily suspend push notifications via an API call, so that an application can invoke a "Do not disturb" feature based on context, and so that users may gain easier access to turning notifications on and off directly, whatever the platform, without navigating multiple menus.
We propose the addition of a section in support of this feature requirement as follows:
Section 2.12 Defer and Queue
When this flag is set no notifications are delivered to the user interface. Rather they are queued for display once the flag is cleared.
Thanks for the feedback!
I think I'm missing something, as it seems to me that the application already has all the control to temporarily disable notifications. If they don't create any notifications, none will be shown. It seems to me this kind of queuing logic is better implemented in a library on top of the standard API.
However, you also suggest that users should have easy access to such functionality, which makes me think you don't want this to be an API for applications?
And just to be clear, push notifications are defined in https://w3c.github.io/push-api/ as far as network traffic is concerned, but this here is indeed the standard that's responsible for showing notifications to end users.
Thanks for the prompt response, Anne, and sorry I'm slow getting back to you. I'll try to stay more on top of this. The requirement in the first of our two use cases is to control subscribed notifications that come from outside the current application. The idea is to generalize a mobile device's "Do Not Disturb" functionality across all browsing/application environments, desktop as well as mobile. The second use case could certainly be handled by the application, but we think it would be far easier to allow the AT a user is relying on to get this on/off effect using the same gesture, regardless the underlying application. Does this help explain things? I think we're actually far more concerned with the first use case as people working on payments in W3C believe its applicability is wider than just accessibility. However, we believe both use cases present accessibility requirements.
I think I still don't understand the scenarios well enough or the technologies that would be involved in creating it. "Subscribed notifications" makes me think you want to file an issue at https://github.com/w3c/push-api/issues/new instead, but I'm definitely not sure that's what you're after.
E.g., one way of reading what you're saying that is that the user agent should expose more functionality to the user to control the flow of notifications. However, that doesn't match with you suggesting the need for some kind of API. Or did you not mean an API exposed to applications?
It's kind of funny--but we filed this issue at the suggestion of W3C's Web Platforms WG. APA had comments on the W3C Push API, and we were told our use cases were inappropriate for Push API, but would be appropriate for the Notifications API. Since the W3C work on Notifications is now closed, we were advised to come here. Anne, will you be at TPAC per chance? Perhaps, as a worst case, we could discuss there? Meanwhile, let me try another explanation vector ... Our argument is that bad things can happen for users unless: 1.) An application handling a payment transaction can't stop interruptions to the UI at key moments. 2.) An AT can't give the user a quick way to defer any toasts, popups, spoken output, etc.
I won't be at TPAC this year. If you think this would be easier to communicate through voice I'm happy to join some call, provided it's a somewhat convenient time for Europeans (I'm generally available 9AM-5PM or 7PM-9PM, Zürich time).
Questions:
- If an application handling a payment transaction cannot be interrupted, is that because of a flaw in the application? How would you envision that to be solved?
- Why can AT not give the user a quick way to defer notifications et al?
Anne, W3C APA's telecon is Wednesdays at Noon Boston, currently 16:00 UTC. Would that work? I'd like to propose Wednesday 11 October at that time, if that works for you. Earlier and we wouldn't have the people we'd like to bring to the discussion. BTW, you're absolutely right to ask for use cases. I'm not sure just typing them in a comment field is the way to put that together, though. I'll endeavor to create a document before the 11th to start defining those.
Mind if I tag along to that call, @JaninaSajka, given that I'm involved in both the Push API and Notifications?
I could do 17:00 UTC. I have to pick up my kid from daycare around 16:00. There's also some risk I can't make that date at the last minute due to it being rather close to the due date of our second child. Earlier would be better (or say, November).
Peter, your participation would be most welcome. And, Anne, your need to be present for the birth of your child certainly takes precedence! Let's hold for the 11th for now. I'm also juggling availability of W3C people. But, if we need to postpone--even last minute--we can do that. I will post a URI to the agenda a few days ahead of the call. We use Webex with password, and need to ensure the passwords don't become visible, so I'll need an email address for that bit.
@JaninaSajka thanks, I emailed you at a11y.org (also included Peter in the email).
It seems like there is a confusion here between the UX piece (notifications) and the networking piece (push API). My understanding is that @JaninaSajka is concerned about the effect on the user experience. I trust that Peter can help you sort this out because I like to sleep at that hour.
Telecon logistics and agenda for our call tomorrow, Wednesday 11 October at 17:00 UTC are provided at:
http://lists.w3.org/Archives/Public/public-apa/2017Oct/0017.html
Please note we're also on IRC, which is important to W3C process. Note also the multiple options for connecting via Webex. If you're not already configured for using Webex, you might want to check these options in advance.
If you have any questions, please don't hesitate to contact me directly or via this github.
Thanking you in advance for your participation,
Janina
Martin Thomson writes:
It seems like there is a confusion here between the UX piece (notifications) and the networking piece (push API). My understanding is that @JaninaSajka is concerned about the effect on the user experience. I trust that Peter can help you sort this out because I like to sleep at that hour.
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/whatwg/notifications/issues/107#issuecomment-332375657
--
Janina Sajka, Phone: +1.443.300.2200 sip:[email protected] Email: [email protected]
Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org
The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
Minutes from our teleconference are available at http://lists.w3.org/Archives/Public/public-apa/2017Oct/0025.html
The conclusion was that we should advice users agents to give users sufficiently control over the flow of notifications. For instance, by perhaps not unduly distracting users when the user agent knows they are otherwise occupied (e.g., via a web site using a payments API).
APA picking this up (after 4 years), wants to resume discussion, will re-orient and then reach out.
