Open chrisjj opened 4 years ago
@chrisjj thanks for all feedback, generally we test keyboard accessibility, i think menu support was really overlooked because most of us rely on the command palette. We will fix it as the some point, or you can send a PR if it is super critical for you right now.
We could add check for keyboard accessibility explicitly in https://github.com/eclipse-theia/theia/blob/master/doc/pull-requests.md#review-checklist We could adopt some rules for keyboard testing from https://webaim.org/techniques/keyboard/ I won't enforce that we don't merge without it to allow different kind of contributions, but at least we should identify and track an issue if not by an author then by reviews.
We could add check for keyboard accessibility
I suggested specifically keyboard operability, because I think keyboard accessibility is probably out of reach for a project like Theia.
I won't enforce that we don't merge without it to allow different kind of contributions
Sad to hear. As I said, I think Theia really does need a policy that protects against further deterioration.
@akosyakov, why did you remove the proposal label?
@chrisjj proposal means whether we should consider doing it at all. If there is not such label it means that one can work on it.
Thanks. Note: that's not said on the description of the proposal label or any where else I could see.
Theia needs to be operable by keyboard if it is to meet objectives set out by Sven [here](https://www.eclipse.org/community/eclipse_newsletter/2020/january/3.php e.g. offer the best of the desktop IDE world and "minimize the onboarding time and learning curve for developers migrating to the new IDE". (Almost all other Windows IDEs are fully keyboard operable.)
Theia's keyboard operability is currently astonishingly poor e.g. none of the main menus are accessible by keyboard and ironically too key bindings cannot be created by keyboard. The fact this meets the low standards of major users such as Arm Mbed Studio (which, having also disabled the command palette, by default has no documented way of accessing New Program, New File etc. or any Help by keyboard) risks further deterioration through addition of non-keyboardable controls that will substantially disadvantage any attempts at rectification such as this.
I suggest project leadership declare that full keyboard operability is an inalienable objective and that patches adding functionality not keyboard accessible be disallowed.