Opened 13 years ago
Closed 13 years ago
#21347 closed defect (bug) (fixed)
There is no way to tab out of the plugins and themes editors textareas
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Accessibility | Keywords: | |
Focuses: | Cc: |
Description
Currently we are inserting tab characters on pressing the Tab key in both file editors, even if Shift is pressed too. That breaks tabbing on these screens and leaves users stuck in the textarea.
Attachments (2)
Change History (15)
#2
follow-up:
↓ 3
@
13 years ago
If the action required to tab beyond the textarea is not a tab button then clear and visible text instructions should be included above the relevant fields.
#3
in reply to:
↑ 2
@
13 years ago
Replying to grahamarmfield:
It is still a tab keystroke, but to make it go beyond the textarea instead of typing a tab char, you need to press Esc first. That is described in the extended description of the textarea (added with aria-describedby
attribute). Will commit the patch so it would be easier to test.
#4
@
13 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In [21310]:
#5
follow-up:
↓ 6
@
13 years ago
Closed as fixed for now. If this behavior is not acceptable, feel free to reopen with other options.
#6
in reply to:
↑ 5
@
13 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Replying to azaozz:
Closed as fixed for now. If this behavior is not acceptable, feel free to reopen with other options.
Standard behaviour for a textarea when tab key is pressed is to move to the next item that can receive focus. I'm a little nervous about that behaviour being overridden. How about swapping the solution round to:
- Tab key pressed - moves out of textarea
- Esc + Tab - inserts a tab character
Also, using aria-describedby attribute is good for screen reader users, but where non-standard behaviour is present it's important that clear and visible instructions are provided for those who may be using a keyboard but not alongside a screen reader - eg some motor-impaired sighted people.
#7
follow-up:
↓ 8
@
13 years ago
Standard behaviour for a textarea when tab key is pressed is to move to the next item that can receive focus.
Standard behaviour for a "Code Editor" (Which the text area is in this case) is to insert a tab character for indention purposes, Shift+Tab would be to un-indent, so to remove the tab before the current position.
The Plugin/Theme editors being Code Editors rather than standard form elements makes me comfortable that the Esc key being added as an escape.. but that's just a Developers opinion, those that would be using the textarea, for the tab key to do anything other than inserting a tab makes muscle memory useless
#8
in reply to:
↑ 7
@
13 years ago
Replying to dd32:
Fair comment dd32.
It would still be useful to have some visual indication that Esc+Tab is required to move out of the code editor.
#9
@
13 years ago
It would still be useful to have some visual indication that Esc+Tab is required to move out of the code editor.
I don't disagree there, It's not going to be obvious when pressing Esc that anything has changed
#11
@
13 years ago
I would rather put this in help, at most. This kind of instruction has very little benefit taking up space on the page.
21347.patch adds checking of modifier keys when inserting a tab char in the file editors textareas, so Shift + Tab will work as expected. It also adds a key combination to be able to tab past the textarea: first press Esc, then press Tab. This behavior is described by aria-describedby elements for the textareas.