I am legally deafblind, which means I rely solely on braille output, no voice output from screenreaders. I also installed a NVDA plugin which does some helpful things like keeping the NVDA focus locked on the output window. I searched for the keyword accessibility in the MUSHClient forum, but only found a post from 2009. In that post my problem was already described - it would be handy if the output was navigateable by arrow keys. Also, that incoming input moves cursor to the bottom of the output window isn't ideal. The post didn't match all of my problems, though, nor did the following discussion solve them.
My specific issues:
As the MUD I'm playing is very fast-paced, it'd be ideal if I could navigate output with arrow keys. What I DEFINITELY need is that the focus stays locked on the line I selected, and doesn't jump to bottom of Window. At the same time, I need to be able to type commands (downside of many split window applications - can't type while staying locked on output window).
Did someone develop a plugin like that? Didn't find a matching one in the plugin list. Tried smoother scrolling and v!ry smooth scrolling, but these settings didn't seem to fix it.
Also I noticed that the help files aren't readable under NVDA. I can read it with Jaws, but sadly not with NVDA. Maybe my fault, because I'm not that familiar with all NVDA hotkeys. Does anyone know whether there's a way in NVDA?
I can’t answer that in detail just now, because I’m on holidays and do not have access to a PC.
The auto scrolling upon arrival of new output is, I think, a configurable option. Try pressing control+space.
That is a toggle, which is supposed to stop the automatic scrolling. That should make it possible for you to type commands in the command window, whilst reviewing the output in the output window at the same time.
The output should be navigable by the arrow keys, from memory again I think it is control+up and control+down arrow.
I am not familiar with NVDA however there is an existing plug-in that will let you access the help files from within the output window. It lets you type in “mchelp” followed by the word you want help on and the resulting part of the help file then appears in the output window where it can be read to you by a screen reader.
The "pause output" option (ctrl+space) freezes the screen, I think? So, the current screen content stays fixed. As soon as I type a new command, this state gets broken, though. I'd probably need a permanent version of this state.
Re control up/down, that visually scrolls through the output, doesn't move NVDA or Jaws focus, though. I suspect I'd have to talk to the developers of the screenreaders, though, unless there's a client side function to move screenreader focus?
Re helpfiles: thnks, that works. It'd be nice if I just could scroll through output without screen/window limitations, but ultimately I can do so with pageup/pagedown without problem, so that's OK.
Most important would be a permanent form of "pause output".
Regarding your first point , I thought there was an option to stop new output automatically causing the screen to scroll. Can’t confirm this just now, however..
As for scrolling the screen, your point about moving where Jaws will read out assumes that there is a focus which can be moved.
MUSHclient does not have a focus (line) in the output window, the closest you get to that is if you select text, and then that becomes the selected text..
Can you clarify what you are really trying to achieve here? Do you want to have certain lines from the output window re-spoken to you? Are you trying to slow down the delivery rate? Or skip certain blocks of text?
One possible thing you could do would be to log all of the output to a text file, and then use a suitable program to read from that, instead.
Another possible thing you could do, assuming you’re trying to review earlier text, would be to make a plug-in that, using some sort of command, speaks X number of lines back from the current output position.
As noted in the background section I'm legally deafblind so using screenreaders (and MUSHclient) much differently than most blind people do.
To be clear, I don't need speech at all (haven't even installed that plugin), but I'm using a braille display and the auto-scroll function when new text arrives messes with my ability to perceive text.
I'll keep looking for that option, perhaps I overlooked it so far. Another person told me it's there, just couldn't tell me where. So that'd definitely do.
My other problem is that the numbers of lines displayed per screen is rather low - so I need to press page up/page down a lot if a lot scroll is coming in. Is it possible to resize the output window so it contains more lines? I wouldn't want to trade the output window for something like a log file, because I can't type commands while reading the log file.
I'm sorry if all this is explained clumsily, I'm rather new to sharing my problems. Usually I just try to patch them up somehow, but seeing as how MUSHclient has so many inbuilt and plugin functions...
EDIT: Found a "disable pause on send" checkbox and unchecked. Pause still gets removed when I scroll with ctrl+down/up arrow/page up/down, though.
Yes, when I said “speaks X lines” I should have said “conveys X lines”.
You can certainly resize the output window, you hold as many lines as will fit into the current size of the screen, and you can make font smaller, to fit in more lines. I’m not sure how this will apply in your case.
How does the Braille display even interact with the output window?Effectively the window is just a graphic, although most the time the graphic is in the form of letters of the alphabet. Thinking about it, I am now guessing the braille reader recognises text on the screen rather than interacting with the underlying textual representation in the computer.
The screen reader plugin works by hooking into the code which simply sends into the plugin the stream of incoming text. This is unaffected by whether or not you scroll forwards or backwards or pause the display.
I’m pretty confident the autoscrolling can be disabled, if that is the easiest solution, however as I said I do not have access to my computer just now.
Okay, brief introduction on how screenreaders work.
A screenreader works by focusing a single object on the screen (this can be a textfield, a hyperlink, a button, even an image or a menu item) and speaking its attributes, if possible.
Attributes can be descriptions, tool tip texts, name, associated labels and the like. (So in the case of an image I might see butterfly.png, but not what exactly the image displays unless a text-based description was set).
This focusing can be done in 2 main ways: System focus/system caret - focuses on current object the edit cursor is on, or the system is focused at (that's the usual focus, and applies when I'm editing things in MUSHclient's menu, or input.
The second is more unusual and is the Jaws or NVDA focus. This one is *independent* from system focus and can be moved all over the screen (sometimes it can get tethered to the mouse, if people want to).
What we access by arrow key up/down is the system focus, so that doesn't affect the screenreader focus, but I can move that focus with keys on my braille display.
I guess this isn't important for the current problem, but hope it's interesting nonetheless.
And I'll keep searching for the setting :-)
JJTim, your explanation of how screenreaders works only explains how you interact with it, but doesn't explain how it actually knows what the text in the output window.
Can you describe the functioning of your braille display a little bit in the context of how it works with MUSHclient currently? Does it show one line of output at a time? Does it show an entire page?
Braille displays are devices which you can connect to your computer with USB/Bluetooth.
They display one line of the screenreader-focused object (if there is more than one line) in braille. (Each letter as dot combination).
A standard braille display only contains 40 characters, and only one line. There are 80 character displays, but they're twice as long as a normal screen.
Imagine someone put a hood over your screen so only one line remained visible. You could scroll manually, but add an auto-scroll function to this mix and a lot of scroll...
First things first...
My experience is that "Auto Pause" checked and "Un-Pause on send" not checked does what you want. You say that pause still gets removed when you scroll with ctrl+down/up arrow/page up/down, but my experience is that it only gets removed when you're at the very bottom. Are you saying that you want a way to not unpause even when the text is scrolled all the way down to the end? This should be relatively simple to do as long as you know that it will then necessarily require you to manually unpause always. Perhaps that's what you want, though?
Since you're here and letting us pick your brain about screen readers...
Ok, so what I don't understand yet is how it decides what line to display. MUSHclient gets some messages from the server and then displays them on the screen. Then what? The reason that text-to-speech players use special plugins to play is because MUSHclient doesn't directly interface with any screen readers and so we make plugins that send new lines to the speech engines. I've made one for Aardwolf that uses the Tolk library on the back-end which claims to handle both speech and braille output systems. But if you're not using a plugin, then why do other people need these plugins? And the scenario where anything in the scrollback buffer might also be read is something that I still don't yet understand, especially for players who do use such plugins that send incoming lines to their preferred output engine.
Heh, ah, that's why... I probably was at end of output file and pressed page down/ctrl+down. Which unpaused.
Hm, to be honest ideally I'd have more lines per page (I tried to do that with smaller font and the like, but it somehow didn't really work...) and disable the auto-scroll function - whether I manually unpause whenever I'm at end of output file, or manually pause is, ultimately, the same. Just will have to get used to pressing ctrl+space whenever it gets unpaused.
My MUD is pretty fast-paced, so not sure whether it'll work like this. we'll have to see.
*ponders* I'm not a screenreader developer. But I guess the way it works is that screenreader focus, once separated from sysstem or caret focus, moves to a certain line on the screen and stays on that line, sending my braille display the content of that line. That'd also explain why auto-scrolling is so annoying for me - because I don't focus a specific line, but a screen position and whichever line is currently at this position, you get what I mean?
Voice engines work very differently, though. They don't have a screenreader focus. They only read what's on system/caret focus or alternatively lines sent to the engine.
It’s still not totally clear to me the exact nature
of your problem. Is your primary intention just to read the text from
the MUD as it arrives? Or is it to go back and review earlier lines and
then return to where you were before you started doing the review?
It's... hard to explain when you can't see it for yourself...
So remember how I told you that I'm focusing a position on the screen? Well, that means if five new lines of text arrive, I don't stay focused on the line I just wanted to read, but on a five lines newer line.
Ehm, assume I read line 3 on the current screen (counting from bottom up). 5 new lines arrive - and I still am focused on the NOW 3rd line from the bottom up. But the line I wanted to read is now the 8th line on the screen, so I need to scroll up. In a fast-paced mud, however, lines quickly s croll off my screen and I need to use pageback to read them and when I have read them all... I'm dead.
Ideal would be if I could focus specific lines, like in text documents.
A solution has already been suggested: Add all output lines to a notepad document of MUSHclient's internal notepad. Problem here is that if I type, I don't type to the input window anymore.
Unless... the all typing goes to command window does this?
In that case I might need a function to add all stuff to a notepad and I'd be good. (and feel rather foolish for bugging y'all)
You point your braille reading device to a certain part of the screen which, in the absence of input from you, is fixed.
It renders what it sees in that part of the screen by raising bumps on the device which your fingers can then read. I presume you only use your eight fingers, and not your thumbs, so you would be able to read 8 characters at a time, and would have to move your fingers to read the whole 40 characters.
I’m guessing that your thumbs would be available to do other activities such as push a button to scroll.
Now, no doubt the annoying part is if the screen scrolls and the text being rendered changes before you have had a chance to read it.
It seems to me the same interface which is used by plug-ins to do text to speech would also be useful in this case. Those plug-ins use a special call back which is simply the incoming text from the output window which it then renders into speech, which it equally well render it into braille.
Ideally it seems to me such a plug-in would render 40 characters at a time, pausing at the end of a word and then wait for you to press a button to tell it to render the next 40 characters.
To speed up rendering, a new line could be rented as a special character, for example a slash, to speed up the output of text.
Does this sound like the sort of solution you are seeking?
Yes - this is pretty much my problem.
I only use 4 fingers (2 at each hand) but that's not that important as I'm, in theory, a very fast reader.
Also, my thumbs are actually pressing buttons to scroll, just as you visualized:
Thumb key 1: Scroll 40 characters back (or a line if braille display is at start of line).
Thumb key 2: Scroll 80 characters back (usually one line up)
Thumkb key 3: Move focus to system focus/caret.
Thumb key 4: Scroll 80 characters forward.
Thumb key 5: Scroll 40 characters forward, or one line down if braille display is at end of line.
The problem here is that if too much text comes in, I don't get a chance to read everything, and get caught up trying to scroll back - that's a bit like trying to walk up a conveyor belt that moves down - you move, but the movement in opposite direction renders your progress near zero, you get what I mean?
There are also 3 settings I can use: Braille display tethered to system focus/caret (I can only see what I type in MUSHclient), tethered to NVDA-focus (can only see output) or automatically tethered (see what I type, then shift to output upon enter).
What you suggest sounds great, but I'm not sure how to do that, tbh.
Okay, so your problem of needing to pause the output, and your other problem of wanting to review old text are really secondary problems caused by the primary problem of your not be able to read the text as quickly as it is arriving, or having a useful way of pausing it.
It seems to me that my proposed solution of having a method of delivering text to the Braille rendering device in a controlled fashion is what you need.
Can you give me the name, webpage, model number, or other information about it so that I might better be able to understand how to interface with it?
If the device can in fact simply read text off the screen, in the same way that it might read text off a book or a newspaper, then a fairly simple solution would be to make a miniwindow, which would have the purpose of delivering the output text to you in a controlled way.
The company developing my braille display is called Optelec.
My braille display itself is the ALVA 640 Comfort, Firmware 3.0.2, Bluetooth 1.20
More details here:
https://in.optelec.com/products/alva-640-comfort.html
I haven't used mini windows in MUSHclient yet, but I know blind people who have, so they should be able to help me with learning how to focus them.
Therefore it seems to me that the work is 90 percent done.
If you interface with JAWS and then install the JAWS plug-in into MUSHclient, then the text from the MUD will be sent to JAWS, it will be “spoken” and then your device will render it in sequence.
The only problem might be the rate of delivery, however JAWS already has the option to slow the speech down. You should conceivably be able to choose a speed that suits your reading rate.
Failing that, the plug-in could be modified to pause indefinitely until it receives a certain keystroke which could be generated by one of the buttons on the device.
In fact, from memory, the JAWS plug-in already has an option to pause the output.
I'll try this, of course.
However, please keep in mind that braille and speech are two entirely different things.
It's not like I see everything which gets spoken on my braille display. Likewise, not everything I read is spoken.
I'll get back to you after the testing.
I'm no expert...
Come to think about it, the interface for voice and braille should be rather similar, but there are also differences.
Hm, which JAWS plugin were you talking about? The sapi one on the plugin page?
It should be in the plugins folder of the download you would’ve got. I’m not absolutely certain that it’s compatible with Jaws, perhaps Fiendish could comment.
Not that plugin. That plugin sends directly to the Microsoft speech api instead of going through any screen reader's input interface. Essentially it bypasses the screen reader entirely and I have no idea what degree of first-party support Windows has baked in for braille displays.
Plugins that I know of for interfacing with JAWS and also NVDA are the mushReader plugin from https://www.allinaccess.com/mc/ or my own "Universal Text To Speech" plugin that I include in the Aardwolf MUSHclient package. Because I only really write plugins for Aardwolf, my plugin also depends on LuaJIT which I also include in the Aardwolf package in place of PUC-Rio Lua. But I can (and will) bundle it into its own portable package. Just know that I didn't write my own because of any known deficiency in mushReader except that I just found its code to be harder to read than necessary. So using mushReader should work fine.
But I suspect that these plugins won't solve the problem without some modification.
To recap the description of the thread so far...
The major difference as I understand it between braille output and speech output is that there's an insurmountable latency between when the braille display shows some text and when the fingers are able to finish reading it. This is because speech output doesn't interrupt itself before it finishes speaking a line, so the ears always get the chance to receive every spoken word, but the braille display will happily switch to showing a new line before your fingers have finished scanning to the end of the first line.
I'm not sure if using either of the above plugins will directly solve this, since the only solution I can think of is, as you suggest Nick, to slow down how quickly lines get pulled out of the screen reader's text buffer onto the display. And while you can slow down a speech rate, you can't really slow down a braille display rate because I imagine that it would always display instantly (since it can show the whole line all at once instead of vocalizing phonemes).
I think the plugins would need to be modified to add a second layer of buffering inside of the plugin and then a coroutine to gradually pull things off the buffer before sending them to be displayed with some delay between each line. That way the player could control the inter-line delay. None of the plugins I know currently does this. but it should be easy enough to add.
Nick, I should be able to look at the MUSHclient code tonight to rig up a toggle option for disabling the auto-unpause when scrolling hits the bottom. If I did, would you merge it? I'll also look at adding a line delay setting to the plugins.
JJTim, there's a new pre-release build of MUSHclient with the ability to disable the part of auto-pause that also automatically unpauses when scrolled to the end of the output.
And the next round.
First thanks SO MUCH for putting up with all of this. Without your help, I'd probably quit playing one of the more fast paced MUDs, because I couldn't hope to get all this working.
First, Fiendish, the function you made is very good, thanks. Sadly, a NVDA AddOn for MUSHclient that automatically fixed my screenreader focus to the output no longer works with the new exe file. I have no clue why, have already messaged NV Access AddOns about this - no response so far. So now I'm on Jaws. I could try to make such an AddOn for Jaws, but I'd need to learn the scripting language of Jaws first, so that takes time. In the meanwhile, I downloaded output_functions, a plugin, which pastes all output to a notepad. That's not perfect, but it would've sufficed for now. Sadly, when there's a lot of spam, the writing to the notepad completely disables the client for a few seconds. There's just so much in the quue, and the client is just busy with other stuff - I can't read during that time, type commands etc.
Do you think Lua-JIT would solve that? Or do you think there's some other method I could use?
My holiday is almost over, so I will be able to work on your issue in a few days.
My plan is something similar to what you describe, to send output to a notepad window. The notepad window has the disadvantage that the Windows control slows down the more text that is in it. You have already noticed this.
My plan is to output 40 characters to the window and then pause and wait for some input from you by pressing a key which you will be able to tie to one of your buttons.
Then the notepad window would be cleared, thus avoiding the issue of it slowing down, and then the next 40 characters would be displayed. This action will then continue indefinitely, allowing you to pace the rendering of the braille to the exact speed that you require.
Perhaps a second function key could be used to skip to end of line, in order to ignore something you already know, like a room description.
I know right?
It worked with MUSHclient 4.9.x and 5.0.5. I downloaded the exe file from GitHub, copied it into the MUSHclient folder, selected copy and replace, and the AddOn stopped working. I even ran the AddOn installer again, but nope.
Really weird.
I've made a plugin that should help, assuming you can focus your reader on the bottom of the output window.
It uses the plugin callback OnPluginScreendraw to find what is being displayed, and caches it inside the plugin.
Some room at the bottom of the output window is reserved, and a miniwindow created there for a single line of text.
The cached output is displayed at the bottom of the output window in chunks of 40 characters up to the end of the last word (the most-recent space). Press the "resume" function key to view the next 40 characters.
To skip the rest of the current line press the "skip" function key. The intention here is to allow you to skip an uninteresting line (eg. a chat line, or a line with a known description) and re-position at the start of the next line).
To discard all output press the "clear" function key. The intention here is to allow you to clear possibly hundreds of lines that might be cached while you were doing something else.
Default keys:
F6 - resume
F7 - skip rest of line
F8 - clear all output
If the display is blank then there is no pending output. Blank lines from the MUD are automatically ignored.
If the display is blank, and output arrives, then it automatically is shown.
To save and install the Braille_Reader plugin do this:
Nick Gammon, you are a genius!
This works quite well. It might have problems with extreme scroll, like when speed-walking, I'm not sure about that yet, though, as it's pretty late and I haven't run thorough tests yet. three things are certain, though.
1) You're extremely empathic. The keys you chose are ideal because it's a pretty natural posture to keep three fingers on f6-f8 while the other hand reads the content of the braille display. Not many people would be able to design a program like that with no real experience with braille displays.
2) Underlining the text in the miniwindow was smart. I immediately can tell regular window and special display apart.
3) I really owe you something. seriously. MUDs are a huge part of how I spend my free time and you just managed to help me with something that sometimes made me want to give MUDs up.
There mighj be room for improvements on the long run - I'll have to test it more. I'll also have to teach Jaws how to stay focused on the Output, or get the NVDA AddOn back to working again. But either way, you did great, fine-tuning my screenreaders is on me.
2) Underlining the text in the miniwindow was smart. I immediately can tell regular window and special display apart.
That's odd. It isn't actually underlined. That must be an artifact of the Braille reader.
I can imagine scope for improvements, after all it is hard for me to work out exactly what would be the best workflow for you.
You can configure the function keys in the plugin code, in a fairly obvious way. You might, for example, make the "clear output" be a bit harder to accidentally press.
There might also be call for some sort of recall of recent lines. For example, F9 might recall the most recently-displayed line. Or maybe pressing F9 repeatedly would recall the last line, second last line, etc.
I'm acting under the assumption that, once the issue of the text arriving too fast is solved, that your need to review earlier output might not be that great.
With a bit of luck the plugin might be useful for other people in the same, or similar, position to yourself.
