Re: Call for Consensus (CfC): Compute Pressure Ac

+1

Janina Sajka writes:
> Colleagues:
> 
> This is a Call for Consensus (CfC) to the Accessible Platform Architectures (APA) Working Group testing for agreement on an Accessibility Considerations addition to the Device and Sensors Working Group's Compute Pressure API. The candidate AC section is attached to this email. The API is specified here:
> 
> https://www.w3.org/TR/compute-pressure/
> 
> This draft AC was discussed at length on APA's regular weekly
> teleconference of Wednesday 29 November as logged here:
> 
> https://www.w3.org/2023/11/29-apa-minutes.html
> 
> *** Action to Take ***
> 
> This CfC is now open for objection, comment, as well as statements of support via email. Silence will be interpreted as support, though messages of support are certainly welcome.
> 
> If you object to this proposed action, or have comments concerning this proposal, please respond by replying on list to this message no later than 23:59 (Midnight) Boston Time, Wednesday 6 December.
> 
> NOTE: This Call for Consensus is being conducted in accordance with the APA Decision Policy published at: http://www.w3.org/WAI/APA/decision-policy
> 
> -------------------------------------------------------------------------------
> 
> Janina Sajka (she/her/hers)
> Accessibility Consultant https://linkedin.com/in/jsajka
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Co-Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa
> 
> Linux Foundation Fellow
> https://www.linuxfoundation.org/board-of-directors-2/
> 

> # Accessibility Considerations
> 
> The Compute Pressure API is focused on improving the user experience. There are two ways in which applications that build on the API can positively impact accessibility.
> 
> 1. Considering users' access needs when making decisions based on information gathered using the API.
> 
> 2. Designing and making user interfaces based on information gained from the API with accessibility in mind.
> 
> As a consumer of the API, it's important to consider both of these opportunities. Here are some examples:
> 
> * **Decision:** In a video conferencing scenario, there may be multiple video streams. The system may determines that it needs to drop certain streams in order to conserve resources. If one of the video streams comes from a sign language interpreter, then that stream must be prioritized over others, so that the user can still understand the conversation. In practice, this could be simply implemented by allowing the user to "pin" a certain stream, and ensuring that that pinned stream is never automatically dropped by the system.
> 
> * **User Interface:**
> 
>   - A simple load-level meter, in which the current usage level bucket is indicated on the screen. This information must be conveyed using more than just color, so that people who cannot perceive color can still perceive the information. A symbol could be used in conjunction with color. Text could also be used in conjunction with both shape and color.
> 
>   - Some applications may present a notification to the user when some functionality is restricted due to compute pressure. These notifications may take the form of "toast" messages, in which case care must be taken to ensure that people using assistive technologies (including screen readers) can be made aware of the notification, and dismiss it, without unduly interrupting their workflow.


-- 

Janina Sajka (she/her/hers)
Accessibility Consultant https://linkedin.com/in/jsajka

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

Linux Foundation Fellow
https://www.linuxfoundation.org/board-of-directors-2/

Received on Tuesday, 5 December 2023 13:51:00 UTC