E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: Brian Lovely
Date: Tue, Apr 16 2024 8:47AM
Subject: Meaningful Sequence in SPAs
No previous message | Next message →

I'm curious about focus order in single-page application-style websites,
where the base URL doesn't change, but the content of the previous page is
"blown away" and replaced by the content of the new page. Let's call them
pages A and B.

If on page A there is a control that causes page A to be replaced with page
B, then the currently focused element is removed from the DOM, along with
the rest of page A, when that control is activated. Screen reader users
will hear nothing, and if they try navigating "forward" they will be at
roughly the same distance from the top of page B as they were from the top
of page A (that's been my experience, anyway.) Navigating forward, they may
just encounter the footer, but no matter what they encounter it will be
confusing to be at some random point in the page B content.

My question is when changing views in a single-page application-style
website, how should focus be handled? I specify "website" to differentiate
from a single page application that is simply a series of form views.

From: Dean.Vasile@outlook.com
Date: Tue, Apr 16 2024 9:15AM
Subject: Re: Meaningful Sequence in SPAs
← Previous message | Next message →

When dealing with view changes in a single-page application (SPA) website, managing focus properly is crucial for accessibility and usability, especially for keyboard and screen reader users. Here are some best practices for handling focus when changing views in an SPA:Set Focus to New Content: When new content loads, especially after an interaction like clicking a link or a button that results in a view change, you should set the focus to an element within the new content. Typically, this should be a container element (like a <div> or <section>) that wraps the content of the new view. This element should have a tabindex="-1" attribute to make it programmatically focusable without adding it to the natural tab order.Use ARIA Roles and Labels: Apply appropriate ARIA roles and labels to the new content container. For example, assigning role="main" to the main content container can help screen reader users understand the role of the region they have navigated to. Using aria-live="polite" can also be useful to announce when new content is loaded, though this should be used carefully to avoid unnecessary verbosity.Restore Focus on Navigation Back: When users navigate back to a previously visited view (e.g., using the browser’s back button), it is important to restore the focus to the element they interacted with last within that view. This could be a link, button, or another interactive element. This restoration improves the user experience by providing a seamless navigation experience.Manage Focus on Modal Dialogs: If a new view opens as a modal dialog, focus should be set to the dialog container, and then managed within the modal elements. Ensure that the focus is trapped within the modal as long as it remains open. When the modal closes, return the focus to the initiating element in the main content.Announce Page Changes: For users who rely on screen readers, it's helpful to announce page changes. This can be accomplished through ARIA live regions, which can dynamically announce changes in content. However, make sure the announcements are not too verbose or frequent.Consistent Navigation: Maintain consistent navigation across different views. For instance, if your navigation bar is at the top of the page, keep it consistent across all views and ensure that focus can be moved to it from any part of the page.Testing and Validation: Regularly test your website using keyboard navigation and screen readers to ensure that focus management is working correctly across all views. This helps in identifying any areas where users might get stuck or lose context.By following these guidelines, you can enhance the accessibility and user experience of your SPA, making it navigable and understandable for all users, including those with disabilities.
Dean Vasile


617-799-1162

> On Apr 16, 2024, at 10:47 AM, Brian Lovely < = EMAIL ADDRESS REMOVED = > wrote:
>
>
> My question is when changing views in a single-page application-style
> website, how should focus be handled? I specify "website" to differentiate
> from a single page application that is simply a series of form views.

From: Brian Lovely
Date: Tue, Apr 16 2024 10:15AM
Subject: Re: Meaningful Sequence in SPAs
← Previous message | Next message →

In an old-school website with multiple .html pages, does the browser back
button restore focus, or does it simply navigate to the previous page same
as any link would?

On Tue, Apr 16, 2024 at 11:15 AM = EMAIL ADDRESS REMOVED = <
= EMAIL ADDRESS REMOVED = > wrote:

> Restore Focus on Navigation Back: When users navigate back to a previously
> visited view (e.g., using the browser’s back button), it is important to
> restore the focus to the element they interacted with last within that
> view. This could be a link, button, or another interactive element. This
> restoration improves the user experience by providing a seamless navigation
> experience.
> Dean Vasile
>
>
> 617-799-1162
>
> > On Apr 16, 2024, at 10:47 AM, Brian Lovely < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >
> > My question is when changing views in a single-page application-style
> > website, how should focus be handled? I specify "website" to
> differentiate
> > from a single page application that is simply a series of form views.
> > > > >

From: L Snider
Date: Tue, Apr 16 2024 10:46AM
Subject: Re: Meaningful Sequence in SPAs
← Previous message | Next message →

I will add to the previous comment. In my experience with PSAs, there
should be a way to go back, and go forward (or there should be)-usually
using a button not a link. Now people can argue button or link, but for me
this case would be a button in my view. So if they are switching, would
they not be switching with new headings? So heading 2 on page A is Contact
Information, and then Heading 2 on Page B is location preference, etc. Just
ensure that as the other commented said, that people can get back and forth
whether they are using a screen reader (and test with multiple kinds) or
voice control. I have been stuck in these things using voice, and it isnt
pretty when it happens.

Cheers

Lisa


On Tue, Apr 16, 2024 at 11:47 AM Brian Lovely < = EMAIL ADDRESS REMOVED = >
wrote:

> I'm curious about focus order in single-page application-style websites,
> where the base URL doesn't change, but the content of the previous page is
> "blown away" and replaced by the content of the new page. Let's call them
> pages A and B.
>
> If on page A there is a control that causes page A to be replaced with page
> B, then the currently focused element is removed from the DOM, along with
> the rest of page A, when that control is activated. Screen reader users
> will hear nothing, and if they try navigating "forward" they will be at
> roughly the same distance from the top of page B as they were from the top
> of page A (that's been my experience, anyway.) Navigating forward, they may
> just encounter the footer, but no matter what they encounter it will be
> confusing to be at some random point in the page B content.
>
> My question is when changing views in a single-page application-style
> website, how should focus be handled? I specify "website" to differentiate
> from a single page application that is simply a series of form views.
> > > > >

From: Dean.Vasile@outlook.com
Date: Tue, Apr 16 2024 10:58AM
Subject: Re: Meaningful Sequence in SPAs
← Previous message | Next message →

In an old-school website with multiple .html pages, when a user clicks the browser's back button, the behavior primarily involves navigating back to the previous page, similar to following a link to that page. However, the restoration of focus—the specific element that was last focused before navigating away—is not consistently handled across different browsers and can depend on several factors.Here’s how it generally works:Navigation: The back button primarily causes the browser to navigate to the previous URL in its history stack. This means that the browser loads the previously visited page either from cache or by making a new request to the server.Restoration of State: Most modern browsers attempt to save the state of the previous page including the scroll position and sometimes form inputs. However, whether focus is restored to the last focused element before navigating away is less consistently managed.Focus Behavior: The restoration of focus is not guaranteed and can behave differently across different browsers. In many cases, when navigating back:The focus might start at the beginning of the document rather than on the last focused element.Some browsers might maintain focus on the same element if the page is retrieved from the cache (bfcache or Back/Forward Cache, for instance), but this is not universally reliable.Standards and Practices: There isn't a strict standard requiring browsers to restore focus to the last focused element when navigating back. This behavior is largely up to the implementation by the browser developers, and can vary:Google Chrome: Typically does not restore focus to the last active element after navigating back.Mozilla Firefox: Similar to Chrome, it generally does not restore focus to the previously active element.Safari: Might exhibit slightly different behaviors, especially on iOS, but generally aligns with Chrome and Firefox in this respect.Therefore, if maintaining focus is crucial for your website's usability, especially across page navigations, it might be necessary to implement a custom solution. This can involve using JavaScript to remember the last focused element before the page unloads and then restoring that focus when the page is loaded again (assuming the page is revisited via the back button). This approach, however, requires careful programming to ensure compatibility and performance across different browsers and devices.
Dean Vasile


617-799-1162

> On Apr 16, 2024, at 12:15 PM, Brian Lovely < = EMAIL ADDRESS REMOVED = > wrote:
>
> In an old-school website with multiple .html pages, does the browser back
> button restore focus, or does it simply navigate to the previous page same
> as any link would?

From: Brian Lovely
Date: Tue, Apr 16 2024 12:48PM
Subject: Re: Meaningful Sequence in SPAs
← Previous message | Next message →

That's more or less what I thought. ...or "was afraid of" is more accurate.
If there was consistent back button behavior across browsers, then a single
page application could be coded to match that behavior.

On Tue, Apr 16, 2024 at 12:58 PM = EMAIL ADDRESS REMOVED = <
= EMAIL ADDRESS REMOVED = > wrote:

> In an old-school website with multiple .html pages, when a user clicks the
> browser's back button, the behavior primarily involves navigating back to
> the previous page, similar to following a link to that page. However, the
> restoration of focus—the specific element that was last focused before
> navigating away—is not consistently handled across different browsers and
> can depend on several factors.
>
> 617-799-1162
>
> > On Apr 16, 2024, at 12:15 PM, Brian Lovely < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> > In an old-school website with multiple .html pages, does the browser back
> > button restore focus, or does it simply navigate to the previous page
> same
> > as any link would?
> > > > >

From: Weston Thayer
Date: Tue, Apr 16 2024 1:07PM
Subject: Re: Meaningful Sequence in SPAs
← Previous message | No next message

Multi-page websites (I've seen those called multi page apps, MPAs) have
gotten much more consistent since https://web.dev/articles/bfcache gained
wide support. Bfcache creates consistent focus restoration because when
navigating forward, the departing page's state (including currently focused
element) is "frozen". When navigating back, the state is "unfrozen",
restoring focus and scroll position.

MPAs can break support for bfcache, see the article for what breaks it.

SPAs don't have access to bfcache, although they can technically match the
behavior. https://github.com/WICG/navigation-api has some platform APIs to
make this much easier, this issue discusses it
https://github.com/WICG/navigation-api/issues/190.

Also related, note that same-document/fragment navigation (like #anchor
links) does not use bfcache and has inconsistencies:
https://github.com/whatwg/html/issues/7397

On Tue, Apr 16, 2024 at 11:49 AM Brian Lovely < = EMAIL ADDRESS REMOVED = >
wrote:

> That's more or less what I thought. ...or "was afraid of" is more accurate.
> If there was consistent back button behavior across browsers, then a single
> page application could be coded to match that behavior.
>
> On Tue, Apr 16, 2024 at 12:58 PM = EMAIL ADDRESS REMOVED = <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > In an old-school website with multiple .html pages, when a user clicks
> the
> > browser's back button, the behavior primarily involves navigating back to
> > the previous page, similar to following a link to that page. However, the
> > restoration of focus—the specific element that was last focused before
> > navigating away—is not consistently handled across different browsers and
> > can depend on several factors.
> >
> > 617-799-1162
> >
> > > On Apr 16, 2024, at 12:15 PM, Brian Lovely < = EMAIL ADDRESS REMOVED = >
> > wrote:
> > >
> > > In an old-school website with multiple .html pages, does the browser
> back
> > > button restore focus, or does it simply navigate to the previous page
> > same
> > > as any link would?
> > > > > > > > > >
> > > > >