On Wed, Jun 27, 2012 at 9:48 AM, Kurt Zeilenga <[email protected]>wrote:
> > That is an excellent idea. An Accessibility XEP is useful in the > future, if someone wants to start it (I'd be happy to help). It should > contain at least a section about Total Conversion for the Europeans > (audio+video+RTT), > > I think the XEP should be careful to distinguish the accessibility issues > in XMPP as it currently specified I agree about this. Consider a situation where software advertises audio (XEP-0266), video (XEP-0299) but does not advertise RTT (XEP-0301) even though it's implemented. The Accessibility XEP would make this clear from the XMPP perspective. That's not 'accessible' from an accessibility perspective; it's discriminatory: In this situation, hearing people can successfully start initiating a real-time audio conversation. -- Sender listens immediately while speaker speaks, telephone-style. And deaf people are prevented from initiating a real-time text conversation. -- Recipient reads immediately while sender writes, "text-telephone" (TTY) style. It would be a bad accessibility practice to have a developer implement XEP-0301, but have it completely turned off (no advertising of support), whenever audio/video support is enabled. Generally speaking, as a software installation default setting -- it is recommended that advertising of XEP-0301 support is always enabled, even if RTT is turned off (i.e. <rtt/> is not sent by default) How is XMPP IM less accessible by having users take some action (like > pressing 'submit' or return) to send a message? And to the extent that > it's an accessibility issue, how is chat state notifications or other > extensions not a mitigation of any particular issue called out? > See above. I am curious... do you also consider traditional (text only) email to also > be accessibility issues for the deaf because there's some action required > there to send a message? if so, why? if not, why? > Email is not an accessibility issue. It's only an accessibility issue because there are real-time conversational methods of talking over XMPP (audio, video) but none existed for people like me until now (i.e. XEP-0301). Suddenly, we now have the potential discrimination issue of software permitting audio initations by default, but not being able to do RTT initations by default. This is the discriminatory situation we want to avoid. :-) *NOTE: It's a user interface concern for incoming RTT attempts. Software can be designed so that recipient software can prompt something similiar to an incoming audio/video connection -- for example "Incoming real-time text being initiated. Accept or Reject?" when the first incoming <rtt/> is detected. There are a lot of variants on this theme, but it is beyond the scope of XEP-0301. Eventually, we will gradually need a unified method of accept/reject for Total Conversation (simulation initation of XEP-0266, XEP-0299 and XEP-0301 for a Total Conversation session). This could potentially be covered in the future Accessibility XEP, or an Accessibility section added to appropriate XEP's.* Sincerely, Mark Rejhon
