search

w3c / a11y-request

Horizontal review requests will be made via issues in this repo.
9 stars 2 forks source link

Compute Pressure API 2023-02-07 #53

Open anssiko opened 1 year ago

anssiko commented 1 year ago

Other comments:

Thank you for your review and comments!

ruoxiran commented 1 year ago

@fredrika11y will look this issue.

ruoxiran commented 1 year ago

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

anssiko commented 1 year ago

@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 https://github.com/w3c/compute-pressure/issues/183 we believe there are no accessibility considerations that should be documented in this specification.

matatk commented 1 year ago

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:

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 10 months ago

@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 commented 9 months ago

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 commented 8 months ago

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:

anssiko commented 8 months ago

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: https://github.com/w3c/compute-pressure/pull/247