- From: Matthew Tylee Atkinson <notifications@github.com>
- Date: Wed, 20 Nov 2024 08:47:17 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/962/2489090160@github.com>
@eladalon1983: > Could you please clarify which UI changes you are referring to? As far as I can tell, this spec does not deal with anything UX-related. Although bespoke user agent UX associated with these APIs is possible, this is completely up to the UA's discretion; a spec-compliant implementation is possible even without any additional user agent UX. > > To clarify, [this mock](https://github.com/screen-share/captured-surface-control/blob/main/images/explainer/onboarding_mock_full_context.png) is of the Web application's possible UX, not the user agent's. Totally agree that we generally aim to avoid specifying UI/UX, and ACK that the UI in the example is from the app (and, of course, UI is already covered by WCAG - though I'll come back to that). Let me hopefully clarify... Whilst a spec may be for a low-level API, products built with the API are often user-facing. Developers building things with the API may not imagine some of the ways users could be using them; it can be helpful to raise awareness of the opportunities, and any risks, and makes sense to do that in the spec itself. A concrete and helpful example of some big accessibility wins, and some patterns to avoid, can be found in the [Compute Pressure API's Accessibility Considerations section](https://www.w3.org/TR/compute-pressure/#accessibility-considerations). This example is great because it shows how the API can affect users (UI decisions being made based on its output), how this can help users, and also the importance of meeting, but thinking beyond WCAG in a particular domain. In the case of Captured Surface Control, there is a new avenue through which to interact with the preview, and a new avenue to scroll and zoom the target tab. As an extensive sample of one vision-impaired people, this seems like a helpful thing to me :-). I am not 100% sure how/if focus considerations would come into play (focusing the PiP window is likely out of scope, but would you expect there to be interactive controls floating within it?) It'd be great to read your thoughts on this in the explainer. APA WG would be happy to follow the development of this API—please consider requesting a review, or tagging APA WG via the "a11y-tracker" label in any issue where you think some input may be of help. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/962#issuecomment-2489090160 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/962/2489090160@github.com>
Received on Wednesday, 20 November 2024 16:47:21 UTC