-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
guidance recommended for Braille support in remote meeting software. #257
Comments
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: