w3c / apa

APA WG deliverables have been moved to individual repositories
Other
47 stars 38 forks source link

What should we say about "screen sharing" in remote meetings? #260

Closed jasonjgw closed 2 years ago

jasonjgw commented 2 years ago

Several issues have been raised about "screen sharing" in remote meetings. This is problematic in that it is inherently inaccessible to non-visual users. As I understand it, the technique is implemented by transferring rasterized graphics data from the person who is sharing to other meeting participants. No accessibility API data are transferred. As rasterized images are used, the graphics are not vectors, hence not intrinsically scalable without reducing quality. What guidance should we give?

RealJoshue108 commented 2 years ago

We may need to separate the question of the act of 'screen sharing' from 'what is being shared' - as they are two separate things. But taking that this relates to 'what is being shared' - do the usual accessibility best practices not apply here?

jasonjgw commented 2 years ago

Activating the "sharing" is normally a straightforward user interface issue (e.g., selecting which window to share from a list and pressing a button in the simplest case).

As I understand it, what is being shared (under every implementation I am aware of) are real-time video data, and sometimes also audio data, comprising the entire screen or an individual window. So far as I know (and I may be wrong), the protocols used don't allow for accessibility API information to be transferred - it's simply a matter of "raw" (presumably compressed) video and audio.

The practical solution is to give meeting participants copies of the underlying files being presented, which are then as accessible as the file format and standard authoring practices used in their creation allow. Should we advise meeting participants to do both (i.e., use admittedly inaccessible screen sharing features and provide the underlying files)? What should we say about making screen sharing more accessible?

Are there strategies that meeting software developers can use so they aren't transmitting video and audio, but something more structured, even when presenting content dynamically?

sehollier commented 2 years ago

I agree in principle, but I'm also aware of products like this:

https://www.youtube.com/watch?v=36NgkpctW6k

So if I'm understanding it correctly, there's some sort of OCR that goes on depending on what type of content is being shared. This may change the guidance depending on what type of content is being shared.

Scott.

RealJoshue108 commented 2 years ago

The API issue is very interesting - I wonder if there is a need for a 'remote meetings API bridge' that supports interoperability and synchronization requirements for alternate content etc?

sehollier commented 2 years ago

As discussed in RQTF, since these 3rd party tools are not well developed, we may just want to close this issue