Description
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:
- Tab/keyboard trapping in the editor (or at least
Escdoesn't work, as seen on other WYSIWYGs) - A button-ish div with
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) - Focus sometimes getting completely lost/misdirected when tabbing through the right sidebar (harder for me to characterize, but maybe happens when tabbing "too fast"?)
- I think the file-upload feature also isn't reachable.
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