Closed jasonjgw closed 2 years ago
Since braille support is provided by a screen reader in all current operating systems, having it in meeting software seems architecturally out of place and unlikely to be implemented. What is the desired functionality, and can it be provided elsewhere?
As we know there are issues with ARIA support for Braille output devices, I think it would be an interesting question to look at that in this context (of remote meeting software). Or is this more a platform level question?
It isn't clear to me why this is a "remote meeting" issue rather than a general UI accessibility issue; and the scenarios being considered for braille support in ARIA are really special cases (e.g., mathematical content that is processed by JavaScript tools such as MathJax) rather than issues that would occur in a general application such as a remote meeting system. So I think the question is: what's the issue here?
The issue as I understand it is that current remote meeting platforms don't have braille display support so I'm thinking this will be guidance in a developer section that API support for this is needed particularly around controls.
Since (as noted above) braille displays are under the exclusive control of a screen reader, a meeting platform can't address them directly. Is there something that screen readers should be doing? What are the user needs here?
@jasonjgw I ack this point but think this could be a good forum for initiating discussion on API support for Braille in the context of remote meetings.
@JaninaSajka made a comment today in Research Questions about the need to be able to 'pin' who is actively speaking to a consistent part of the Braille display. This is something that could be supported in our document as a use case.
Can see that there's bigger implications for Braille-specific APIs that extend beyond this document. Based on debate in RQTF, closing without addition.
This is an issue from the TPAC 2021 session. More detail would be helpful.