a11y short check list

[himorin]

• [ ] If technology allows visual rendering of content
  • no visual rendering
• [ ] If technology provides author control over color
  • no color control
• [x] If technology provides features to accept user input
  • There is a mechanism to label user input controls in an unambiguous and clear manner.
  • no, clearly defined by hardware
  • Authors can associate extended help information with a control.
  • no, clearly defined by hardware
  • If there is an input error, it is possible to associate the error message clearly with the specific control that is in error.
  • handled within Gamepads spec
  • There is a mechanism to report and set the state or value of controls programmatically.
  • no, simply user input
  • Authors can address multiple types of input hardware (keyboard, pointing device, touch screen, voice recognition, etc.), or the technology supports hardware-agnostic input methods.
  • no, this is a module for a single type of input hardware
  • This is a module for a single type of input method which is closely connected to specific hardware. But implementation can give users quite a bit of control over what system inputs are mapped like from keyboard and all of that is an implementation detail and beyond the scope of this spec.
  • User input does not require specific physical characteristics (e.g., fingerprint readers).
  • does not require
  • Authors can ensure a "meaningful" order of controls exists regardless of presentation.
  • no presentation is defined in this spec
• [ ] If technology provides user interaction features
  • interaction is defined and handled in WebXR Device API layer
• [ ] 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
  • no text content
• [ ] If technology creates objects that don't have an inherent text representation
  • no object for presentation
• [ ] If technology provides content fallback mechanisms, whether text or other formats
  • no content fallback mechanism
• [ ] If technology provides visual graphics
  • no graphics
• [ ] If technology provides internationalization support
  • no i18n item
• [ ] If technology defines accessible alternative features
  • this is a module for a single type of input device
• [ ] If technology provides content directly for end-users
  • no content defined, just input
• [ ] If technology defines an API
  • no API, just to attach Gamepads into WebXR
• [ ] If technology defines a transmission protocol
  • no

[himorin]

@toji please cross check this.

[toji]

Seems reasonable! LGTM with a couple of minor notes:

• Authors can address multiple types of input hardware (keyboard, pointing device, touch screen, voice recognition, etc.), or the technology supports hardware-agnostic input methods.
  • no, this is a module for a single type of input hardware

Theoretically the API can surface anything that produces button or axis input, and some utilities like SteamVR give users quite a bit of control over what system inputs are mapped to those buttons/axes. All of that is an implementation detail, though, and beyond the scope of this spec.

• Authors can ensure a "meaningful" order of controls exists regardless of presentation.
  • no presentation is defined in this spec

I'm a little confused by this one? It's correct that we don't have a presentation aspect in this spec, but the controls are also prescribed a "meaningful order" by the xr-standard mapping? Not sure if that's what's being referred to here.

[himorin]

Seems reasonable! LGTM with a couple of minor notes:

• Authors can address multiple types of input hardware (keyboard, pointing device, touch screen, voice recognition, etc.), or the technology supports hardware-agnostic input methods.

  • no, this is a module for a single type of input hardware

Theoretically the API can surface anything that produces button or axis input, and some utilities like SteamVR give users quite a bit of control over what system inputs are mapped to those buttons/axes. All of that is an implementation detail, though, and beyond the scope of this spec.

Ah, yes. I should write as something like 'a single type of input method' but not 'hardware'. I agree that all are an implementation detail, like some utilities may map keyboard inputs as gamepads like input. Updated as This is a module for a single type of input method which is closely connected to specific hardware. But implementation can give users quite a bit of control over what system inputs are mapped like from keyboard and all of that is an implementation detail and beyond the scope of this spec.

• Authors can ensure a "meaningful" order of controls exists regardless of presentation.

  • no presentation is defined in this spec

I'm a little confused by this one? It's correct that we don't have a presentation aspect in this spec, but the controls are also prescribed a "meaningful order" by the xr-standard mapping? Not sure if that's what's being referred to here.

I've read this as order of multiple input devices. hrm...