Skip to content

[ci skip] Fix rails' guides dropdown when navigating with browser back button #54934

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

Merged
merged 1 commit into from
Apr 17, 2025

Conversation

keegankb93
Copy link
Contributor

@keegankb93 keegankb93 commented Apr 17, 2025

  • Removes potentially unnecessary js from the code
  • Closes a div in the layout file

Motivation / Background

There is an issue with the guide index not opening after navigating through history. I've provided a video below of the issue.

Screen.Recording.2025-04-17.at.1.08.47.AM.1.mp4

This Pull Request has been created because the guides index was not working in this scenario.

Detail

This Pull Request changes

  • Removes setting and removing of attributes in the JS code

The main issue is that because we set the aria attributes based off of psuedo aria attributes i.e. data-aria-expanded and then remove the psuedo aria attributes we have no way to set the actual aria attributes that are referenced throughout the code when navigating through partial refreshes. From my understanding, hotwire is being used for the main content frames, but the guides index is in the layout so we'll never see that HTML refresh unless a full reload is requested. Therefore, once those attributes are removed we have no way to select the guides dropdown from that point on.

I removed setting and adding of the attributes because from my perspective I don't see it as necessary since the original data-aria attributes are being statically set in the index.html.erb file and then we set the attributes on DOMContentLoad/Turbo load event, which in this case is roughly doing the same thing.

My only assumption of why it was written that way is because you want it to act as a link to the index of the guides page, but also act as a dropdown. That isn't how it is working today, so there shouldn't be any regression in functionality. If we wanted that functionality, we may want to change how that is done. For accessibility, we'd probably want to keep it as a button and have the index/home page be listed along side the guides.

Screen.Recording.2025-04-17.at.12.55.07.AM.1.mp4

Alternatively if we don't want these changes, I'd suggest we just do something that checks if the aria attributes are present first and use those otherwise use the psuedo attributes. That may be the easier solution, but I'm wondering if this is working as intended in production.

- Removes *potentially* unnecessary js from the code
- Closes a div in the index file
@rails-bot rails-bot bot added the docs label Apr 17, 2025
@kamipo kamipo merged commit 76744c5 into rails:main Apr 17, 2025
3 checks passed
@brunoprietog
Copy link
Contributor

This breaks the accessibility of the menu. In my opinion we should revert it. These roles were carefully discussed in #51499. All the aria attributes and roles that are there have their reason for being.

@brunoprietog
Copy link
Contributor

Actually, the reason behind using the JavaScript code there was because we only wanted to set the roles when we have JavaScript enabled. If that's not a concern and we'll assume that will always be the case, it's probably fine.

@keegankb93
Copy link
Contributor Author

keegankb93 commented Apr 17, 2025

Actually, the reason behind using the JavaScript code there was because we only wanted to set the roles when we have JavaScript enabled. If that's not a concern and we'll assume that will always be the case, it's probably fine.

@brunoprietog --Right, that's what I had thought and was hoping to get some clarification on as it seems in the other PR referenced removing the JS was potentially the play as well. If we wanted to keep that functionality, I think what we'd need to do is probably reference the existing attributes if present i.e. if aria-controls and aria-expand are already set then we should not set them as I mentioned in my conclusion.

I'm happy to make that change, it might be the better compromise.

@keegankb93
Copy link
Contributor Author

keegankb93 commented Apr 17, 2025

@brunoprietog

keegankb93@931aaa1

Since it's a simple change I went ahead and made an update to it. I can make a PR if it is something you want to pursue. There shouldn't be a case, from what I can see, where the aria-attributes would not be present without at least the data-aria attributes being present to set them. Since the aria attributes will only be set when not present, we're assuming that 100% of the time aria attributes aren't there, the data attributes are. I'm not sure if it makes sense to implement sensible defaults as this should cover the basis.

@brunoprietog
Copy link
Contributor

Anyway, I don't see it broken in edgeguides. The only problem I see is that someone with JavaScript disabled would see the link as if it were a button. But still, the link takes you to the same page anyway. If we conclude that that's a very extreme case, I don't know if it's worth pursuing this further, really. I think the more I think about it the more I'm convinced of that. I don't know anyone who uses the browser without JavaScript enabled to be honest 😂. That probably should never have been a link and perhaps a details summary would have been more appropriate. That would always work without JS.

@keegankb93
Copy link
Contributor Author

Anyway, I don't see it broken in edgeguides. The only problem I see is that someone with JavaScript disabled would see the link as if it were a button. But still, the link takes you to the same page anyway. If we conclude that that's a very extreme case, I don't know if it's worth pursuing this further, really. I think the more I think about it the more I'm convinced of that. I don't know anyone who uses the browser without JavaScript enabled to be honest 😂. That probably should never have been a link and perhaps a details summary would have been more appropriate. That would always work without JS.

Fair enough! I was thinking the same thing--web developers are the primary audience using the site and if there are some javascript-free web developers out there, they know something that I don't 😂 .

Thank you for your quick responses and feedback, much appreciated!

kamipo added a commit that referenced this pull request Apr 18, 2025
[ci skip] Fix rails' guides dropdown when navigating with browser back button
@SleeplessByte
Copy link
Contributor

SleeplessByte commented Jun 12, 2025

👋🏽 I wrote that. @brunoprietog was right that making a link act like a button needs to be done in JavaScript so it works without JavaScript.

Moving it to HTML is... not great but okay. The problem is that you have now also broken it from being a dropdown. It's no longer announced as such. Sure, there is enough information in my screenreader to tell us what's going on, but this is not great.

The real fix is to revert the replacement on turbolinks before cache, or whatever the event is.

@keegankb93 your suggestion here: #54934 (comment) would also work, and if that's easier, do that!

Fair enough! I was thinking the same thing--web developers are the primary audience using the site and if there are some javascript-free web developers out there, they know something that I don't 😂 .

I have a few friend-developers that primarily browse the web using a text-based browser hooked up to text-to-speech and a braille display. @brunoprietog do you use a braille display too? Anyway, no JavaScript in that browser! And my gotttt it is soooo fast!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants