Make svelte-announcer text configurable

[frederikhors]

Is your feature request related to a problem? Please describe.
I'm building for the first time my new app with svelte-kit and I found in my bundled app text like "Navigated to ...page name..." in a div with id: svelte-announcer.

There is no info in docs about this.

Describe the solution you'd like
Understanding what we are talking about. And just in case you don't agree how to disable this mechanism.

Additional context
If it is about accessibility it should be possible to disable it because most of my works for example are for company devices used by specific personnel who only want maximum speed (often the hardware is very poor!). They (almost) never need "help" for visual or hearing impairments. And if and when it is needed we will provide.

[benmccann]

Yes, it's for accessibility. Implemented in #311 and described in #307

What speed impact is there? Just a few extra bytes downloaded?

[frederikhors]

Is it possible to disable it?

For speed, I was referring to anything "superfluous" for a given job that slows down execution / rendering in the main thread.

[benmccann]

No, it's not currently possible. I don't know that it's worth adding an option for it either as it's not likely a measurable difference

[dummdidumm]

Rereading those, I think we should have an issue that tracks making this configurable. Right now the text is hardcoded, which is not ideal, especially if your site is not in english

[frederikhors]

@dummdidumm I agree 100%.

Please @benmccann can you reopen?

[dummdidumm]

Reposting from #307

For future consideration (haven't really thought this through): Could this be a component that can be imported via $app/a11y or something? People could then use it in their layout like this:

<script>
   import Announcer from "...";
</script>

<Announcer let:title>
   Hey, I've navigated to {title}
</Announcer>

[rmunn]

I think it's good that it's in there by default, rather than being off by default unless you import the component, because a lot of people will forget to import it. But the language and/or the text should definitely be configurable, to be able to adapt to the language spoken by the site's expected audience. And if a site's author can configure the text, then it's possible to set the text to "", which is equivalent to turning it off. So we might as well give authors the able to turn the div off entirely if they really want it to not be there. (For example, maybe they have a different method of announcing page navigation to screen readers that they think is better, and having the svelte-announcer div would harm accessibility by having two announcements instead of just one.)

[dummdidumm]

The component solution would provide more flexibility in my opinion - easier to add translations, different announcer based in routes, etc. It could be added to the starter template so people will not be able to forget it.

[Wolfr]

I looked into announcers a whole ago and researched the topic. It is great that this is considered and added to Svelte Kit by default. Good discussion in #307 .

Now it is added by default (which is great), but without making it translatable, it might be causing more harm than gain (making non-English speakers encounter an English message every page they enter).

[dummdidumm]

Thought about this some more, and I think a simple function might be enough here and also propagate better that the result can only be a string, in constrast to a Announcer component. Example: setNavigationAnnouncer((title) => 'Navigated to ' + title); . Logic would be:

• latest takes precedence (meaning you can put one in $layout.svelte, and variations in specific routes, if you want)
• cleaned up on destroy and reinstatiating the earlier navigation announcer
• if nothing is set, either set a default announcer (like it is now) or disable announcement

[raydaly]

Currently the div for svelte-announcer only appears in pages of folders in routes and not for the default (home) page in routes. This is inconsistent. The svelte-announcer div could appear in the home page with a aria-live: off. This would be more consistent.

Secondly, ideally the setting of aria-live would be dynamic. Regardless of which page a person first visits, the first page visited would be "off" and subsequent pages would be "assertive". For example if a Google search lead me to the About page, I'd probably want the content of $layout to be read. Then if I navigated "back" to the home page, I would not want the $layout read again. In that case I'd want aria-live: assertive. By adding the svelte-announcer to the home page, this behavior would be easier to add in the future without it being a breaking change to the HTML structure.

Or perhaps keeping track of first page versus subsequent pages is the responsibility of the screen reader. The off|polite|assertive options for aria-live are not sufficient and a new option is needed to handle subsequent pages.

I have very little experience with screen readers, so this could be way off.

[Rich-Harris]

Our plan for this is to remove the 'Navigated to' prefix and just use document.title. Later, when our i18n story is fleshed out, we can probably use whatever translation mechanism we settle on to make it customisable per-language