E-mail List Archives
Thread: What are the current best practices for accessible client-side routing?
Number of posts in this thread: 3 (In chronological order)
From: Nolan Darilek
Date: Tue, Nov 23 2021 7:06AM
Subject: What are the current best practices for accessible client-side routing?
No previous message | Next message →
Hey folks,
I'm a screen-reader-using software developer under contract to add
accessibility-related functionality to a hybrid server/client-side web
framework. I'm currently trying to make their routing more accessible,
and naturally want to do so to as many groups even though my own
disability makes doing some of that work myself impossible. It's one of
those frameworks that patches the DOM directly on route change, so it
doesn't benefit from the more traditional "one route, one page"
strategy. Broadly speaking, there seem to be two related issues:
1. Announcing the page change to screen readers (easy enough.)
2. Managing focus on page transitions effectively, possibly implementing
1) in the process (more challenging, especially for non-screen-reader
users.)
As a screen reader user, I typically just suck it up and deal with
whatever a given app does, and this is one area I've never done a deep
dive into fixing.
I'm also trying to do both so they're configurable on the framework
level (I.e. maybe you turn off 2 and just announce page titles, or
implement your own algorithm for finding a focus target for 2, or use 1
on some routes and a custom algorithm for 2 in certain situations... So
whatever solution I come up with won't necessarily be definitive, but it
may very well be the default for many users, and I'd like it to be a
good one.
Are there any comprehensive, modern resources on this? I found
https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/
which was a bit confusing--it seemed to lay out a couple different
focus-management strategies, imply that these caused challenges for some
groups but that doing something was better than nothing in that regard,
then later doubled back and advocated for an announcement-only strategy.
I could very well be misreading this--I've been deep in the trenches
relearning this particular framework so my brain is a bit overloaded.
Naturally I'll be advocating for more accessibility testing too, since
the goal is to open source and upstream both the work itself and blog
posts about the process. But I want them on the best foundation possible
before we do that testing, so if anyone has a favorite accessible
client-side routing strategy then please do share. :) Thanks!
From: Jonathan Avila
Date: Tue, Nov 23 2021 12:16PM
Subject: Re: What are the current best practices for accessible client-side routing?
← Previous message | Next message →
It's a fairly common pattern to move the user to the first heading or first unique content when changing context on user interaction such as pressing a button that changes the main portion of the screen in a single page application like Gmail.
For things like carousels that change less of the page more people seem to favor keeping focus on the button and announcing the change.
Jonathan
From: Peter Shikli
Date: Tue, Nov 23 2021 12:28PM
Subject: Re: What are the current best practices for accessible client-side routing?
← Previous message | No next message
Nolan,
This sounds like an interesting problem for our analysts. It pushes the envelope in a direction that I'd like them to be more experienced. If you have a few days to get answers, I would like to volunteer two of them to work the problem, a newbie teamed with a veteran. No charge as long as we could take 4 business days so as to get the best learning experience.
Let me know if you're interested and can provide specifics such as URLs directly to my email address below.
Cheers,
Peter Shikli
Access2online Inc.
29030 SW Town Center Loop East
Suite 202-187
Wilsonville, OR 97070
503-570-6831 - = EMAIL ADDRESS REMOVED =
Cell: 949-677-3705
FAX: 503-582-8337
www.access2online.com
Prison inmates helping the internet become accessible
----------------------------------------
From: = EMAIL ADDRESS REMOVED =
Sent: 11/23/21 11:00 AM
To: = EMAIL ADDRESS REMOVED =
Subject: WebAIM-Forum Digest, Vol 200, Issue 14
Send WebAIM-Forum mailing list submissions to
= EMAIL ADDRESS REMOVED =
To subscribe or unsubscribe via the World Wide Web, visit
https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
or, via email, send a message with subject or body 'help' to
= EMAIL ADDRESS REMOVED =
You can reach the person managing the list at
= EMAIL ADDRESS REMOVED =
When replying, please edit your Subject line so it is more specific
than "Re: Contents of WebAIM-Forum digest..."
Today's Topics:
1. What are the current best practices for accessible
client-side routing? (Nolan Darilek)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Nov 2021 08:06:16 -0600
From: Nolan Darilek < = EMAIL ADDRESS REMOVED = >
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] What are the current best practices for accessible
client-side routing?
Message-ID: < = EMAIL ADDRESS REMOVED = >
Content-Type: text/plain; charset=UTF-8; format=flowed
Hey folks,
I'm a screen-reader-using software developer under contract to add
accessibility-related functionality to a hybrid server/client-side web
framework. I'm currently trying to make their routing more accessible,
and naturally want to do so to as many groups even though my own
disability makes doing some of that work myself impossible. It's one of
those frameworks that patches the DOM directly on route change, so it
doesn't benefit from the more traditional "one route, one page"
strategy. Broadly speaking, there seem to be two related issues:
1. Announcing the page change to screen readers (easy enough.)
2. Managing focus on page transitions effectively, possibly implementing
1) in the process (more challenging, especially for non-screen-reader
users.)
As a screen reader user, I typically just suck it up and deal with
whatever a given app does, and this is one area I've never done a deep
dive into fixing.
I'm also trying to do both so they're configurable on the framework
level (I.e. maybe you turn off 2 and just announce page titles, or
implement your own algorithm for finding a focus target for 2, or use 1
on some routes and a custom algorithm for 2 in certain situations... So
whatever solution I come up with won't necessarily be definitive, but it
may very well be the default for many users, and I'd like it to be a
good one.
Are there any comprehensive, modern resources on this? I found
https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/
which was a bit confusing--it seemed to lay out a couple different
focus-management strategies, imply that these caused challenges for some
groups but that doing something was better than nothing in that regard,
then later doubled back and advocated for an announcement-only strategy.
I could very well be misreading this--I've been deep in the trenches
relearning this particular framework so my brain is a bit overloaded.
Naturally I'll be advocating for more accessibility testing too, since
the goal is to open source and upstream both the work itself and blog
posts about the process. But I want them on the best foundation possible
before we do that testing, so if anyone has a favorite accessible
client-side routing strategy then please do share. :) Thanks!
------------------------------
Subject: Digest Footer
------------------------------
End of WebAIM-Forum Digest, Vol 200, Issue 14
*********************************************