Description of the issue

• The check for reduced motion preference is implemented in a way to not respect the current setting
• We're now also doing the opposite, i.e. re-enabling animations even when they're already disabled
• Practically, this means that popstate visits are now always animated if this option is enabled

How to reproduce the issue

• Enabled respectReducedMotion
• Trigger a history visit
• It's animated

What did you expect? 🧐

I added the announcements option as described in the readme:

{
  announcements: {
    'en-US': {
      visit: 'Navigated to: {title}',
      url: 'New page at {url}'
    },
    'de-DE': {
      visit: 'Navigiert zu: {title}',
      url: 'Neue Seite unter {url}'
    },
    '*': {
      visit: '{title}',
      url: '{url}'
    }
  }
}

What actually happened? 😵‍💫

When I do that, typescript complains since it expects the default visit and url parameters to exist at the top level of the option, like this:

{
  announcements: {
    'en-US': {
      visit: 'Navigated to: {title}',
      url: 'New page at {url}'
    },
    'de-DE': {
      visit: 'Navigiert zu: {title}',
      url: 'Neue Seite unter {url}'
    },
    visit: '{title}',
    url: '{url}'
  }
}

The implementation looks like it should work as described in the documentation. So we should probably change the type of the option from this:

/** Translations of announcements, keyed by language. */
type AnnouncementTranslations = {
	[lang: string]: Announcements;
} & {
	[key in keyof Announcements]: string;
};

To this:

/** Translations of announcements, keyed by language. */
type AnnouncementTranslations = {
	[lang: string]: Announcements;
};

Also, this looks redundant to me:

const lang = document.documentElement.lang || '*';

// @ts-expect-error: indexing is messy
const templates: Announcements = announcements[lang] || announcements['*'] || announcements;

lang has already a fallback of *, so we should be able to get away with this, shouldn't we?

const lang = document.documentElement.lang || '*';

// @ts-expect-error: indexing is messy
const templates: Announcements = announcements[lang] || announcements;

Overall it looks like this could use some cleanup. Happy to take care of it after #44 has landed, to avoid merge conflicts.

Swup and plugin versions 📝

• @swup/a11y-plugin 4.5.0
• swup 4.6.1

What browsers are you seeing the problem on? 🧭

No response

Relevant log output 🤓

No response

URL to minimal reproduction 🔗

n/a

Checked all these? 📚

• I have read and searched the official docs
• I have checked discussions and existing issues for related problems
• I agree to follow this project's Code of Conduct
• I have provided all necessary information to the best of my knowledge

Describe the problem

• Currently, announcement templates are configured once
• Navigating to a page with a different lang will not change the language of announcements

Describe the proposed solutions

Tending towards option 1, or a combination of 1 and 2.

1. Allow keying the announcement templates by language: { en: 'Navigated to', de: 'Seite geladen' }
2. Create a hook content:announce to modify these on the fly
3. Read the announcement templates from the DOM: <meta name="swup-a11y-announce" content="Seite geladen">

Alternatives considered

• Hard-reloading on language change
• Possible, but not a great user experience by any means

How important is this feature to you?

• Nice to have
• Would make my life a lot easier
• I cannot use swup without it

Description of the issue

I just installed a11y-plugin in a fresh typescript project and got this error:

Could not find a declaration file for module '@swup/a11y-plugin'.

How to reproduce the issue

• Start a new ts project
• Install @swup/a11y-plugin

...seems like it's due to the missing toplevel "types" property. I thought it wasn't necessary anymore due to us providing it in the "exports" field anyways, but adding it made the error go away in VSCode.

Evaluate whether we should disable transitions for devices that request reduced motion:

• Pro: Conceptually, it's well within this plugin's core idea
• Con: Technically, this belongs in CSS
• Con: Turning off animations isn't reducing but removing motion completely
• Probably make this an optional feature turned off by default

Details

Revisiting the reduced motion media query

Example code

@media screen and
  (prefers-reduced-motion: reduce), 
  (update: slow) {
  .transition-fade {
    transition-duration: 0.001ms !important;
  }
}

Describe the problem

When using in-site app views that alter the URL but are being ignored by swup due to the use of resolveUrl, a11y plugin doesn't announce anything, since there is no swup visit happening.

Describe the proposed solution

It would be handy to be able to manually trigger announcements:

import SwupA11yPlugin from "@swup/a11y-plugin";
const swup = new Swup({
  plugins: [
    new SwupA11yPlugin(),
  ],
});

