[Standards] XEP-0301 Accessibility (resurrected)
markybox at gmail.com
Mon Jul 9 10:57:18 UTC 2012
Resuming the Accessibility discussions from last week, since Gunnar brought
We recall Kevin and Kurt's concerns, including Kurt saying:
> The argument I'm making here is that if the user says "I do not want
> to ever do RTT, I do not want to receive it, I do not want to be
> prompted to receive it" then they shouldn't receive it, they shouldn't
> be prompted to receive it, and people chatting to them shouldn't be
> misled into thinking they might be able to use it.
* Unfortunately, this is frequently /indistinguishable/ from actual user
'I want to do RTT and be notified about it, but my software only lets me
turn off RTT for everyone'
'My RTT is off because I dont know what RTT is and my software has it off
'I forgot to turn it on'
I have fixed the specification to satisfy Kurt and Kevin's concerns, and
Gregg Vanderheiden seems happy with it, as am I:
*"Enabling/disabling of discovery is SHOULD NOT be the default method of
activating/deactivating real-time text. See Activating and Deactivating
*In the absence of feature discovery, sender clients MAY send a single
blank <rtt/> element at the beginning of the session (or upon sender
attempting to initiate real-time text), as a method of indicating to the
recipient that real-time text is permitted until the end of the chat
session. Senders SHOULD NOT send any further <rtt/> until incoming <rtt/>
is received during the same chat session, or when support is confirmed via
Since I now claim the use of disco as the sole tool for this method, is
flawed from an Accessibility perspective, and nobody objected to my intent
to allow senders to signal a desire to begin real-time text According to
Activating/Deactivating Real-Time Text, sending a single <rtt
event='start'/> upon sender initation of real time text is suggested)
Given, XEP-0301 may be used in situations where is certain deaf people's
(like me) real-time conversational (sub-1-second latency), where text is
used conversationally, like telephone users use audio conversationally....
and we have accessibility legislators in both USA and Europe that are
interested in citing XEP-0301 (I even posted quotes from those emails two
weeks ago, and Peter Saint Andre has expedited his reviews as a result of
this, too.), and because I am deaf (cannot use the phone), I am defending
Accessibility aspects of this specification.
It has very important "Accessibility" advantages, for the modification that
*1. It satisfies Accessibility requirements by giving senders a chance to
(Rather than recipient blocking real-time text)
*2. It allows "Accessible" implementations from both a sender and/or
-- Sender can attempt to initiate an RTT call, by signalling.
-- Recipient can be informed of incoming RTT call attempts even if ignored
(because sender did send a signal)
*3. It satisfies Kurt and Kevin's concerns last week; implementations can
still choose to ignore (Section 6.2.1 Activation Methods)*
(That means any potential Accessibility blame is shifted to such
implementation that turns off disco to deactivate RTT; and the "accessible
implementations" have immunity from blame. There might be excellent
reasons (i.e. transcription bot services, DoS/security concerns, etc.).
However, it makes Accessibility responsibilities pretty plainly clear for
both senders/recipients, and it's easier to tell who's complying with
accessibility norms, and who's not complying with accessibility norms.
All satisfied now by the sender allowed ability to send a single <rtt
event='start'/> upon initation. (which uses less bandwidth than disco
anyway between the sender and the recipient)
And because sending a single <rtt event='start'/> is now allowed, the
disco (flawed for meeting accessibility needs) is downgraded from REQUIRED
Even if the <rtt event='start'/> signal is used, the disco is still useful
-- as a persistent "I'm accepting real-time text calls" announcement if the
software clients wish to support such a feature. (To easily list which
buddies support real-time text and freely stream multiple <rtt/> elements
right away to, without further confirmation.)
Ease of Real-Time Text:
....Also, a secondary reason of permitting <rtt/> be used as the alternate
method of determining support, is that it greatly simplifies
implementations in many situations. It allows implementations where
<rtt/> is completely inline. In one situation earlier this year, I have
wasted at least 8 hours trying to figure out how to properly add disco to a
fairly poorly documented XMPP library, that was otherwise able to function
well with <rtt/> extension. Although the blame is on the poor
documentation, it does lead to simpler implementations when trying to
rapidly create many implementations, and makes it easier to create
real-time text "plug-ins" since I only need to plug-in into the extension.
....Peter/Kevin did express last year it was not "xmpp-ish", but a majority
of people I correspond with, say Accessibility concerns is more important.
....XEP-0301 is slightly an outlier of a standard here, because it contains
lots of elements normally reserved for other layers. It essentially has
its own error detection and recovery, which is already proven necessary in
real-world testing (mentioned in past messages, and now encapsulated at
It's so self-contained that it's making better and better sense (due to
Accessibility, too), to put activation/deactivation capabilities inline
into it, irregardless of disco.
....Bandwidth concern was mentioned last year but sending a single <rtt/>
element actually uses less bandwidth than sending a disco iq. So the
bandwidth concern is essentially moot.
....Again, I also like the simplification that putting
activation/deactivation features inline into <rtt/> does, making "XEP-0301
plugins" much easier for many existing clients using their existing XMPP
I'd like to hear comments from other people about this "Accessible"
improvement to "Determining Support".
If there are anybody here who dislikes this, I'd like suggestions of
alternatives that still meets the 1-2-3 accessibility requirements
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards