-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Title edit buttons aren't keyboard focusable #19769
Comments
Related is #7057 |
Confirmed. Thanks for reporting. Your suspicion was right: gitea/templates/repo/issue/view_title.tmpl Lines 17 to 18 in 8fee7c4
A fix should also look into Perhaps worth to split this issue into multiple. |
I wrote a PR that adds the bare minimum for now and will need some conversation to understand other accessibility regressions here better. Thank you for taking the time to report these. |
…ts (#22807) Replace #19922 , which is stale since my last review: #19922 (review) and #19922 (comment) Close #19769 Changes: 1. Use `<button>` instead of `<div>` for buttons 2. Prevent default event handler in `initGlobalButtonClickOnEnter` 3. Fix the incorrect call to `pullrequest_targetbranch_change` 4. Add a slight margin-left to the input element to make UI look better The logic in repo-issue.js is not ideal, but this PR isn't going to touch the logic. This is also an example for future developers to understand how to make buttons work properly. ### Before ![image](https://user-images.githubusercontent.com/2114189/217262515-ec0462f7-7051-46a5-bfa2-2f6c6a807b7d.png) ### After * Add a slight margin-left. * The `Cancel` button is focused. ![image](https://user-images.githubusercontent.com/2114189/217264891-934c9c8d-d190-4866-98b5-666cea57e28d.png) Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Description
When trying to edit an issue or PR title, or cancel/save said edit, the "buttons" (Edit/Cancel/Save) don't receive keyboard focus, so I can't tab to them to complete the action. For me personally this is more of an inconvenience issue (I prefer keyboard shortcuts for a lot of web interactions), but for others it's an accessibility barrier.
This seems to be because these "buttons" are really just divs with click and keypress events, but without
tabindex="0"
, which makes those keypress events rather useless. Though a more robust solution a11y-wise would be to simply make them real<button>
s.The scope of keyboard navigability issues might actually be much larger than this. For example, in the demo site, I'm also seeing things like:
Esc
doesn't work, as seen on other WYSIWYGs)tabindex="6"
if not others like that (generally bad practice a11y-wise to set values specifically if you have to use tabindex, as opposed to justtabindex="0"
which will just follow DOM order, unless maybe one is doing odd things with DOM order, but then maybe that's a whole other issue)But I figured I'd at least start of this/my first issue with a concrete limited-scope issue I genuinely came across today (dunno how Gitea might prefer to handle broader multi-part issues like started in my bulleted list).
Screenshots
Screen.Recording.2022-05-20.at.1.18.17.PM.mov
Gitea Version
1.15.0
Can you reproduce the bug on the Gitea demo site?
Yes
Operating System
Mac OS 12.3.1
Browser Version
Firefox 100.0
The text was updated successfully, but these errors were encountered: