Add Accessibility Considerations (#869)

Use distinct actors "web author", "user", and "implementer".
Use "encouraged to" when RFC 2119 key words do not apply.

Based on accessibility review feedback:
w3c/a11y-request#105

Co-authored-by: Dwayne Robinson <[email protected]>

Author: anssiko

index.bs

@@ -404,6 +404,8 @@ built on top of pre-trained deep neural network (DNN) [[models]].
 
 Note: Please be aware that some of the use cases described here, are by their very nature, privacy-invasive. Developers who are planning to use the API for such use cases <span class=allow-2119>should</span> ensure that the API is being used to benefit users, for purposes that users understand, and approve. They <span class=allow-2119>should</span> apply the Ethical Principles for Web Machine Learning [[webmachinelearning-ethics]] and implement appropriate privacy risk mitigations such as transparency, data minimisation, and users controls.
 
+Note: [[#accessibility]] provides guidance on how to improve accessibility of these use cases.
+
 ### Person Detection ### {#usecase-person-detection}
 
 A user opens a web-based video conferencing application, but she temporarily
@@ -601,6 +603,21 @@ A JavaScript ML framework is responsible for loading, interpreting and executing
 
 The user experience of WebRTC-based video conferencing is enhanced using real-time video processing. For example, background blur implemented using a [[#usecase-segmentation]] model blurs the background in the user's live camera feed. To satisfy the performance requirements of this use case, the WebNN API integrates with primitives from other Web APIs that make up the media pipeline to allow WebNN API-based transformation of real-time video streams.
 
+Accessibility Considerations {#accessibility}
+===================================
+
+This section provides guidance to web authors on how to improve accessibility of [[#usecases-application]] enabled by neural network inference hardware acceleration. This guidance generalizes beyond the specific use cases outlined in this specification, and web authors are encouraged to consult [[wcag]] for further accessibility guidance and [[#ethics]] for digital accessibility in context of ethical principles.
+
+[[#usecase-image-captioning]] can be improved by ensuring the captions are surfaced to screen-reader and other Assistive Technology (AT) users. Web authors are encouraged to ensure the generated image captions are semantically linked to their respective images, either via the standard alt attribute, or other means which may depend on whether the descriptions are updated on initial page load, or later, as the result of user action.
+
+[[#usecase-emotion-analysis]] can mis-label and thus mis-classify users, leading to discriminatory experiences. Web authors are encouraged to expose confidence scores and give users an option to turn the feature off.
+
+[[#usecase-noise-suppression]] with aggressive filters can wipe out the speech of users with dysarthria, making captions and recognition fail. Web authors are encouraged to expose a bypass or sensitivity control, and not hard-wire noise suppression when live captions are active.
+
+[[#usecase-real-time-video-processing]] with background-blur powered segmentation helps remove distractions, but can add too much delay that breaks lip-reading and live captions. Web authors are encouraged to provide an ability for user-facing keyboard- and screen-reader-operable “Background blur on/off” control, surfaced next to other accessibility/media settings.
+
+[[#programming-model-device-selection]] allows web authors to indicate preferences for execution speed and power consumption. Implementers are encouraged to allow users to override the web author hint in browser UI to ensure that people on low-end or battery-sensitive devices can keep captions and other critical accessibility features responsive, especially on portable AAC or eye-gaze setups.
+
 Security Considerations {#security}
 ===================================
 This specification defines a low-level API for neural network inference hardware acceleration. This API is considered a powerful feature [[POWERFUL-FEATURES]] because it grants low-level access to a user's computer. To meet the authentication and confidentiality expectations of a powerful feature and to prevent man-in-the-middle attacks, all interfaces defined by this specification are only available in a secure context.