// sometime later:
createHistoryRecord(newUrl);
swup.say?.(`Navigated to filter ${currentFilterName}`);

How important is this feature to you?

• Nice to have

Describe the problem

• Some visits don't need to reset focus to the main element, e.g. fragment visits like filter UIs
• Ideally, the custom focus target could be overwritten per visit
• The fragment plugin and users can then just set visit.focus = '#list' or similar

Describe the proposed solution

• New key in visit object: visit.focus — or maybe nested/grouped somewhere?
• New hook content:focus that can be replaced

How important is this feature to you?

• Nice to have
• Would make my life a lot easier
• I cannot use swup without it

"SwupA11YPlugin" is writen with a capital Y in the code, but the example has a small y

const swup = new Swup({
plugins: [new SwupA11yPlugin()]
});

should be:

const swup = new Swup({
plugins: [new SwupA11YPlugin()]
});

or the code changed to have "SwupA11yPlugin"

Describe the problem

Intuitively, I would have thought that this CSS should hide any outline on the <main> element:

main:focus {
  outline: none;
}

But in the docs it recommends this approach:

main[tabindex="-1"] {
  outline: none;
}

In my tests, it works well with the simple :focus selector. Is there a reason for the [tabindex] form being chosen in the docs?

Describe the problem 🧐

Both swup and the scroll plugin don't explicitly move focus when a same-page anchor is clicked. Focus remains on the clicked link, which is not great for keyboard and screen reader users.

We've briefly discussed the topic on an issue about the :target pseudo-lement but I never followed up on checking our implementation.

Describe the propsed solution 😎

Move the focus navigation starting point to the targeted anchor. Browsers these days don't directly focus the target element but merely move the focus starting point so the next tab press will find the closest interactive element to focus. Technically, the document's active element will be body – the browser merely bookmarks a position for restarting focus navigation.

Some research or prior discussions:

• HTML spec: sequential focus navigation
• Working Group discussion: Programmatically setting focus navigation start point?
• Explanation on what the focus navigation starting point is
• Chrome updates on automatic management of the focus starting point

There's currently no way of manually setting the focus starting point without also focussing the element itself. There's a few workarounds, though, like the one below from a whatwg discussion on the topic. Given the amount of new code required for a "clean" implementation, I'd rather have this in the accessibility plugin than the core.

function setFocusStartPoint(element) {
  const tabindex = element.getAttribute('tabindex');

  element.setAttribute('tabindex', '-1');
  element.focus();
  element.blur();

  if (tabindex) {
    element.setAttribute('tabindex', tabindex);
  } else {
    element.removeAttribute('tabindex');
  }
}

Alternatives considered 🤔

We could get away with just calling .focus() from the core, but that tends to come with styling issues.

How important is this feature to you? 🧭

Would make my life a lot easier

Checked all these? 📚

• I have read and searched the official docs
• I have checked discussions and existing issues for related problems
• I agree to follow this project's Code of Conduct
• I have provided all necessary information to the best of my knowledge

What did you expect? 🧐

An undefined language should result in the announcement using the provided fallback.

What actually happened? 😵‍💫

No announcement is made if the language is not defined in the options. This started happening in 4.5.1, specifically after this pull request was merged. The part that seemed redundant was actually the relevant implementation of the fallback: announcements['*'].

I'll make a note to fix and test this in the test branch that's currently in progress, just flagging it here so we don't forget.

Swup and plugin versions 📝

• swup: *
• a11y plugin: 4.5.1

What browsers are you seeing the problem on? 🧭

No response

Relevant log output 🤓

No response

URL to minimal reproduction 🔗

https://github.com/swup/a11y-plugin/pull/46/files

Checked all these? 📚

• I have read and searched the official docs
• I have checked discussions and existing issues for related problems
• I agree to follow this project's Code of Conduct
• I have provided all necessary information to the best of my knowledge

Describe the problem 🧐

• Testing a11y with swup could be a easier if we had a standardized demo app

Describe the propsed solution 😎

• Create a demo site that can also serve as an interactive test suite

Prior art

• Ember A11y Demo App
• Testing A11y Demo App
• Deque University A11y Demo Sites

Checked all these? 📚

• I have read and searched the official docs
• I have checked discussions and existing issues for related problems
• I agree to follow this project's Code of Conduct
• I have provided all necessary information to the best of my knowledge