Multi-Screen Window Placement 2021-11-25

[anssiko]

• name of spec to be reviewed: Multi-Screen Window Placement

• URL of spec: https://www.w3.org/TR/window-placement/

• Do you need a reply by a particular date? Prefer a response by EOY 2022.

• Please point to the results of your own self-review: https://github.com/w3c/window-placement/issues/117

• Where and how to file issues arising? https://github.com/w3c/window-placement/issues/

• Pointer to any explainer for the spec? The following two explainers cover the Multi-Screen Window Placement feature scope in review: incremental improvements to existing screen information and window placement APIs and API enhancements to allow initiation of multi-screen experiences from a single user activation. These explainers should be read in that order.

Other comments:

We look forward to enhancing the existing Accessibility Considerations with your feedback. Thank you for your review!

[ruoxiran]

tracking at: https://www.w3.org/WAI/APA/wiki/Multi-Screen_Window_Placement

[anssiko]

I gentle reminder that we’d love to get your a11y feedback.

[matatk]

Hi @anssiko. I'm sorry for our slow reply. We look forward to working with you.

One of our members, @mbeganyi, reviewed your spec, and we have a couple of questions and suggested changes. We'd be happy to work with you on both of these.

We note that you have an accessibility considerations section, which is a great start. However, it's quite abstract; would you be able to include some more concrete examples?

There are a number of ways that APIs such as this may affect users, and use, of assistive technologies (such as screen readers, and magnifiers). One immediate concern with our review was how alerts about new content being made available might be fired, and how that would affect, or be managed by, people using assistive technologies. That's a general problem (so perhaps still quite abstract) but addressing it would be most helpful.

When searching for more concrete use cases, I was looking through some documents we have published on use cases/access needs for Real-time comms; Remote Meetings and XR. The biggest one that seems relevant here is Window anchoring and pinning, but there could be others (I'll keep looking, but recommend you and your group to have a look too, as you might spot something that's relevant).

I hope this is useful feedback and, again, we look forward to working with you.

Everything you need is in this comment but, for completeness, here's a link to our full review email thread.

[anssiko]

@matatk thanks for your feedback!

We note that you have an accessibility considerations section, which is a great start. However, it's quite abstract; would you be able to include some more concrete examples?

I'll let @michaelwasserman chime in with concrete examples. He authored the current accessibility considerations.

One immediate concern with our review was how alerts about new content being made available might be fired, and how that would affect, or be managed by, people using assistive technologies.

IIUC the alert behaviour is similar to any window(s) programmatically opened via the "vanilla" window.open() method invocation (without the new extensions). IOW, the alert behaviour is not modified by this API.

Is there an established pattern on how AT handles alert() or other modal dialogs such as confirm() and prompt()? Any related recommendations for spec authors? We are happy add more accessibility-related guidance to the spec.