Compute Pressure API 2023-02-07

[anssiko]

• name of spec to be reviewed: Compute Pressure API

• URL of spec: https://www.w3.org/TR/compute-pressure/

• Do you need a reply by a particular date? Prefer a response by the end of March 2023.

• Please point to the results of your own self-review: Accessibility Checklist compute-pressure#183

• Where and how to file issues arising? https://github.com/w3cping/privacy-request/issues

• Pointer to any explainer for the spec? https://github.com/w3c/compute-pressure/blob/main/README.md

Other comments:

Thank you for your review and comments!

[ruoxiran]

@fredrika11y will look this issue.

[ruoxiran]

tracked: https://www.w3.org/WAI/APA/wiki/Compute_Pressure_Level_1

[anssiko]

@fredrika11y @ruoxiran, this is a gentle reminder that we'd like to get your a11y review feedback so that we can address it in a timely manner. Based on our a11y self-evaluation w3c/compute-pressure#183 we believe there are no accessibility considerations that should be documented in this specification.

[matatk]

Hello @anssiko, and I'm sorry for the delay in our response. This is just a personal response for now—we have been discussing your spec in our calls, and still are. I wanted to report back on our current thinking...

Whilst the API itself does not expose UI, there are some accessibility/UI considerations for apps that build on the API; here are two aspects of that:

1. In the example that involves reducing the number of concurrent video streams: if this were a videoconferencing system, it could be that one of the streams is a sign language stream. Therefore, when the number of streams is constrained, it's important that this is done with appropriate prioritisation. Whilst specifying how apps that build on the API is well out of the scope of the document, it is important to remind consumers of the API that they should consider how they'll constrain their resource usage, and how this might affect users (and the assistive technologies/adaptations they use to access the app).

2. Whilst the creation of pressure-reporting UI is not the goal (and that's made clear), it is quite possible that people will ultimately use it in this way—in which case there would be accessibility considerations. Also, it's worth noting for UA vendors that the notifications they create will need to be accessible.

To address these two aspects of building apps/features that use your API, an "Accessibility Considerations" section could be included in the spec. Your examples are very helpful, and I think it would be equally helpful for us to add a brief explanation of how the accessibility of these examples may be preserved/promoted in practice.

I'd expect such a section to be quite short, covering:

• The need to consider how resource usage would be constrained, and that it may have accessibility implications (citing the examples from the API spec).
• That any UI that is created to present information from the API would need to follow existing accessibility specs.
• Likewise with UA features (we have a separate spec, UAAG, for UAs).

We would use the section mainly to provide pointers to others (such as WCAG and UAAG).

We'd be happy to work with you on writing such a section, if you'd like.

[anssiko]

@matatk those are some great insights, thanks! Your contributions are much welcome to help author the accessibility considerations section. To make it easy for you, please feel free to propose the text to be added here. The WG will then consider it as input for its spec PR and will also seek for your review on that PR to make sure we get all the details right, including pointers to relevant resources.

[matatk]

Thanks @anssiko, we'll do that; we discussed this again on our call today, and have some further examples we may want to include. We'll post again on this thread when we have an accessibility considerations section for your review.

[matatk]

@anssiko: We also wanted to ask if this is blocking a transition to CR? (We'll be working on this as quickly as we can, but if you're trying to move to CR, we'll prioritise it further.)

[anssiko]

@matatk thanks for checking. No, this review is not blocking CR. We want to give all horizontal groups ample time to review and contribute to this work before that transition would be timely.

As the next step we start a trial (Origin Trial, specifically) with early adopter web developers. We are not planning a CR transition right now.

If we get your a11y review feedback and contributions incorporated in the specification during the first half of this year we are in a good position to make changes also to the normative parts of the specification based on your feedback as needed. Thanks for working with us.

[anssiko]

@matatk I'd like to check whether we are on track to get your planned contributions to the accessibility considerations section within a month. We'd like to note a11y considerations as applicable in the documentation provided to web developers in the context of the Origin Trial of this feature.

[matatk]

@anssiko I'm really sorry for missing this! We have all been somewhat overrun with TPAC planning etc. and this slipped through the net. We are still working on an Accessibility Considerations draft section draft for you, and are very pleased that you intended to distribute it to developers! We are still in the throes of TPAC planning, but we will do our best to get you a draft as soon as we can.

[anssiko]

@matatk, we will be at TPAC with @kenchris so if you'd like to chat with us about accessibility considerations for the Compute Pressure API we could probably join your 12 September 2023, 09:30–18:30 Central European Summer Time meeting if you have availability.

[matatk]

@anssiko: It'd be great to meet you and @kenchris, and that's a good idea. We are still finalising our schedule, which will include a significant amount of general WG working time, within which this would fit quite well. I'll email you as soon as we have our Tuesday pinned down. The morning sessions will be the most likely ones for this.

[anssiko]

@matatk thanks for the great TPAC discussion. Let us know when you are ready to share the Accessibility Considerations contribution. A draft is fine, we’ll iterate on it, seek your review prior to integrating.

[matatk]

Hi @anssiko, I'm really sorry for the delay (again!); I moved both home and work shortly after TPAC, and it took a bit longer than I expected to get settled. Anyway, I am back now, and have a small update for you on this, with more to follow soon.

We (APA WG) are going to run a call for consensus on an internal draft we have; we'll start that tomorrow. I think the text covers most things you need (pending WG approval), but one thing we have not yet found is solid examples for devs to follow that are in W3C space. We may have to create those resources, and link to them in later versions.

I'll let you know as soon as our CfC has been run, and we have a result from it.

[matatk]

APA WG members approved the text we had - here it is in the rest of this comment. We do not have ready-made examples for developers to follow that are in W3C space, so that is an action on us to either find, or create, such examples. For now, we hope you will find the following useful. We also look forward to continuing to work with you and your group.

---

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.

[anssiko]

On behalf of the Devices and Sensors WG I'd like to say thank you to all APA WG members for this significant contribution.

@matatk I've staged a spec PR for your review: w3c/compute-pressure#247

[himorin]

@matatk thank all a11y colleagues on horizontal review. Is it fine to close this review request as completed, since a PR to add new accessibility considerations section has been merged?
@anssiko I believe anything else has been raised, but please kindly point if you have something else.