Accessibility Checklist

[anssiko]

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:

This specification enables sites to place content on specific screens, which may pose limited new accessibility risks. The visual presentation, non-visual rendering, and effect of assistive technologies on the content itself is not commonly substantially influenced by the placement of content on one screen or another. Still, existing accessibility risks of programmatic content placement may be exacerbated by the expanded areas over which content may be placed. Existing accessibility considerations regarding default powerful feature permission models, prompting methods, and permission-related UIs, are equally pertinent to this particular specification’s permission.

There are no documented accessibility considerations pertaining to the structured screen information (and accessibility features thereof) exposed by the API at this time.

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
• If technology provides author control over color
• If technology provides features to accept user input
• If technology provides user interaction features
• If technology defines document semantics
• If technology provides time-based visual media
• If technology provides audio
• If technology allows time limits
• If technology allows text content
• If technology creates objects that don't have an inherent text representation
• If technology provides content fallback mechanisms, whether text or other formats
• If technology provides visual graphics
• If technology provides internationalization support
• If technology defines accessible alternative features
• If technology provides content directly for end-users
• If technology defines an API
• If technology defines a transmission protocol

If technology allows visual rendering of content

• There is a defined way for a non-visual rendering to be created.

This API does not hinder automated conversion of presented content into alternate formats, or to content that can provide explicit non-visual alternatives.

• Content can be resized.
• Luminosity and hue contrast can adapt to user requirements.
• Text presentation attributes can be changed.
• Visual presentation of pointers and cursors can be adjusted.

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.

Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it.

N/A

• It is possible to make navigation order correspond to the visual presentation.

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

• There is a mechanism to create short text alternatives that label the object.

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.

• There is a mechanism to create extended text alternatives for fallback content.
• Text alternatives can be semantically "rich" e.g., with page structure, text style, hyperlinks, etc.

N/A

If technology defines an API

• If the API can be used for structured content, it provides features to represent all aspects of the content including hidden accessibility features.

N/A

• If the API relies on user agents to generate a user interface, the specification provides guidance about accessibility requirements needed to enable full interaction with the API.

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.

[anssiko]

@michaelwasserman here's my first stab, PTAL. When we're happy, I'll initiate the official a11y review.

[michaelwasserman]

Thank you for kicking this off, and creating a high-quality initial draft!
I made some minor edits, and believe it is in good shape to request review.

[michaelwasserman]

Thanks for already requesting that review, the progress of which is tracked here