-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider defocussing the page after page change #87
Comments
Agree. As long as we allow for exceptions, like we do with scroll resets and |
Since accessibility is important to us, we have been doing some tests regarding this, making an example of how a regular HTML page reacts to a page changes as opposed to an SPA.
Now, what is the difference between this? The problem is that with the Svelte version, the user of a screen reader does not know that they are on a new page. There is no defocussing (Related #87), no jumping to top. Gatsby has recently come up with a solution for this. They solve this in two ways, one by adding a skip link, and one by announcing a new page using an aria live region. The skip link is a decision of the site author to add, we cannot enforce that from the router. The announcing of a page could be good, but I am not sure if screen reader users really appreciate that - this is something I want to investigate further. Gatbsy has a writeup on their recent solution here. It comes with its own localization problems. This is all fairly new territory; the blog posted is from 2 weeks ago. I will be consulting with a local accessiblity expert, and checking more things in depth. Special mention for Emily in our team for her investigation. |
It's quite clear how if you walk through a regular site, with focus styling on the nav elements, that it needs defocus. For those interested this is also a preview of what we're working on re: the website. |
I worked a bit on this issue. This in the script tag of the main
And this in the HTML:
Gives you a hint of what is focussed at the moment. Now, to defocus it on page change, that is the next step. There's is a helper |
No, but we should add one. I can write a defocuser, but how do we implement it in a scoped fashion? A lot of people, me included, use the URL for state handling and nested views. Imagine a page with two widgets. A ControlWidget and a ViewWidget. The ControlWidget controls what's going on in the ViewWidget and the ViewWidget's state is stored in the current address. In this case defocusing the ControlWidget on URL change might be an unwanted effect. One way to approach it would be to grab the active element, traverse through its ancestor elements and if no This would be similar to the scroll-lock attribute which works in the same manner. |
I noted in my research that Gatsby on their site does not defocus links when changing pages. I wonder if that is considered a bug or intended behavior. I asked the accessibility expert on their team on Twitter but chance might be slim to get an answer. |
If you can see well but you have a motor impairment (or you are just not a mouse user), and rely on keyboard nav the keyboard the persistence of focus is actually very helpful behavior to navigate the website. I.e. try to navigate Twitter.com using keyboard only: it is very well done. If you can't see and use a tool like Apple's Voiceover to read the screen, you encounter 2 behaviors;
I wonder how people with visual impairments figure out where they are if the behavior is not consistent. Now, visual impairment is a spectrum as well. So a lot of this is probably about user expectation. I should make a video of me navigating through a site with a screen reader to give you an idea of what I am talking about. |
Update, after some more reading, still convinced that initial problem is correct, with some added info: it would be best to focus the skip link (see info here). However, this focusses the skip link for everyone, which then causes a problem for people who do not use the keyboard (Vue.js demo at https://ns7t5.csb.app/ - try clicking to a new route). I find this permanence of an unknown UI element unacceptable for the users who do not need it. I would propose to simply start over again at the top of the body. The idea of the scoped solution sounds bery good @jakobrosenberg - just want to avoid once again to implement things few people will understand - but then we are back at the discussion we recently had with being able to opt out of behavior with flags vs simplicity of the engineering solution. The problem as well is that the skip link is a decision in userland. We can't ship a skip link with our router (well, we could techically do it if we provide a default template in Routify-starter) |
I did a google to see what solutions others had come up with.
https://hiddedevries.nl/en/blog/2018-07-19-accessible-page-titles-in-a-single-page-app
https://www.deque.com/blog/accessibility-tips-in-single-page-applications/ I wonder if it wouldn't be better to move focus to the new page/content rather than defocusing. |
By simply adding this code in, I had a working page announcer.
This depended on a variable with the page title being available. This might tie into your recent work with the meta things @jakobrosenberg . |
Well, there is a focus thing now, which should be available in the next release. It just occurred to me that decorators also could alleviate the whole focus situation. |
This should be fixed. If not, we'll reopen. |
Yess the defocussing is working on https://routify.dev/ :) |
We should consider defocussing the page on page change.
Otherwise a screen reader user has no idea that they are on a new page.
Reference: https://github.com/oaf-project/oaf-svelte-routing
The text was updated successfully, but these errors were encountered: