Should-read article: Accessible drag and drop using WAI-ARIA
The keyboard-friendly design of Opera was one of the things that attracted me to the browser in the first place, and one I am disappointed with the slow progress with. Keyboard-wise Opera today isn’t substantially better today than Opera 3, or at least Opera 7. In some cases it is better (like spatial navigation when it works), in other cases it is worse (I still haven’t found how to recover the Alt+Z history view, one of Opera’s greatest inventions). I don’t think Opera does any keyboard-only or keyboard-augmented usability testing.
Opera’s lack of progress is one thing, but in the Web sphere things are actually getting worse. Early on you could do keyboard-only browsing most of the time. If the site used frames it was very awkward and it was better to use any mousing device available, and you had the occasional idiot who used ‘onclick’ functionality to recreate actual links, either because he didn’t like the colour or underline of links or simply because he could.
Most of those idiots have discovered CSS by now (there should be a Hall of Shame site for those who haven’t), but in these webapp ajax gidget 2.0 days recreating the user interface is the game of the day, and that usually means breaking the keyboard.
One of the tasks you can’t reliably do with the keyboard today is drag and drop, and that goes for navigating to dynamically generated submenus and choices as well.
In my view the raging accessibility question shouldn’t be whether the ‘alt’ attribute is optional or mandatory, but how we can make the Facebooks of the future accessible.
This ties in with HTML5 and the obituaries over the dead discontinued XHTML2 spec. XHTML2 and XForms were designed with accessibility in mind, HTML5 was designed primarily with web designers in mind. For a devoted keyboard user that should make the preference easy, right? Not so. The HTML4 spec, like XHTML2 and XForms, is filled with well-intentioned accessibility features, but those features are no good if they are not used.
An attribute like ‘longdesc’ can make an inaccessible picture into a device-independent and accessible textual representation of that picture. All the designer has to do is to spend a couple hours for each picture describing them in detail what they depict and what they are used for in an as context-independent way as possible. For some reason most web designers opt not to do that.
Given the choice between having Facebook and similar sites mostly usable or the WAI site and a couple other special interest sites perfectly accessibly marked up, Facebook is the winner. If the spec can give designers the features they crave and then behind the scenes give the browser or the assistive tool the information they need to cater to their users we have a winner. The HTML5 work with drag and drop looks very promising in this regard.
What the HTML5 spec doesn’t cover, and which Opera has struggled with in its extensive keyboard support, is how to handle the conflicting interests of the web application developer and the user agent, be it a browser and/or assistive tool. As an example Opera uses the A key to navigate to the next link, what if that key is used by the application? In a keyboard not having the A key another key is used instead, or the user can configure his own keyboard mapping, so it wouldn’t make sense to make a collection including A “reserved key” unavailable for the application. So who should win in a battle of A, the web application or the user agent? CSS has covered a similar conflict in the Cascade (the C in CSS), essentially default < author preferences < user-important preferences. For a User Agent I believe the best option is to let the UI be overridden by the web application (otherwise the application won’t work in that environment) but have a mechanism to override the application when needed.
Related, given the great variety of keyboards, some user mechanism to remap keyboard mappings is necessary not only for the user agent, but for the web application as well.
Here is a demo of keyboard-accessible drag and drop in action.
Tools > Preferences > Shortcuts > 9.2 CompatibleSo, there is your Alt+Z shortcut.
Thank you a bunch, this was driving me crazy. I have customised keyboard setup, but through your tip I found the command I was looking for:Z Alt: Show popup menu, “Internal Back History”(and similarly added for Alt+X)
Thanks, before I read this I did not even know what Alt+Z was.:D
Fabian writes:That article about keyboard accessible drag-and-drop is interesting, but the real challenge is of course to get native drag-and-drop including keyboard support in Opera, without the author paying any attention to it.
I agree, and I wanted that while working there but the killer still isWhat the HTML5 spec doesn’t cover, and which Opera has struggled with in its extensive keyboard support, is how to handle the conflicting interests of the web application developer and the user agent, be it a browser and/or assistive tool.Keyboard has had low priority in Opera for years now, other accessibility features have had priority, and where we have keyboard access it is often seen as a bug, not a feature. One of the reasons web designers have disliked Opera is that that the keyboard features they make don’t work in Opera.Somehow we would need a mechanism to let author keyboard functionality and user keyboard functionality co-exist, and it has to be mainstream. If the mechanism is constrained to the accessibility tool niche it would be functionally inferior. Even if it was constrained to the Opera, the tens of millions of Opera users would still be few enough to be ignored by the ambitious web developer.The mechanism needs to be catered for in HTML5 and similar mainline specs, and have support not only by Opera, but by as many as possible of Firefox, IE, and Safari as well.