On Jun 27, 2012, at 12:25 AM, Mark Rejhon 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 (in the base specifications and as extended by current XEPS) from how XMPP could be used to improve the lifes of persons with disabilities. We should be careful not to conflate the two. I am really curious as what accessibility issues folks think XMPP IM and presence, as described the 6121, especially those inherit in the base protocol... and then discuss how these issues can be mitigated. > coverage of ITU-T F.700 and F.703, the best-practices of always making RTT > available on a best-effort basis, other Accessibility-related XEP's, > applicability to other segments such as the blind, etc. > > As for an Accessibility section to XEP-0301, that could be a good idea too. > Some material is already in the spec already, which could transferred to that > section instead. Also mentioning the recommendation that clients that don't > want to do RTT by default (i.e. mainstream clients), it is STRONGLY > RECOMMENDED to advertise RTT support, To support this, I think you need to specifically state exactly what accessibility issue in XMPP IM is RTT actually mitigating AND why RTT is better mitigation than other possible mitigations. And it needs to be a clear and definite and significant (*) accessibility issue, as in something that is precluding deaf persons from using XMPP IM. The less clear and definite and severe the issue, the weaker the case for STRONGLY RECOMMENDED or even RECOMMENDED. > and should still be receptive to incoming RTT (Even if it has to prompt a > confirmation to recipient upon first incoming <rtt/>, much like confirming an > incoming audio/video connection), in order to remain 'accessible'. 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? 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? -- Kurt
