More robust accessibility checks

Is your feature request related to a problem? Please describe.
Svelte's current accessibility checks, while useful, are limited. They only perform a static analysis of single components in isolation. For example, here are some significant a11y issues that Svelte currently can't detect:

• low color contrast
• heading levels, e.g. no <h1> or skipping from <h2> to <h4>
• proper HTML structure, e.g. <li> must be a direct child of <ul> or <ol>
• issues with dynamically rendered content via the {@html} directive
• document only contains one <main> element

These are all tricky issues to detect with the current compiler-centric checks, since they depend on how components are used or rendered into the final application. It would be difficult or even impossible to detect looking at a single component. For example, if a component contains an <h3>, how would you know that in all cases where the component is used, it comes after an <h2> or another <h3>? How do you know what color the text and background will eventually be so you can verify that the contrast is sufficient? These issues would be much easier to detect at runtime, when the app has been rendered.

Describe the solution you'd like
SvelteKit should integrate runtime accessibility checks into the default template. These would analyze the page in the browser and report any a11y issues to the console when running in dev mode. Ideally, it could continually monitor and re-run checks when the page changes, e.g. when navigating to a new page or opening a menu. These checks could be configurable by the user, but enabled by default.

If possible, we should take advantage of existing tooling like Deque's axe so that we don't have to re-implement these checks. Building a framework is complicated enough without having to implement and maintain dozens of a11y checks.

See also packages like axe-core/react and agnostic-axe, which detect UI changes and re-run a11y checks on the new state of the UI.

Describe alternatives you've considered
There could be a way to run these checks at build time -- in the recent Svelte Summit Q&A, Rich Harris mentioned the possibility of programmatically navigating the application and reporting a11y errors.

SvelteKit could also do nothing here, and rely on users to check these a11y issues on their own.

How important is this feature to you?
Lacking this feature won't block me or anyone else from using SvelteKit. If people want to, they can already run these extended a11y checks through other methods. However, I think having this feature would show that Svelte cares about a11y and help educate more developers about a11y.

Additional context
I see this as a natural extension of https://github.com/sveltejs/svelte/issues/374.

We can help educate developers about a11y and make a strong statement about the kind of web we want to be a part of — I think we should.

Start by reviewing SvelteKit's default template and the browser runtime behavior described in the issue, then compare the integration approaches used by axe-core/react and agnostic-axe. The work would be complete when development-mode pages report runtime accessibility issues, re-run after relevant page changes, and provide a user configuration path.