Hey !
So we got this keyboard navigation bug with flag on some browser.
Step to reproduce :
On firefox it's not a big issue, tabbing one more time put the focus back on the icon, but on browsers like Chromium, the focus is sent back to the beginning of the document, which is a big accessibility problem (stopping us from our AA accessibility grade, damn…).
So what I was thinking about was to add a Command after the operation, in Controller/ActionLinkController.php, somewhere like // Create a new JQuery Replace command to update the link display. in order to put the focus back on the element when the replace is over, with maybe a small delay or something else.
I'd really like to solve this issue, every feedback / advice is well appreciated.
Thanks !
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 2901287-5.patch | 993 bytes | idebr |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
andrewmacpherson commentedkeyboard focus is a tag we already use.
Comment #3
sylvainar commentedIt was actually easier than I thought. Anyway it solves our keyboard navigation problem.
Comment #5
idebr commentedReroll after #2834455: [Regression] Flag/unflag messages don't show for reload and confirm link types was committed.
Comment #6
ivnishComment #9
prem suthar commentedComment #10
ivnishComment #12
ivnishComment #14
ivnishI reverted this commit because of #3524123: Implementation of 2901287 causes issues when multiple instances of a flag are rendered on page
Comment #15
anybodyThanks @ivnish I can confirm this issue and just ran into this using the last stable release: #3553976: Flag Action Ajax Link "focus" command jumps to wrong flag, if there are multiple on the page (I'll close it as duplicate of #3524123: Implementation of 2901287 causes issues when multiple instances of a flag are rendered on page which I just found.
So this definitely should not be added, see my issue. I don't think the focus can work properly, as we never know which of the buttons were clicked.
Could you maybe tag a new stable release with the reverted code? Thank you!
I'd vote to close this won't fix or we need a quite complicated solution, that might not be worth it? Another alternative might be to solve the focus directly on the clicked element in JS?
Comment #16
deaom commentedI can confirm the issue and even add to it, as it's not just focus that's the issue. If you have multiple flags that are the same (like bookmark) added to the page, they all have the same id/selector that is added via the ajax command, meaning that the click gets lost as ajax command replaces the whole selector bit (click event is added to the a element inside flag div). So ajax does not have the information on which flag/link was actually clicked, so the text that is displayed after flag/unflag is displayed on the first flag.
When the focus part of the code is removed, the focus does not return to the selected a element, but when pressing the tab again it does jump to the right link. It was reported this only working correctly in firefox, but tested in Chrome and it works the same there as well.
If multiple flags added with the same selector is something that the module supports, this issue can be re-used for that as then the focus can be added via JS. I played around for a bit and it gets a little complicated for me with JS.
Comment #17
anybody@deaom thanks, you basically found out the same as I did in #3553976: Flag Action Ajax Link "focus" command jumps to wrong flag, if there are multiple on the page :D
So I think it's really important to have a stable release for now, publishing the revert. Afterwards this seems to be a quite complicated logical issue ;)
Comment #18
ivnish@anybody
I'm on vacation now, but a new release was created :)