Accessibility of FTelnet and canvas about ftelnet HOT 18 OPEN

Extracting the text from the canvas can be done by hooking some of the Crt functions. For example I've hooked into the ClrScr and Write methods, and am outputting the printable characters to a textarea on this new Demo page:

https://www.ftelnet.ca/demos/accessible-demo/

Does that help at all? I tried installing NVDA since it's free, and it does read out the contents of the textarea when I move my mouse around it. But then I find I'm unable to type in fTelnet, and I'm guessing that's because NVDA doesn't see any elements focused so it thinks I'm trying to hit shortcut keys, and not type text. So I wasn't able to test beyond my login screen.

from ftelnet.

from ftelnet.

from ftelnet.

Your latest message didn't contain a link. But I did a bit of googling, and swapped out the textarea element for a div element with aria-live="assertive" set, and now NVDA reads out the incoming text.

I also hooked the Connect function to try setting role="application" on the body element, but it seems like adding that dynamically via javascript doesn't work as I still need to manually enter application mode. But at least now I know there's a keyboard shortcut for that, so thanks! I'll take another look at setting application mode via javascript in the morning.

And just to be clear, hooking the various functions is just a quick and dirty way to see what works. Once things are working properly, I'll update fTelnet itself to natively support detecting and supporting screen readers.

from ftelnet.

from ftelnet.

Hey Noel,

I've been playing around with this a bit more, and it looks like I can set the Canvas element to use aria-live="true" and update its innerText when new text is written to the canvas. This has the benefit of not needing an extra div, which means it should be safe to enable by default (users without a screen reader running won't notice any difference).

I also have it auto-entering application mode on connect, and then exiting on disconnect. I'm doing this via an extra element. On connect I focus it, and then on disconnect I blur it. Any idea if this is the best way to go, or if there are other ways to enable application mode programmatically? I tried updating the body tag to have role="application" on connect, but that change didn't seem to be recognized by the screen reader so it stayed in browse mode.

These latest changes are only in my local copy of fTelnet for now, so unfortunately nothing new for you to test yet.

from ftelnet.

Just updated the demo page here:
https://www.ftelnet.ca/demos/accessible-demo/

As I mentioned in the last message, this uses the canvas element as an aria-live="assertive" element for the screen reader (is "assertive" or "polite" the better option? And is there value in allowing the sysop to choose which to use?)

It also includes a textbox with role="application" that gets focused and blurred on connect and disconnect, so the screen reader should automatically enter and exit application mode when needed.

Please let me know how it works for you, especially with JAWS since I only have NVDA to test with here.

Thanks,
Rick

from ftelnet.

from ftelnet.

Hey Noel,

I've switched from assertive to polite. I've also tweaked how the text is added to the canvas live region -- originally it was setting the innerText of the canvas, so yeah hitting a key would overwrite the innerText with the same text as before but with your new keypress added to the end, and then seeing the text changed must make the screen reader start over (even though 99% of the text is the same)

Now it appends child divs to the canvas element, so the behaviour I'm seeing is that if NVDA gets halfway through reading the screen when I hit a key, it stops reading and only announces the new keypress I just made, then stops talking. Is that the desired behaviour?

I can switch to a div if needed, I was just hoping to keep things backwards compatible so screen reading could be on by default. As far as I know any standard method used to hide a div visually will also hide it from a screen reader, so non-standard methods like position: absolute; left: -9999px; top: -9999px to position it outside the viewable area of the screen would need to be used, but I'm not 100% sure whether that's safe or if it may mess up the display for some users.

Thanks,
Rick

from ftelnet.

from ftelnet.

from ftelnet.

from ftelnet.

For the keyboard trap, what's happening is I added a textbox with the role set to application, and then on connect the textbox is focused to enter application mode, and on disconnect it is blurred to exit application mode. It didn't occur to me that the keyboard shortcut to exit application mode wouldn't work while the textbox is focused, so that's not good!

I can definitely add a keyboard shortcut to exit application mode, but then users will need to know what the shortcut is, and so maybe another option would be to not add the textbox, and not auto-enter application mode? Then users could use their screen reader's shortcut keys to enter/exit application mode as needed.

from ftelnet.

from ftelnet.

I haven't had much luck with the describedby setup, it seems to be very hit and miss for me. So sometimes it works and reads the message about needing to enter application mode to interact with the terminal, but other times it seems to completely ignore it.

I wonder if maybe when the client connects it could add the text to an aria-live region set to assertive, so that text would be read first. I'll try that next and see how it goes.

from ftelnet.

from ftelnet.

Hey Rick, Any luck with this lately? I know you've been pretty busy lately with other things. Once we get this dialed in, can it be included in Synchronet directly so that it will be easier to integrate?

from ftelnet.

Sorry, this completely fell off my radar. Looks like on Dec 15 I made a couple changes, and if I recall correctly they seemed to work OK.

The first change was to remove the keyboard trap, to allow users to enter application mode on demand, and not have it forced on without a way to exit.

The second change was to switch from setting the canvas's innerText value, which if I recall correctly caused the screen reader to start over again at the beginning when new text was received, to adding child divs when new text is received.

These changes are probably still not perfect, but I'm going to merge them into the master branch and update the embed wizard anyway, because it should make things easier to test that way.

from ftelnet.