Current telnet clients work. Zmud may or may not, I don't think it does; mushclient is the main client used by blind players (well, there's vipmud, but that thing has a number of broken bits, costs money, and was written by someone who has evidently never played a mud).
Writing a client "that doesn't rely on screen readers" is not simple, but not impossible either; to do so, one must duplicate all functionality of a screen reader.
Obviously, there's a misconception about screen readers and standard windows programming practices. It's not the fault of the screen reader that there *aren't* standards. I did some looking--in the future, blind accessible clients can be made with aria live regions--but for now, meh, as that's still a draft.
It's like this. If there is a standard protocol, i.e. telnet, writing something that makes it blind accessible is, if not trivial, at least doable. Writing a client without using a screen reader requires rather a lot of work--I really think you should go look, for example, at how web browsing works through screen readers. You seem to think that screen readers should be able to understand human intent.
Dynamic content delivered through a web browser is only recently becoming popular enough to gain a standard. There are standards for web accessibility, but no one follows them. It's maybe the last year or so that something (wai-aria live regions) has been introduced that makes this possible, and like the rest of the internet it's going to be at least another five years before that gets adopted. Screen readers don't know that I'm playing a game; for all the screen reader knows, I'm working on a document in a word processor or something. If it monitored everything for updates and then did it's best, a number of things that shouldn't happen start happening in other places: reading dynamic ads over and over, reading the 4000 or so previous lines from the mud...
If a number of things happen, I'll embrace the change to web clients; as it stands, every mud has it's own client and it's own protocol. If someone standardizes the protocol and a significant number of muds agree to use it, writing a client specifically for the blind becomes an option. If not, well, it comes down to the mud authors; I know from past experience that most mud authors won't bother to make the required changes, and in most cases exposing telnet is easier. This is mostly through lack of skill and/or lack of understanding why the changes requested would actually be better for the blind, and then there's the argument of not enough gain. My best estimate is somewhere between 5 and 10 percent of the mudding world is blind, and that percent doesn't have anywhere else to go; world of warcraft is literally not an option. Even then, most inaccessible muds are still not willing to put forth the effort--minimal in many cases--to be accessible.
Before saying that screen readers are lame, etc, go try learning one, and come to understand the capabilities. It allows one to use a computer without a mouse and without a screen; to do so there's a whole bunch of capabilities in there. It doesn't simply read from top to bottom, and abandoning screen readers and writing a client that doesn't need one abandons a lot, and I do mean a lot, of functionality. Then your users have to learn a completely new interface: it's not like a mouse, where it's obvious what you have to do; to learn a program that is "self-voicing", one must memorize all the keystrokes beforehand.
The current limitation is this: screen readers can't automatically assume things are dynamic. If your application exposes the information properly, I can use it. But if it is in realtime, the screen reader doesn't know what to do. The real limitation is only with things that draw controls themselves instead of allowing the operating system to do it--in such cases, nothing can be done--but that's getting better as time advances.
The issue is not current mud clients. I know how to make a client accessible--I am blind and I do play muds, after all.
But, until something is done to prove to me that web-based json clients that do all this fancy stuff are accessible, I'm not going to embrace it. They can be, but no one has yet bothered to make an effort.
And here's the final issue. It takes years to learn a screen reader, and 99% of the training you can get doesn't teach you how to use a computer as a blind person. Instead, you're taught how to be a parrot: press these five keystrokes to open the e-mail client, press these 5 keystrokes to open word. The focus isn't on learning the computer as a sighted person does, it's on being able to work in the workplace. Most blind mudders are this type of player, nowadays, and half the time a friend set up the client. As a mouse-user with a screen, there's idiomes you learn in a basic computing class that aren't taught to blind people: why opening this program is the same as opening that program, etc. Having an accessible web client is only half the issue here: half the users barely know how to navigate the internet; for example, I made a worldmap that used an html table for lost souls, and so far I'm the only blind player who can use it, simply because no one else actually knows what a table represents, if you follow. Blind people aren't taught how the computer works, they're taught how to do common tasks so they can go make a living. The average blind computer user will have trouble making a word document.
And yes, I know and agree with the counter-argument to that last part, but it does need saying.
Go look on mudconnect. I just posted something a few days ago about aria live regions and the issues with using them to make an accessible client; I'm still hoping someone will reply and say they're willing to try, but meh...if you're curious about the issues, go look at that. I'll probably cross-post it at some point. As I said in my last post, I needed to go look to see if there was anything new, and aria live regions are. The problem is getting mud developers to label their web clients properly, make a change involving something called forms mode (which I need to figure out), and use aria live regions (intelligently, there's a few issues with the super-obvious approach).
