Exactly how can someone develop a client for blind and partially
sighted people while staying within your new rules? Or are they stuck
with using a screen reader on the Twitter web pages (which are
notoriously inaccessible)?

Because speech synthesis is slower than reading, it will be necessary
to remove some of the proprietary notices and marks, rather than
repeating them all the time, so breaking term 4B. And exporting to
datastore to drive speech synthesis might break 4A.

I am not sure what 5C means in practice, but it would be important to
reproduce all parts of the Twitter service that make sense when done
through sound and typing, not vision.

As most disability aids are distributed through charities or social
service programs, people are paid to distribute them and teach people
how to use them. That breaks 5B.

It is common to let disabled users store pre-written pieces of text
they can send at a keystroke (or mouth blow if they cannot type on
normal keyboards). That would break 5D.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Reply via email to