Okay, so I just got done testing out Lost Pig in Parchment through Firefox and Chrome to basically compared notes with @Dannii, and I’m seeing identical behavior in Parchment.
From this, I’m guessing it’s a problem with the Firefox implementation on Android, and not with my web page?
The bug seems to be known, and reported here.
If I’m understanding this correctly, it seems to occur when role="status" on a div. I’m gonna spin up a few tests, and see what happens when I remove that attribute, in favor of the aria-live="polite" one, which will now stand alone.
According to this test, it seems that aria-live is pretty universal at this time, regarding support.
Removing role="status" from the div allows function to return to the live region, while using Firefox through TalkBack on Android. The only major catch, though, is live regions seem to force aria-atomic="true" functionality, where the entirety of the live region is re-announced, upon every addition.
So, my new idea here is to have a message buffer for a live region, which collects announcements. When announcements are meant to be dropped all at once, a lock is imposed on the buffer for 1 second, and the announcements are dumped into the live region.
While the lock is in place, any new incoming announcements are held in a backup buffer. When the lock lifts, this backup is checked. If the backup has items, then the current live region is cleared, the backup is transferred to the main buffer, and the process repeats.
If the backup is empty, then the live region is only cleared when the next announcement dump occurs.
Hopefully this will fix the issues I have with live regions on Android Firefox, and still maintain function on other platforms, browsers, and readers.
Huh, that bug could cause issues for Parchment. Would you mind doing a test for me? The combination of role: status and aria-live: polite would main occur for menus. So if you type “help” in Lost Pig then the status window will expand and set aria-live: polite. Does Firefox+TalkBack then not read out anything for the menu? If that’s the case then we can report it to bugzilla as having a real world example.
This doesn’t happen in Parchment for the main window, does it? I’ve never experienced that and no one has ever reported it to me.
Yup, I did run a test on Parchment, and the same problem occurs there as well!
I actually went straight there after finding this bug, because I figured Parchment nets a lot of IF traffic, and would probably be a good expected-behavior standard to compare against.
Nothing gets read from the main window at all, actually.
After starting the reader’s say-all routine, it will read the current text. From there, once I input a command, the results are not announced, and there is no audible indication that anything has happened at all.
Again, same behavior as my Octane engine, it seems. 
Now, this specific behavior…
…only happened for me after I removed role="status" from the live region, but since I think Parchment has both aria-live="polite" and role="status", then the bug I encountered when testing Parchment was the nothing-is-announced-at-all behavior.
This has fixed the problem. After removing role="status" and implementing this region-clearing-twin-buffer management system, the weird difference in behavior is gone, and Firefox on Android now announces updates correctly with TalkBack.
Oh dear. But I guess that means no one uses Firefox+TalkBack. The Parchment main window is role: log BTW.
Even if it did mistakenly set the main window to atomic, then it still shouldn’t read nothing - instead it should read everything after every turn! Something else must be wrong.
Ohhhhh, right, I do remember TalkBack calling out a log and not a status. My mistake, lol.
Mobile user survey suggests it’s likely larger than zero, and also shows that 66% of users fall in the span between “never” and “not very often” for submitting bug reports for accessibility issues, so it’s likely that problems have occurred, but users have not told you about them.
Also, sure, the number of Firefox+Talkback users is still small, but I personally make a fine point about always supporting Firefox on desktop and mobile when I make stuff, so that an alternative to Chromium is always available.
Just now double-checked this specific test case for ya. 
Nothing is read aloud. Also, I can’t seem to select other options in the help menu, either.
Just made an account there and posted about it!
Submitting bug reports is like the digital equivalent of picking up litter. Everyone knows they should, but most walk by and pretend they don’t notice it.
Did you know that the CSS properties of user-select and -webkit-user-select both break TalkBack scrolling, but apparently on Firefox mobile?
Also, apparently Firefox reads announcements in order of structure (which makes sense, right)? So if you add a div to a live region, the DOM sort order of its contents are the order in which the announcements are done.
On Chrome, a different order is used for the announcements, but I can’t tell what this ordering is. Which is also weird because Chrome and TalkBack are supposed to have better compatibility.
EDIT: Apparently reading in source order is standard, which is the behavior I’m seeing in Firefox. What is happening with Chrome…??
Desktop Firefox and Chrome both read with the correct order…?? It’s just Chrome for Android that reads in the wrong order…??
I’ve been reading along on this thread,. I don’t have a clue what the technical talk is all about.
Which makes me feel like I dived in the middle of an extra-quantomical episode of some new SF-romcom series, with weird SAX-tension going all around.
The really wild part is I’m basically developing multiple parallel versions of this and bug-fixing them on different platforms and screen readers, and once I identify a variant which functions identically on everything, then that will be the survivor.
Because each of these variants are perfectly-usable, and I would be confident in presenting any of these to a player, but I don’t have constant access to test systems, and a variant must pass with full marks before I mark it as a survivor.
Each variant has certain advantages and avoids different weird inconsistencies. I feel like I’m getting closer to the answer, at least.
If I run to hug someone in the pouring rain as a result of this process, then we’ll know for sure.
Wanna know a fun fact I just learned?
TalkBack with Google Chrome apparently truncates entire paragraphs from a screen reader’s awareness. You cannot select these paragraphs; you cannot read them; you can not scroll to them; you do not hear them in your say-all routine.
The paragraphs which get truncated are apparently random. I’ve refreshed this exact prototype web page multiple times, and different ones get dropped, and sometimes they all remain.
Apparently this is a known bug, and a lot of people have been submitting all kinds of bug reports about it.
What is up with TalkBack???
I’ve also been finding some neat workarounds and solutions. Hoping I can borrow an iPhone tomorrow for testing.
Another discovery!
If you have a sequence of text nodes in the same paragraph, they will each be processed separately.
So, let’s say you have a homebrew print() and println() method. If you chain a bunch of print() statements together, each one of those will be treated as an individual pronunciation item.
So I need to build a system that condenses these calls into a minimum number of text nodes.
This journey has been equal parts annoying and fascinating.
I’ve been very interested in how this works as well. I’m so glad you’re sharing your findings!
I feel kind of bad though because it’s like you’re the canary in the coalmine. I keep benefiting from your pain and suffering. 
I mean, if it causes an increase in assistive technology support for IF game engines and interpreters, on top of the development of my own engine, then that’s kind of a ten-birds-with-one-stone.
Without any modification, I can confirm that my engine works correctly on Windows with NVDA through Chrome! Have not tested Firefox on Windows with NVDA, but my experiences on Linux show that both desktop browsers seem to have completely identical accessibility interfaces; it’s just the Android versions of the browsers which differ so much.
Hopefully, once my dad is awake, I can ask to borrow his iPhone and test using VoiceOver!
