Selecting ranges of text should not require use of a mouse. Currently, not only can you not select ranges of text in a webpage with the keyboard, but once you've selected text with the mouse, you can't even adjust the selection with the keyboard using shift plus arrow keys. This is a serious usability obstacle for people who have mobility disabilities or who are blind and using VoiceOver: http://www.mail-archive.com/discuss@macvisionaries.com/msg19301.html
<rdar://problem/5710317>
r33520 added some limited caret browsing support. Mozilla's implementation allows the caret to blink and allows navigation when the caret is in a hyperlink and enter is pressed, which the commit doesn't do. We also need to be able to enable this feature with a per-WebView granularity, since caret browsing isn't useful in many contexts where a WebView might be embedded, but is generally helpful only when browsing read-only document content. There are quite a few places in WebCore where caret selection modification and caret blinking is hard-coded to test for contenteditable, so implementing this feature fully will require a handful of modifications around Frame and SelectionController. A global gAccessibilityEnhancedUserInterfaceEnabled export doesn't make much sense since you rarely want all WebViews in an application to allow for this kind of selection -- I'd recommend that it's removed in favour of a new WebSettings entry. Is anyone working on this or should we go ahead and develop this feature?
(In reply to comment #2) > A global gAccessibilityEnhancedUserInterfaceEnabled export doesn't make much > sense since you rarely want all WebViews in an application to allow for this > kind of selection -- I'd recommend that it's removed in favour of a new > WebSettings entry. It's worth also noting that it should be possible to turn this on and off dynamically (WebSettings is handy for this). This kind of accessible selection handling is bizarre to some users, and after trying it, they may wish to disable it without restarting the browser application. (You can see caret browsing in the Firefox browser by hitting F7 if not familiar with it.) One improvement over that implementation may be to desaturate or otherwise modify the caret marker's rendering to indicate whether the selection point is actually editable or not.
I believe that having a specialised EventHandler::handleKeyboardSelectionMovement() for this isn't the way to go. The code here currently doesn't support Ctrl, for example, to move selections at word granularity. It would be more consistent to reuse the existing SelectionController logic used for editable content. A colleague has suggested that it might be easier to implement this by enabling content editing and disallowing modifications, and then fixing any bad interactions from there. Chris, could you describe some of the thinking behind the way r33520 is implemented? It may be that you're following a Mac convention for non-editable selection modification which I'm not familar with. Are the limitations intentional or are they missing because the feature is WIP?
Making Webkit respond to text selection in non-editable web views for many scenarios went far beyond my prerogative. I am not in the kind of position to make those decisions, so I made this change as limited as possible, in a way that would only affect VoiceOver users on the Mac. If you want to extend this further, then I think that should be done. BTW, the option key does word granularity, like it does on the Mac.
(In reply to comment #5) > Making Webkit respond to text selection in non-editable web views for many > scenarios went far beyond my prerogative. I am not in the kind of position to > make those decisions, so I made this change as limited as possible, in a way > that would only affect VoiceOver users on the Mac. If you want to extend this > further, then I think that should be done. BTW, the option key does word > granularity, like it does on the Mac. > Thanks for the reply Chris. Could you at least eliminate the modality of the setting and make it a WebSetting/WebPreference? We (Nuanti) are willing to support development of this important accessibility feature as part of the accessibility work in WebKit but I'm not comfortable reviewing changes that modify your globally exported functions since you may be using them internally in Apple products, and I don't want to develop the feature separately since it's just a logical improvement of the feature you already added which can be shared across all WebKit ports and platforms.
Hello, I suggest at this point filing a new bug that explicitly states what you would like this feature to do. i don't think anything will happen within the context of this bug. please spell out how you intend to use the feature and how you envision it working. hopefully, then it will get some attention from the rest of the webkit team (since this seems like it is not purely an accessibility issue) (In reply to comment #6) > (In reply to comment #5) > > Making Webkit respond to text selection in non-editable web views for many > > scenarios went far beyond my prerogative. I am not in the kind of position to > > make those decisions, so I made this change as limited as possible, in a way > > that would only affect VoiceOver users on the Mac. If you want to extend this > > further, then I think that should be done. BTW, the option key does word > > granularity, like it does on the Mac. > > > > Thanks for the reply Chris. Could you at least eliminate the modality of the > setting and make it a WebSetting/WebPreference? We (Nuanti) are willing to > support development of this important accessibility feature as part of the > accessibility work in WebKit but I'm not comfortable reviewing changes that > modify your globally exported functions since you may be using them internally > in Apple products, and I don't want to develop the feature separately since > it's just a logical improvement of the feature you already added which can be > shared across all WebKit ports and platforms. >
fixed.
Just added a 5 minute proof-of-concept caret navigation patch to bug #16135 It reuses existing key handling code and might be an interesting feature to support on Mac too. Feedback welcome from accessibility hackers.