Add swup-a11y-plugin #34
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
What is the expected behavior for focus on the first page load? When changing routes, I see that the plugin correctly focuses on the element specified by the focus option. However, on the first page load, it appears that |
|
Considering Swup is dedicated to page transitions handling, I don't believe it should impact the first page load. The vanilla behavior of focus being set to Then it seems reasonable that if you navigate to another page of the same site that you want to access the main content directly: the h1 |
The
VoiceOver already announces changes to document title. I have not been able to test with other screen readers such as JAWS and NVDA which require Windows (I need to clear up some disk space to install it). Looking at how this Swup plugin determines what to announce, prioritizing the Note that an important aspect of Web accessibility is declaring what is being made accessible. The plugin has no Accessibility Statement nor Accessibility Compliance Report to explain its assumptions and logic beyond its documentation. The plugin claims to be have been tested in VoiceOver, JAWS, and NVDA, but provides no results of these tests or explanations of what their behaviour is. |
| if (visit.a11y) { | ||
| visit.a11y.focus = 'h1#page-heading'; | ||
|
|
||
| // Best not to assume where to move the focus on fragment visits | ||
| if (visit.fragmentVisit) { | ||
| visit.a11y.focus = false; | ||
| } | ||
| } |
There was a problem hiding this comment.
I would discourage this for most standard pages.
The body should be the default focused element.
On pages that use modals/drawers, that container or its main heading should receive focus.
If you insist on keeping this, the logic should be collapsed into a single statement:
| if (visit.a11y) { | |
| visit.a11y.focus = 'h1#page-heading'; | |
| // Best not to assume where to move the focus on fragment visits | |
| if (visit.fragmentVisit) { | |
| visit.a11y.focus = false; | |
| } | |
| } | |
| // Best not to assume where to move the focus on fragment visits | |
| if (visit.a11y && !visit.fragmentVisit) { | |
| visit.a11y.focus = 'h1#page-heading'; | |
| } |
There was a problem hiding this comment.
Pages using modals/drawers are typically in a <dialog> which automatically focuses its first focusable element upon showModal() call.
The issue I see with other types of fragment visits (probably a single section inside the main of the page) resetting the focus to the body is it will require the user to travel again across the page to reach the updated content which could be irritating and potentially disorienting? But at the same time, it's how it would behave without an SPA system... so I'm not entirely sold on that
Also, I posted a comment asking for your advice regarding this bit of code but I didn't notice Github left it as "pending" which prevented you from seeing it.. my bad! It brings some explanations to my thought process there
There was a problem hiding this comment.
Stick to Web standards and its default, established, behaviours.
If a project's stakeholders can afford to hire accessibility consultants and dedicate time to testing with real users, then the behaviour can be adjusted to accommodate their expectations.
| document.documentElement.classList.add(Transitions.TRANSITION_CLASS); | ||
| document.documentElement.classList.remove(Transitions.READY_CLASS); | ||
|
|
||
| if (visit.a11y) { | ||
| visit.a11y.focus = 'h1#page-heading'; |
There was a problem hiding this comment.
visit.a11y.focus = 'h1#page-heading';I'd like to have @mcaskill input on this.
I noticed by testing VoiceOver that a page change would either:
- stay on the focused element (if it's out of
#swupcontainer) - move the focus to the body, but as if we reached the end of the document (moving VoiceOver's cursor forward wouldn't do anything and moving it backwards would read the end of the footer)
Considering those observations, specifying the focus target on the page heading seems pertinent! But it seems to prevent Swup's aria-live announcements to happen as a side effect... Not sure if that's a real issue though as the plugin announces Navigated to {title} by default (title value being decided as such).
We're basically only losing the Navigated to bit, but that bit increases clarity about what's happening.
Could you please try the navigation behavior with/without this line and give your recommendation?
There was a problem hiding this comment.
So, Swup is the one at fault for the recent issue I noticed across some projects where the page does not scroll back to the top after clicking a hyperlink in the footer.
Swup created a problem and instead of fixing it introduces a non-standard solution.
But it seems to prevent Swup's
aria-liveannouncements to happen as a side effect... Not sure if that's a real issue though as the plugin announcesNavigated to {title}by default […]
If its announcing Navigated to {title} that means its aria-live element is working as intended. It's extracting the text node from the first <h1> which happens to be the target of your visit.a11y.focus.
Since the <h1> can't be guaranteed to have a relevant title, maybe the plugin's headingSelector could target <title> instead.
There was a problem hiding this comment.
If its announcing
Navigated to {title}that means itsaria-liveelement is working as intended. It's extracting the text node from the first<h1>which happens to be the target of yourvisit.a11y.focus.
Indeed. What I'm saying is that this doesn't happen anymore if I specify a focus target with visit.a11y.focus = 'h1#page-heading';. Seems like the element being focused steals the VoiceOver attention to the detriment of the aria-live element.
So, Swup is the one at fault for the recent issue I noticed across some projects where the page does not scroll back to the top after clicking a hyperlink in the footer.
Can you send me an example of a project where you noticed this on Slack? It's not necessarily related
There was a problem hiding this comment.
In regards to visit.a11y.focus, that makes sense that it's stealing focus. Not necessarily the intended behavior. I noticed that Swup's documentation site still uses v4 whose behaviour is to focus the first h1.
Description and Context
Add @swup/a11y-plugin by default to improve... a11y!
Notable improvements:
aria-live="assertive"focusselector to determine targeted element on page changes (defaults tobody)Note
It seems though that
content:announce&content:focusmay conflict with each other. See my comment below regarding specificfocussettingType of Change: