Noticed James Edwards’ article on SitePoint about developing javascript-powered sites that still work for screen readers. It had some good points, such as thinking in terms of device independence, using input elements (anchors, buttons) to trigger actions, and using behavioral pairing instead of event pairing.

Although, I think the example of “accessible drag n’ drop” could have been phrased a bit better. Since it was an article about javascript, I realize that James meant “accessible drag n’ drop” to mean “Drag & Drop by mouse or by keyboard.” But I was a bit bothered by the idea of “Drag & Drop” as a feature. I would argue that “Drag & Drop” isn’t a feature per se, but more of an interaction or control mechanism. “Ability to rearrange or sort elements on your personal home page” is a feature, and “drag & drop” can be one (non-accessible) means to accomplish it. While this may seem like (and be) nit picking on my part, I bring it up because IMO I think it’s important to differentiate user goals from how they achieve them. The user doesn’t want to “drag and drop“, they want to “rearrange their home page.” That’s the user’s goal, which we can then start thinking about how to best accomplish for all types users (mouse users, keyboard-only users, screen reader users).

Thinking in this manner (goals first, then how to accomplish it for a given user base) means that you don’t have to take on the task of “making drag & drop work for screen readers” — you just need to allow VI users to rearrange their home page, which might have nothing to do with drag & drop at all! Indeed, the way I thought of doing it would be to have a hidden (or not) button or two on each home page element allowing the user to move it to the top, bottom, or up/down one spot in their home page hierarchy.

I should also mention that “accessibility” isn’t just about sighted vs visually impaired users — it’s about making features accessible to a certain type of user. James makes a great point about this in the first two sections (Keyboard Navigation? and Device Independence!). For example, some users don’t or can’t use a mouse, and instead use a keyboard to surf the web, so a site should still ideally be usable to them. In the example of keyboard-only users who are not visually impaired, I could see a keyboard-driven version of drag & drop, where the user “drives” a div around the screen via the arrow keys. Maybe this would be for an online game or drawing application where you have to position things in a specific way (put a hat on a person’s head, or position a pair of glasses on a face). In that case, the interface for visually impaired or blind people might be totally different, if they’re even interested in the application at all. They may not be, which is why it’s important to consider your potential user base.

James also links to an interesting accessible crossword puzzle by Derek Featherstone. If you look at the source code you’ll see a number of useful elements & tricks for accessible sites: fieldsets, labels, “hidden” text.

So…I really just meant this to be a “hey link over to this interesting article” post, but I guess I got carried away.