Community
Participate
Working Groups
Believe it or not, there is an accessibility design pattern for splitter. We should try to follow it, if it makes sense. https://www.w3.org/TR/wai-aria-practices-1.1/#windowsplitter
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html
Slightly newer wording of the accessible window splitter pattern: https://cdn.rawgit.com/w3c/aria-practices/master/aria-practices.html#windowsplitter The example isn't written yet, but will be soon. This is lower priority for now.
Car, I understand the pattern but it'll require that we be able to put focus on the splitter, put it in the tab order...I'll have to look at the dom structure to even make sure that the splitter has its own element.
We've decided to do this with a new command that iterates through the available tabs (rather than making the tabs themselves be directly tabbable).
GitHub Pull Request 60 created by [emoffatt] https://github.com/eclipse/orion.client/pull/60
I assume that: > iterates through the available tabs (rather than making the tabs themselves be directly tabbable). wanted to be: ==> iterates through the available splitters (rather than making the splitters themselves be directly tabbable). :)
I've pushed changes that implement the given approach. There's a new command (Command + Shift + '.' no a Mac) that moves the focus through each available splitter, allowing the user to manipulate it with the keyboard.
*** Bug 423333 has been marked as a duplicate of this bug. ***
