svelte-navigator VS a11y-dialog

I went to the svelte-navigator github repo and they say that they support SSR. Now, if you use only ssr and not csr, that will reload the page on every navigation.That is because in ssr your front-end asks for entire page from server and doesn't just update components in front-end. For instance here they provide an example with ssr: https://github.com/mefechoel/svelte-navigator/tree/main/example/ssr

Well, depending on your project, you could try svelte-navigator.

But yeah, at the end of the day I guess the actual problem here is that the docs are more opinionated towards Sveltekit. I guess they're focusing on Sveltekit right now so I understand why they wouldn't want to maintain a whole separate project for the router like react, vue, etc right now. But maybe making the docs less opinionated and adding more examples for other use cases would be ideal. I ended up using svelte without sveltekit + this client router for svelte + golang and we are very happy with the results.

If it's a warning it should probably be role="alertdialog" rather than role="dialog". This will allow assistive devices to prioritize its content and trigger things like an alert sound. You probably also want to put keyboard focus on the least destructive action, which in your case would be the "save changes" button, rather than leaving keyboard focus above the close button. Here's a script by Kitty Giraudel that will do most of this for you, if you want.

On that note, TIL about screen reader issues related to dialogs in general, including this built-in. Seems like the question is primarily around how to update the focus target from the "invoking element" to the dialog's content in a reader-friendly way. There's a linked post from the MDN docs with more detail https://www.scottohara.me/blog/2019/03/05/open-dialog.html#i.... They actually still recommend a custom implementation that's considered more robust when used with screen readers: https://github.com/KittyGiraudel/a11y-dialog. I'm glad there's a callout on the MDN docs as I would have assumed this dialog element is screen reader clean. Focus management is always a tough thing regardless.