On Fri, Jun 29, 2012 at 6:01 PM, Mark Rejhon <[email protected]> wrote: > On Fri, Jun 29, 2012 at 12:54 PM, Kevin Smith <[email protected]> wrote: >> >> On Fri, Jun 29, 2012 at 5:49 PM, Mark Rejhon <[email protected]> wrote: >> > If vendors decide to implement video/audio *and* RTT in the same >> > software -- >> > then a main accessibility concern is vendors that enable audio/video >> > support >> > by default, but block the ability to initiate an RTT conversation (i.e. >> > non-compliance with Section 5 of XEP-0301). >> > ...That is, a situation of preventing senders from having any >> > opportunity to >> > initiate RTT, and preventing recipients from being able to be informed >> > that >> > an incoming RTT attempt is occuring. That is the one that becomes the >> > discriminatory issue. >> >> This seems like a bizarre situation to imagine happening - you're >> describing an application that implements RTT but doesn't allow its >> users to use it, as far as I can see. It seems unlikely that anyone >> would go to this effort. > > > You missed the message where a vendor told me they would put it in a Privacy > preference setting, and have it off by default. (while still enabling an > audio/video button by default) So this is a real issue! This > accessibility concern needs to be clarified.
Have /what/ off by default? I strongly support /sending/ RTT being disabled by default (although we're not in the business of telling people how to craft their UX). By default hiding that someone is sending you RTT is just strange. I don't understand why someone would do this. You're right that I missed the message where this happened - which thread was it in? Some context might help here. /K
