Message log gets interrupted when using screen readers.

[DoctorBoomstick]

Describe the bug

Screen Reader Log Demonstrations.zip When using screen readers and bringing up the log with “P”, it seems like the log gets overlaid with the main game UI screen. The consequence of this is that elements of the main screen, E.G., pain, health, thirst etc. also get read out when trying to check the log. This creates a rather annoying muddle for screen reader users, as the log (a keenly useful element for VI players) is constantly being interspersed by these overlaid segments of information.

Steps to reproduce

1. Boot up a Linux machine (the only platform on which Cataclysm is currently playable) which has the curses version of CDDA installed. The install must be a post 0.E stable build.
2. Turn on the integral Orca screen reader, (I am unaware if other screen readers encounter the same issue) and load into a game.
3. Do any string of reported actions that your heart desires, and press “P” to bring up the log.
4. Sit back, and listen.

Expected behavior

It would be ideal if the log was read out as a solid, uninterrupted, string of text. This was the case back during 0.E stable, however later experimental versions brought the log to the current state of matters.

Screenshots

Consult the attached .ZIP file for packaged audio demonstrations of both the 0.E and 0.F sidebars.

Versions and configuration

OS: Ubuntu 18.04

• Game Version: f11519b, but any version post 0.E stable should present the same issues.
• Graphics version: Terminal
• Ingame language: english
• Mods loaded: irrelevant for this issue.

Additional context

No response

[GuardianDll]

I think we can link the audio itself, just for history blind_cdda.mp3.zip

[DoctorBoomstick]

@GuardianDll , I think linking a different audio file would be more appropriate, as I don’t spend much time (at least not enough to be representative) within the log in the file shared here. I can easily record a sample of audio from how the log reads out now, and how it used to read out in 0.E stable days, but it looks like you can’t upload raw audio files onto GitHub. Any idea how to get around this, cause having sample audio attached with this issue would help to better explain the problem?,

[anothersimulacrum]

In their case, it looks like they just renamed the file to change it's extension to .zip, which is sufficient to get around GH's file choosiness.

[NetSysFire]

I had luck uploading mp4 files without video, but this requires usage of ffmpeg, which can be pretty advanced and unwieldy

[DoctorBoomstick]

I’ve just packaged a .ZIP file with an audio demonstration for both the 0.E and 0.F logs with the initial comment. Hopefully, this should work.

[Qrox]

it seems like the log gets overlaid with the main game UI screen

What is your terminal size? From what I can see in the 0.E code, the messsage log UI has fixed size so it will also be overlaid with the main UI if the terminal size is larger than 80*24, so UI overlay is not likely the root cause.

One possibility is that after 0.E the ui_adaptor system was merged, which among other things flushes the screen buffer after drawing every UI instead of once each UI to reduce flickering, so if the screen reader tries to read the updated region of the screen, it now reads the entire terminal area instead.

[DoctorBoomstick]

late reply from my end, but regardless, @Qrox, my terminal size across both 0.F and 0.E was the default 80x24 scale. To be honest, I don’t really understand the technical side of how the game’s side bar UI works, and "ui_adaptor system was merged, which among other things flushes the screen buffer after drawing every UI instead of once each UI," Reads somewhat like Russian to my very ignorant self. Regardless, from what I can understand your diagnoses sounds more on the money than what I originally thought. My only issue now is if there’s any practical way of making the log as readable as it was back during 0.E, without screwing over our current implementation of the sidebar.

[Qrox]

Could you test in 0.E and 0.F with a terminal size larger than 80x24? That way we can know if this issue is caused by the size change of the message log UI or the new UI adaptor system.

[DoctorBoomstick]

Okay, just ran readability tests on both the 0.E and 0.F logs with terminal sizes of 130x50, and 200x80. When it came to 0.E, setting the game to a terminal size of 130x50 appeared to cause the same issue present in the modern 0.F log, I.E having elements of the sidebar interrupt the log messages when the former was being read by the screen reader. That being said, the reading of the log wasn’t quite as mangled as it is nowadays. Larger portions of the log, about two or two and a half sentences give or take, were being announced smoothly between each interruption. On the other hand, setting the terminal size to 200x80 removed the problem and returned the log to a completely readable state. There were no pauses, interruptions or any other negative factors observed. When it came to 0.F, increasing the terminal size to 130x50 increased the amount of log text announced by the screen reader before each interruption, allowing entire sentences to be read as apposed to two or three words. This state didn’t change when the terminal was upsized to 200x80. That being said, it appears that enlarging the terminal size in this way also caused issues with the readability of other elements of the UI. When €xamining, items in the inventory and the item pick up menu, the screen reader was announcing a large amount of ascii text to the point were those menus were very clunky and unpleasant to read through. All things considered, whilst upsizing the terminal in 0.F made the log minorly more readable, it negatively impacted the accessibility of the rest of the game.