The British and German governments have updated their advice for travellers seeking to enter the U.S. with fresh warnings about the risk of arrest or detention. A French scientist was denied entry to the US, because of text messages on their phone containing a 'personal opinion' about the #Trump administration. Veronica Cardenas, former assistant chief counsel at the US Department of Homeland Security says #deportations are eroding public trust.
#US #travel #immigration
youtube.com/watch?v=yt3He2DTD5…
Former ICE lawyer says deportations are eroding public trust • FRANCE 24 English
Officials in Paris are expressing their dismay after a French scientist was denied entry to the US, because of text messages on their phone containing a 'per...YouTube



James Scholes
in reply to Nolan Darilek • • •No. The closest thing to an automatic solution to that is probably tracking scroll position, and you may or may not be able to make that more granular by making the text quite big (I haven't tried). But even then, the best you're gonna be able to achieve is to track the closest element and put focus back there to restore the position, without character-level accuracy.
I know that Mozilla and NV Access have done some work to allow selection of text within the NVDA browse mode buffer to be communicated to the browser for on-page actions that require a selection. But:
1. That doesn't work across browsers; and
2. your use case seems targeted at reading, not selecting.
Nolan Darilek
in reply to James Scholes • • •Thanks, that's what I was thinking. And just to check an assumption, setting the scroll position won't update the screen reader's position in the doc--I'd have to use focus shenanigans for that?
For context, this is my attempt at a document reader that saves/restores position when the document is closed/reopened. I don't think I need character accuracy, or even paragraph accuracy, if I can open books or longer documents to roughly where the reader closed out.
FWIW I'm not just being lazy and asking, I'm trying right now and it isn't working, which I suspected it wouldn't. It's also possible I'm using my web framework wrong or that something is behaving silly under Linux.
Thanks again!
Matt Campbell
in reply to Nolan Darilek • • •Nolan Darilek
in reply to Matt Campbell • • •Quin
in reply to Matt Campbell • • •James Scholes
in reply to Nolan Darilek • • •That's mostly correct.
There are some instances in which a webpage can move the scroll position without explicitly setting focus to the target element, and have the screen reader's reading position follow. But that can be less reliable, particularly if the target element is visually obscured, and setting focus is a more explicit/guaranteed way to do it.
Note that if you're setting focus to things like headings and paragraphs that aren't focusable by default, you'll need to dynamically inject a `tabindex="-1"` for the best results.
Nolan Darilek
in reply to James Scholes • • •