Section 2.8: REQ 10a and 15a: Seem UI-related, and not WebRTC-related.

[RealJoshue108]

[OP Jason White against branch https://github.com/w3c/apa/tree/RTCUserNeeds]

There’s an enormous difference between an incoming text string and an outgoing text string in terms of how each is processed, so the system can easily distinguish the two. It isn’t clear at all what is being sought here. Ensuring that the UI doesn’t intermix incoming and outgoing text would obviously be essential – but that’s true for all users, not just those with disabilities. Can you formulate the UI requirement more clearly?

[RealJoshue108]

REQ15a: This seems problematic. If the “end of message” signal is never sent or never received, then the user won’t receive the message at all – obviously problematic in an emergency or in other situations that one can imagine. As I recall, James Craig argued that this could all be handled with buffering and timeouts on the client side, using standard RTT. I tend to agree with him, and I think this should be rewritten as a UI issue.

[jasonjgw]

This was discussed at the 29 July 2020 RQTF meeting:
https://www.w3.org/2020/07/29-rqtf-minutes.html
in which it was clarified that emergency communications should use Real-Time Text (not an IRC-like style of interaction) to avoid the problem of unsent messages as noted here. It was agreed that the mechanism used in an IRC-style messaging scenario - end of line/end of message characters, buffering with a timeout, etc. - is an implementation question. The user need arises regardless of the implementation approach, and it is important to ensure the draft is clear on what the user need is, without recommending any particular implementation solution.

[RealJoshue108]

@jasonjgw I'm a little unsure of what needs to change here? The user need is pretty clear:

User Need 10: A deaf or deaf blind user needs to tell the difference between incoming text and outgoing text.

And it doesn't specify the implementation in the requirement- beyond suggesting that if using RTT, it needs to be used in conjunction with WebRTC. Does this not meet the requirement of a reasonably agnostic implementation?

[RealJoshue108]

I've added a new requirement to the 'Emergency calls: Support for Real-time text (RTT)' section

REQ 11b: Avoid the problem of unsent emergency messages. A user may not be aware when they have not successfully sent an emergency message. For example, RTT avoids this problem due to instantaneous data transfer but this may be an issue for other messaging platforms.

I think this helps highlight the issue of the user needing to be made aware of unsent messaged, but without specifying the implementation requirement explicitly.