Todd Kloots is talking accessibility and ARIA, with examples showing how YUI nicely supports these techniques. He explains how to improve in three areas: perception, usability, discoverability.
Can We Do ARIA Today?
Yes.
Firefox and IE (he didn't say which version) have really good support for ARIA. And Opera, Chrome, and Safari. Likewise for the screenreaders - JAWS, Windows Eyes, NVDA - also have good support. An the libraries - YUI, Dojo, JQuery-UI - all have good support baked in, one of the benefits of using ARIA is automatic support.
Improving Perception - ARIA and Screenreaders
Websites can have problems in perception when rendered with a screenreader; it's hard to get the big picture about what the words refer to. With ARIA, we can close the gap in perception. This is another example of progressive enhancement - augment the item by adding properties, markup or Javascript if required:
node.role = "menu"// alternative introduced by IE8. IE-only, so don't use!
Improving Usability - Keyboard Focus, ARIA, and YUI support
Keyboard access. For some people, it's a necessity, and for others it's still an option or preference (think Vim). To support it, you must be able to tab to the element to get focus, so you should control tabbing with tabindex. A good application of controlling tabbing is, amazingly enough, moving through tabs. Another is modal dialogs; the browser doesn't "know" it's modal, so we have to control focus to make sure it doesn't slip out of the thing that's the only thing users should be able to click on!
Todd shows us just how many steps are required to perform a task in a complex application like Yahoo! mail, using just tabs to navigate through - 19 steps in this example, walking through the toolbar; and even more, when you consider the wider picture of entering the app in the first place. To help with this, he introduces a pattern whereby tabIndexes are updated dynamically to control what comes next, as you move through a toolbar. A negative tabIndex will ensure the element is skipped over.
You can also use the "focus" pseudoclass to ensure focus appearance is consistent for all elements. But, and it's a big one, it's not very well supported; even IE8 doesn't support :focus on <a>, for example. Doing it manually with Javascript has problems, in particular performance. Fortunately, PPK has worked out how to handle focus and blur with event delegation, so that it's much more performant, and the resulting technique is built into YUI3.
Device-independence with markup was also advocated to further improve accessibility:
Essentially, this is about "random access" and keyboard shortcuts; jumping straight to areas in this page and activating them. The key ARIA feature here is "landmark roles" to identify particular points on the page. This is still something where users aren't aware of the feature, and Todd points out it's not surprising as most screen reader users are self-taught (just under 75% according to the study he showed). Also, not every user is a geek, and the same applies to screen-reader users.
I am right now part of the Stackoverflow DevDays conference tour introducing the attendees to the things Yahoo has to offer for developers. One of the things is YQL as an easy way to use web services. When talking to the Stackoverflow developers they wondered how to make it easier for people to tag their questions. I've taken on the challenge and whipped up a GreaseMonkey script that enhances the Stackoverflow question form to automatically add tags to the question using the Yahoo Term Extractor API. You can see a screencast of the pimped StackOverflow or install the GreaseMonkey Script.
The next logical step was to clean up the script a bit and make it work without Greasemonkey. Now you can simply embed it into any document. See it in action on YouTube:
As shown in the demo page, all you need to do is to point to the script and call the init() method with the two field IDs as parameters.
<textareaid="mainfield"name="mainfield">Hello I am a programmer that does care about interfaces. What kind of library can I use that gives me a defined set of widgets that have been tested in the real world?</textarea>
Bill Scott presented Designing Web Interfaces, a slideshow based on core items from his book (co-authored by Theresa Neil).
There are some really interesting posts on the site, such as 30 Essential Controls. Theresa has been pinging the major frameworks and will be posting a matrix of coverage by the various frameworks. But more generally it is a nice checklist of controls that can liven up an interface.
What would a browser look like if the Web was all there was? As the Web becomes even more ubiquitous, we’ll never have to leave it. Whether it’s on touch tables, giant wall-sized screens, mobile devices, or just our computers, exploring the interactions for browsing a windowless Web will become ever-more important in the next couple of years.
I really like how they use the video to not show talking heads, but instead add to their content.
As I was listening to them discuss the different between usability and discoverability it really resonated with me. Most of my favourite features are not discoverable at all. For example, I navigate tabs with Apple-1, Apple-9 etc.
But back to the topic at hand, imagine you are in full screen browsing mode, how would you get around? For me, I hope those Apple-# keys still work (tabs fade in when I hit apple?)
How many tabs does an average use at a time? How about novice users? How often is the stop button pressed? How many times do people open a new tab to perform a search?
There are hundreds of questions like these whose answers would help quantitatively inform the design process of Firefox.
Those are the questions that Aza Raskin and the Mozilla Labs team are working on solving with Test Pilot, a very exciting project that is kicking off in force.
I am jazzed to see where this goes. I would love to see the crowd show us that "wow, people really do that?" which is my constant experience from usability studies. Maybe we could get some performance info too, and learn from the crowd that plugin A + plugin B causes issues. Who knows. The platform it just beginning. Have ideas? "Come brainstorm at a Lab’s Night, participate in the forums, hop on IRC, or help create on our wiki."
In our age of information and technology, there isn't as much mystery as there used to be. In that sense, short URLs (e.g., tinyurl.com/123) can be fun! Who knows where you'll wind up.
Some folks aren't as happy with uncertainty in hyperlinking; one of them, Darragh Curran, wrote in to tell us about his project: Long URL Please.
Long URL please (http://www.longurlplease.com) is a JSON webservice to
efficiently convert short urls (tinyurl.com/123) to their originals.
I've got a simple jquery plugin to take advantage of it, and a firefox
plugin. It's running on google app engine.
Darragh hates short URLs so much he's offering to contribute his time to help wipe them off the face of the web:
I'd love to see it used in apps like twhirl/tweetdeck/twitterific, on
microblogging sites and pretty much anywhere that's got lots of short
urls. In that respect I'll happily contribute my time to help those
people/teams integrate with the service.
John Resig linked to an interesting new time picker UI that Maxime Haineault implemented as a jQuery plugin:
He made a "two click" time picker. The first click is within the time field. This activates the display and allows the user to choose the time - all of which is done by moving the mouse over the times that you desire. The final click is anywhere - filling in the time that was chosen. It's hard to explain, you simply have to try it.
One thing that you'll notice using it is that it's fast. Very fast. I'd argue much faster than clicking into the input area, moving to the keyboard for entering the time, typing the time, then moving back to mouse.
I am a strong believe in making the keyboard a first class citizen for your applications, including on the Web. Thus, I was interested to read how Ext JS has keyboard handling that ties into the entire system:
Ext.KeyMap
Ext provides several components that support keyboard navigation out of the box such as GridPanel, ComboBox, and TreePanel. To implement custom keyboard handling, developers can use the Ext.KeyMap and Ext.KeyNav classes to attach keyboard bindings to any component or element they wish.
The first set of keys we wanted to handle was all of the Function keys (F1-12). While most browsers reserve some/all of these keys, with some ext-pertise, we are able to override the default function if need be for our application. The application we were working with was completely dynamic and server driven, so we really couldn’t define all of the handlers ahead of time. This led to us dynamically building an array of key handler configuration objects and passing them all through to our new Ext.KeyMap object.
Aza Raskin and the Mozilla Labs team looks like they are having a lot of fun. They have been putting up proposals for new UIs and the latest involves a smarter new tab screen.
Aza discusses how opening a blank screen doesn't really help you. Opera already allows you to have a quick dial screen show up there, but what else can be done?
Often a new tab is opened to do a search, so they can put a search bar right there, and it can be smart enough to search across your own tools and providers (e.g. delicious). I personally don't do this, as I use Apple-K to jump to the search bar in the browser and have the search results open in a new tab.
What I found even more interesting was the context specific smartness. How often do you do this:
Find an address
Select and copy the address
Open a new tab
Go to maps.google.com
Paste in the new address
Instead, the new tab selector can be smart and automatically show you the map option. NOTE: there are of course other options such as plugins that find the addresses and give you links to the map.
Instead of popping up the book, music, dvd information quickly we are required to watch the talent of the developer to sloooowly animate the box into place. Come on folks, we can do better than this!
There is no need to see utility objects like this animate into place.
Here is the general rule. Try your feature without animation. Is the meaning clear? If so then don't add ANY animation. If it is not, try adding a quick animation. Did that get it? Then stop there.
Save animation for when you need it. Animation is good for at least seven reasons:
Maintain context while changing views. Carousels are a good example of this. The scroll animation helps the user maintain context as they move through information.
Explain what just happened. The Apple store Customize your Mac uses this to highlight price changes while configuring a Mac for purchase.
Show relationships between objects. The Mac Genie effect when closing or opening windows. It is fast enough and it ties the iconified window to the dock.
Focus attention. Backpackit's Spotlight technique focuses attention on the change that happened.
Note that by “participate†I mean “edit, answer or ask a questionâ€. Of course passively reading a question and the associated answers will work fine without JavaScript enabled.
...
While we do believe in progressive enhancement, it’s possible that some of the features we’re building for asking and editing may be so dynamic that they do not degrade well, if at all.
What say you? Is it OK for a website in 2008 to require JavaScript for active (not passive) participation?
On a forum site like StackOverflow, is it an "enhancement" when you add a comment? Not really, which would make me lean towards keeping the site simple and not requiring Javascript for making basic contributions. There is also accessibility to consider (although "accessible" is not the same thing as "Javascript not required").
It could be argued that as a developer-focused website, Javascript can be assumed. But developers are also the most likely folks to go out of their way and turn Javascript off. And developers are also among the most critical of sites that require Javascript (or Flash) when it could have worked without it.
One of the examples that Ben and I give in our State of Ajax talk at Google I/O today revolves around form history.
We were thinking about the case for Undo on the Web that Aza Raskin is proposing and it got us thinking about the usage patterns of form data.
An example that got me was the Address Book application on the Mac. I find myself storing past addresses in the general "Notes" section at the bottom, but what if history was built into the system so I could go back in time? This could be a nice metaphor in general that goes beyond undo.
I took this use case and put together a working example that uses Gears to store the history locally so it can be speedy through the history.
The slider component comes from Script.aculo.us, and you can check out all of the code.
In the video below I show the application in action and then do a quick code walk through:
This is just the beginning of course. A slider if fun, but it would probably be more usable if it was simply left and right arrows that click through the versions, or at least putting tacks onto the slider.
Whilst not ticking all the boxes, I took the YouTube API and created an easy interface for YouTube videos that has big friendly buttons and easy to use volume controls:
You can just add a YouTube URL to the end of the player URL to play the video or download the whole player to host it yourself and style it any way you want.
What I found was that neither mine, nor the extJS nor the demo pages on the YouTube API page work in Opera, which means there is a bug in the API itself.
I've been talking about progressive enhancement here before and got a lot of flak in comments about it. It seemed that there was a general misunderstanding of progressive enhancement and unobtrusive scripting as a "passing fad" or "backward facing rather than being innovative".
I was asked by a design agency in London to go there and give a brown bag presentation (during lunch break) on the matter and took this as an opportunity to write up reasons and examples for progressive enhancement concentrating more on the why than on the how.
The gist would be to say: enhancing a product progressively means you'll always deliver a working product - as you have no idea how your product can fail in certain environments, you plan for it to fail. This ties in nicely with the agile manifesto - you always deliver software that works.
In my talk I came up with seven "rules" of pragmatic progressive enhancement:
Separate as much as possible
Build on things that work
Generate dependent markup
Test for everything before you apply it
Explore the environment
Load on demand
Modularize code
I've taken these ideas and backed them up with benefits you get by following them and code examples in a full article: Pragmatic Progressive Enhancement.
The article is licensed with Creative Commons and uses YUI in the example scripts, feel free to translate, remix and create examples using other libraries.
Over at Quirksmode.org, Peter-Paul Koch is researching if Event Delegation which works splendidly with click events is also possible for blur and focus.
Event Delegation means that you piggy-back on the behaviour of browsers to report events on child nodes up the tree to their parents. Instead of applying event handlers to each element you apply a single one on the main parent element and use the event target to determine which element was activated.
The benefits of Event Delegation are that you use a single event handler for a unknown amount of nodes. This is very handy when it comes to developing dynamic menus where the data is pulled via Ajax.
So far, PPK found that apart from IE all browsers play along, and there is a test page to give him feedback.
Bob Buffone has created a tool that can be used to output script and HTML to make your site more usable on an iPhone. He tells us about it here:
I bought an iPhone about six months ago; in that time I noticed that even though it had this part of the Web and that part of the Web. Every page I went to I was only reading this part and in order to do that, I needed to scroll it into view and resize the page the same way every time. When I go Ajaxian.com on my iPhone I need to scroll the content to the right location and scale it so the middle column fits the screen and then start reading. It’s a real pain in the ass.
This was the case for my blog as well. I didn’t want to rewrite it so I figured out a way to use a little JavaScript to set the scale and position of the page at start up so the main content area completely fills the screen for the iPhone.
Once you input the URL to your site, it gets loaded and you can interact with it to put the box in the right place. For Ajaxian, it then output the following HTML:
