Woah boy! Help me throttle Inform 7

It must be a specific version or something else entirely, it works for me on Safari 16.3.

1 Like

I’ve re-read what I posted and it sounded harsh to me, too. Sorry, I didn’t mean to be :slight_smile:

I don’t know what happened. Probably is a client-related problem. Anyway, happy you found your solution. May be useful to let our mods know, in the feedback section of the forums, as it may affect others as well…

4 Likes

I’m gonna try this on my Mac when I’m back home, it’d be cool to have a reliable interpreter for that. I may have misunderstood, but isn’t it all cosmetic? Not meaning to argue semantics, but my understanding of why scrolling effects mess with my software is this:

In the simplest of cases, screen readers work out what to say by checking the whole screen when it updates. They then queue the appropriate text into a speech or Braille buffer, to be relayed to the user. If all of the text isn’t on the screen when the capture takes place, only the visible text at the time of capture will be buffered. Some screen readers are smart, and can try to buffer more if more appears, but unless there are specific instructions, they can’t tell the difference between text which has come in just now, and text which was already there and has moved. Even when it’s manually triggered by a command. So when you say it eliminates all problems of not being able to see what text is new, does that include the screen reader itself?

Like I said, I’m not intending to argue semantics, I’ve just never used an interpreter where this isn’t the first thing I’ve had to turn off.

1 Like

Right, I see the distinction you’re making that I’ve overlooked. These are good points.

I suppose the most important thing, then, is that if an interpreter offers scrolling, there’s an option there to it on or off. This would cater to everyone, screen reader or no.

-Wade

1 Like