Thanks.
It’s truly awful. But thanks. I guess to @mother’s point, very few web applications work quite like IF, so no one is really considering them.
Web can be so dumb sometimes.
1 Like
so is pushState routing and the ability to access pages irrespective of ordering, and i’m sure some screen readers listen for URL changes as well. but a single-page app can still change the URL, and, more critically, there’s very few situations in which the page renders a lot more content without that having been the result of an element clearly and semantically connected to the new content. if you click “more posts” on twitter, you get more posts below that. if you click “About Us” on an SPA with internal routing, you get most of a new page. but none of those involve content which doesn’t exist at load and can barely even be prerendered, much less hinted, being added as a portion of the page, above the interaction element.
despite a million new web APIs, and a million standards, there’s still no obvious or easy answer. that leads me to pretty strongly conclude it’s because we’re more or less outside best practices by design here. same goes for resetting the screen reader caret – that’s usually something which happens predictably with live regions, or as a result of something which both looks and acts like a page navigation. can we do well enough? sure, of course. but i’m not sure the result of that is necessarily ideal or highly marketable to people who want a first-class screen reading experience. certainly i think we can do better either through practice or convention.
(i’ve struggled even with basic questions like “how polite should i be for a chapter title which for sighted users whizzes across the screen, and will likely disappear before the reader navigation?” should it be an alert? should there be an option to disable all timers and insert continue buttons instead? i have no idea!)
1 Like