-
Notifications
You must be signed in to change notification settings - Fork 25
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
Accessibility Checklist #117
Comments
@michaelwasserman here's my first stab, PTAL. When we're happy, I'll initiate the official a11y review. |
Thank you for kicking this off, and creating a high-quality initial draft! |
Thanks for already requesting that review, the progress of which is tracked here |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is a record of the Second Screen Working Group's response to the Accessibility Checklist for the Multi-Screen Window Placement API. Completed Checklist is required for the submission of the Accessibility review, one of the wide reviews tracked in #110.
Multi-Screen Window Placement API: Accessibility Considerations
As a starting point, the current version of Accessibility Considerations is as follows:
Accessibility Checklist
The Accessibility Checklist document is structured into the following sections, with top-level conditions reproduced here to facilitate WG review. Those with a checkmark are considered relevant to this specification and will be discussed in more detail in the sections that follow.
If technology allows visual rendering of content
This API does not hinder automated conversion of presented content into alternate formats, or to content that can provide explicit non-visual alternatives.
Content in windows placed on other screens by means of this API can be adapted with Assistive Technology or using the browser built-in controls, similarly to the content on the primary screen.
N/A
The API programmatically exposes a virtual screen arrangement that defines the relative placement of screens that comprise the overall visual environment of the device. Windows or fullscreen content are programmatically placed on these screens with this API in response to a user action.
For example, a user may have two screens side by side, and a user action on one screen may place a window on the other screen, out of the user's field of view. Accessibility of this feature can be improved by means of Assistive Technology (AT), e.g. by announcing when content is placed on a specific screen ("a new window was opened on the left-hand screen"). Announcements of cross-screen content placement by the user agent or AT functionality could also raise user awareness of potential API abuse, as described in the API's Security Considerations.
If technology creates objects that don't have an inherent text representation
The API defines a concept of virtual screen arrangement that defines the relative placement of screens that comprise the overall visual environment of the device. These concepts do not have an inherent text version beyond the relative bounds rectangles of individual displays. It is however, possible to leverage the Assistive Technology included in the OS to provide a textual versions of these abstractions such as "screen on your left-hand side" to have a meaningful label.
N/A
If technology defines an API
N/A
The only user agent generated user interface is the permission prompt displayed when detailed information about screens used by the device are requested. This user interface component is reused by various powerful features and no new accessibility requirements are suggested by this API.
The text was updated successfully, but these errors were encountered: