[vibration] Accessibility Checklist (#37)

anssiko has just created a new issue for https://github.com/w3c/vibration:

== Accessibility Checklist ==
# Accessibility Checklist

> [!WARNING]
> **This is a work in progress draft to solicit Working Group review and feedback for the Accessibility Checklist (aka FAST Checklist) responses. The primary aim of this exercise is to provide supporting material for the accessibility review of the specification. This content may also be helpful later as the group further improves the API.**

The [Accessibility Checklist](https://w3c.github.io/apa/fast/checklist.html) document is structured into the following sections, with top-level conditions reproduced here to facilitate review. Considerations deemed not applicable are marked as "N/A", and those considered relevant are expanded further.

- ### If technology allows visual rendering of content
N/A
- ### If technology provides author control over color
N/A
- ### If technology provides features to accept user input
N/A
- ### If technology provides user interaction features

- [x] **When providing imperative mechanisms to implement technology features (e.g., scripts), authors can expose accessibility information to accessibility APIs.**

The API returns true if the vibration operation is successful. An implementation can however also return true even if a physical vibration stimuli did not occur e.g. if a vibration cue is conveyed by other means than physical stimuli such as an implementation-defined visual indicator or other mechanism better suited to accessibility tools.

- ### If technology defines document semantics
N/A
- ### If technology provides time-based visual media
N/A
- ### If technology provides audio
N/A
- ### If technology allows time limits
N/A
- ### If technology allows text content
N/A
- ### If technology creates objects that don't have an inherent text representation

- [x] **There is a mechanism to create short text alternatives that label the object.**
- [x] **There is a mechanism to create extended text alternatives for fallback content.**
- [x] **Text alternatives can be semantically "rich" e.g., with page structure, text style, hyperlinks, etc.**

The API does not create objects in a strict sense. Regardless, the API provides developers a means to programmatically create vibration patterns and a conformant implementation could, e.g. with the help of accessibility tools, provide a user a textual representation of a vibration when it occurs ("the device vibrated when you interacted with a navigation bar"), including ahead of time announcement ("the device _will_ vibrate when you interact with this navigation bar").

The vibration pattern is composed of low-level primitives, a vibration followed by a pause, both expressed in milliseconds, up to an implementation-defined length. Given this information, implementations can provide more semantics about the vibration pattern through accessibility tools ("the device is vibrating for 1 second, pauses for 2 second, vibrates again for 1 second...").

- ### If technology provides content fallback mechanisms, whether text or other formats

While the API does not provide an explicit way to mark/associate/indicate alternative content, an implementation could use a screen reader to announce when a vibration operation occurs ("the device is vibrating"), or produce other applicable cue, such as a buzzing sound to simulate vibration stimuli using auditory means, or use any other means applicable to meet the personal accessibility requirements.

- ### If technology provides visual graphics
N/A
- ### If technology provides internationalization support
N/A
- ### If technology defines accessible alternative features
N/A
- ### If technology provides content directly for end-users
N/A
- ### If technology defines an API

- [x] **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 API has adopted a design where the user must interact with the site to allow it to vibrate. This design uses an abstraction called sticky activation. This mechanism requires an explicit click, tap, or press of a key to enable the feature. Specifically, scrolling past an iframe does not count as a user activation.

This design is conceptually analogous to how web audio and video autoplay is gated by a user activation. Considerations motivating the adoption of user activation gating over prompting were explicit user feedback that user activation gating provides a better user experience for this API compared to native UI controls such as modal prompts, dialogs, or door hanger UIs and learnings from a large-scale use of the same mechanism for web audio and video autoplay.

The Working Group is aware of positive feedback from the disabled community for this API design for the Vibration API specifically, quoting ([source](https://github.com/WICG/interventions/issues/25#issuecomment-274098049)):

>In fact I have been talking to a friend of mine that is expert in Typhlotechnia (accessibility technologies) from ONCE (Spanish Disabled Organization) whom I worked in 2014 in "Touchover", a research project to allow blind people to touch images in smartphones (feeling roughness, image edges, buttons, Braille code, etc, using the phone vibration), has made me some comments about this:
>
>* Any haptic content is welcomed on disabled community (deaf, blind, old people), this will help the creation of rich content for them, not only video but music production (feeling beats and intensity of music, you'll get amazed by this Martin Garrix experience with deaf youngs), maps (mentioned by Rick above), images, games, and more to come.
>* Advertising messages can't reach several disabled people because it is not ready for them, and some of them are interested in them too (specially videoclips and interactive ads)
>* Any pop-up action intended to allow it by the user is not welcomed because in such a case the people interested in feeling, for instance an autoplay haptic video, should have to press it twice (once for haptic and one for sound), that's difficult even for a non-disabled person.

#### 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.

This API allows, but does not require, an implementation to make use of explicit user mediation through a native UI. Specifically, the API design allows a conformant implementation to show a UI to ask the user for permission to choose to allow or deny vibration on first invocation on a per-origin basis. However, the recommended mechanism is to use user activation gating instead, as discussed in the previous section, as it also provides a more accessible experience according to user feedback.

- ### If technology defines a transmission protocol
N/A


Please view or discuss this issue at https://github.com/w3c/vibration/issues/37 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 25 June 2024 11:12:32 UTC