a11y self review check list

[himorin]

This AR module spec has the same accessibility properties as the WebXR Device API that it builds on, and as such all accessibility considerations match that of the original API. (pre-CR self check result, HR request for WebXR Device API spec, for reference)

• If technology allows visual rendering of content
  • There is a defined way for a non-visual rendering to be created.
  • 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.
  • Changing content presentation does not render it unreadable.
  • Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it.
  • It is possible to make navigation order correspond to the visual presentation.
  • API does not touch what kind of content will be included in overlay by AR, so none of above are defined in spec (except for UI or navigation mentioned in some notes). a11y considerations on WebXR Device API covers discussions in this area.
• If technology provides author control over color
  • no color control
• If technology provides features to accept user input
  • no user input
• If technology provides user interaction features
  • interaction is defined and handled in WebXR Device API
• If technology defines document semantics
  • no semantics
• If technology provides audio
  • no audio
• If technology allows time limits
  • no time related data
• If technology allows text content
  • text content can be inserted as pixel image by application, but no specific handling in this API
• If technology creates objects that don't have an inherent text representation
  • no object, API handles pixel image passed from application
• If technology provides content fallback mechanisms, whether text or other formats
  • no content fallback mechanism
• If technology provides visual graphics
  • API handles visual graphics but not to generate them
• If technology provides internationalization support
  • no i18n item
• If technology defines accessible alternative features
  • no
• If technology provides content directly for end-users
  • API provides a way that application can provide content for end-users, but does not generate their content
• If technology defines an API
  • no API, extends WebXR Device API with adding attributes
• If technology defines a transmission protocol
  • no

[himorin]

@toji please cross check this.

[Manishearth]

Worth explicitly mentioning: "this spec has the same accessibility properties as the WebXR Device API that it builds on, and as such all accessibility considerations match that of the original API [link to WebXR doc]"

[toji]

LGTM.

[himorin]

Worth explicitly mentioning: "this spec has the same accessibility properties as the WebXR Device API that it builds on, and as such all accessibility considerations match that of the original API [link to WebXR doc]"

updated