WestonThayer/spa-comment.txt Secret

## spa-comment.txt
I've been grappling with truism #1 from an accessibility perspective more and more lately. Most of the debate I've seen revolves around whether a SPA solution is more or less usable/ideal compared to its MPA equivalent, but after digging deeper, I consider them blocked. Two examples:

SPA navigation announcements seem to most commonly use ARIA live regions in an attempt to replicate the MPA UX (Next.js ships with it by default). But I don't think many are aware screen readers don't send live region events to refreshable braille displays (by design [1]). In an MPA nav, browsers fire a11y event types that we don't have access to in JS, and those *are* sent to braille displays by screen readers. The SPA live region technique blocks braille display users, while an MPA works fine, but the industry views it as a workable solution. Google Docs found a different technique, but requires users to self-identify, which is a pretty terrible privacy tradeoff [2]. I don't think there is an acceptable solution for SPAs here until https://github.com/WICG/navigation-api ships.

Keyboard focus a11y got a big boost from bf cache. Not only is focus on interactive/tabindex=-1 elements restored, but the SFNSP [3] is too, which means keyboarding an MPA is actually pretty nice now (it used to constantly restart you at the top of the document). Since SPAs can't use bf cache and there's no SFNSP API [4] (nor acceptable hacks to set it), they just can't compete. Maybe this isn't a 'blocker', but lord losing your focus position is frustrating, especially when it works on some sites but not others. (To be fair, MPAs aren't perfect [5] either).

For years I've had the attitude of the clever developer. I've been amazed by the 'have your cake & eat it too' techniques invented over the years in performance/reliability. But I worry that we're too quick to assume accessibility is the same way — JS can fix it if we try hard enough. JS doesn't have many raw a11y materials to work with. AOM is on ice due to privacy concerns [6]. ARIA can only fire 1 of the many UIA event types [7]. Many ARIA roles are unsupported on mobile [8].

I believe all these things can be fixed with platform support, but browser's a11y crank turns way slower than its others. Maybe raising awareness of how even the best SPA falls woefully short of an MPA when it comes to accessibility will help.

[1] https://github.com/nvaccess/nvda/issues/7756
[2] https://support.google.com/docs/answer/6057417
[3] https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-starting-point
[4] https://github.com/whatwg/html/issues/5326#issuecomment-1150090942
[5] https://github.com/whatwg/html/issues/7397
[6] https://github.com/w3ctag/design-principles/issues/293
[7] https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-events-overview
[8] https://github.com/w3c/aria-practices/issues/8
	I've been grappling with truism #1 from an accessibility perspective more and more lately. Most of the debate I've seen revolves around whether a SPA solution is more or less usable/ideal compared to its MPA equivalent, but after digging deeper, I consider them blocked. Two examples:

	SPA navigation announcements seem to most commonly use ARIA live regions in an attempt to replicate the MPA UX (Next.js ships with it by default). But I don't think many are aware screen readers don't send live region events to refreshable braille displays (by design [1]). In an MPA nav, browsers fire a11y event types that we don't have access to in JS, and those are sent to braille displays by screen readers. The SPA live region technique blocks braille display users, while an MPA works fine, but the industry views it as a workable solution. Google Docs found a different technique, but requires users to self-identify, which is a pretty terrible privacy tradeoff [2]. I don't think there is an acceptable solution for SPAs here until https://github.com/WICG/navigation-api ships.

	Keyboard focus a11y got a big boost from bf cache. Not only is focus on interactive/tabindex=-1 elements restored, but the SFNSP [3] is too, which means keyboarding an MPA is actually pretty nice now (it used to constantly restart you at the top of the document). Since SPAs can't use bf cache and there's no SFNSP API [4] (nor acceptable hacks to set it), they just can't compete. Maybe this isn't a 'blocker', but lord losing your focus position is frustrating, especially when it works on some sites but not others. (To be fair, MPAs aren't perfect [5] either).

	For years I've had the attitude of the clever developer. I've been amazed by the 'have your cake & eat it too' techniques invented over the years in performance/reliability. But I worry that we're too quick to assume accessibility is the same way — JS can fix it if we try hard enough. JS doesn't have many raw a11y materials to work with. AOM is on ice due to privacy concerns [6]. ARIA can only fire 1 of the many UIA event types [7]. Many ARIA roles are unsupported on mobile [8].

	I believe all these things can be fixed with platform support, but browser's a11y crank turns way slower than its others. Maybe raising awareness of how even the best SPA falls woefully short of an MPA when it comes to accessibility will help.

	[1] https://github.com/nvaccess/nvda/issues/7756
	[2] https://support.google.com/docs/answer/6057417
	[3] https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-starting-point
	[4] https://github.com/whatwg/html/issues/5326#issuecomment-1150090942
	[5] https://github.com/whatwg/html/issues/7397
	[6] https://github.com/w3ctag/design-principles/issues/293
	[7] https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/ui-automation-events-overview
	[8] https://github.com/w3c/aria-practices/issues/8