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.

Found another big list of accessibility checking tools at NSCU. Maybe I should start making a comprehensive list. Or a wiki. Or a delicious link set. Or something. Anyhow...

Fangs, a Firefox plugin, is interesting. I tried it out. Basically it displays a text version of your site similarly to how JAWS (the most popular screen reader) would read it. So it helps you look for a bunch of repetitive stuff, etc. It's not perfect, though, but nice for a quick page check.

Google Home Page

Fangs' "intepretation" of google.com would be read by JAWS

Fangs' list of links (similar to JAWS' link list)

 

A List Apart had a nice article on accessibility and the importance of real-world user testing. And for some reason dasBlog is tripping out on me.

Here's the link: http://www.alistapart.com/articles/workingwithothers/

The article has some nice tips, like viewing your web site in IE6 with the font size set to "Largest" to make sure that your fonts all scale up correctly. But the comments also had some gems, for example a link to this paper about observations of screen reader users and how they navigated sites. Craig Francis also listed a huge number of notes from a recent presentation he was at, with some interesting insights.

Some good comments at accessify.com about screen reader testing tools:

• http://www.screenreader.net/ has a free reader called Thunder
• http://www.standards-schmandards.com/index.php?show/fangs - Fangs is a screen reader emulator
• http://www.firevox.clcworld.net/ - FireVox is a FireFox plugin that reads the screen
• http://clickspeak.clcworld.net/ - (I found this one) ClickSpeak is another free FireFox plugin.

Some good points were also raised about sighted developers using screen readers for testing

Adrian Higginbotham: Personally I never recommend anyone to try testing a site with a screenreader product unless they are already a confident screenreader user. you simply don’t use the tool in the same way

Adam Perry: I am sure Adrians comments are correct: a Visually Impaired (VI?) person will use the screen reader in a very different way. Nevertheless I found using a screen reader helped to identify areas of HTML which require improvement (inadequate or missing ALT, TITLE and SUMMARY attributes, for instance).

When developing a web site for screen readers and other accessible browsers, you often have to wrestle with the demands of Section 508 compliance and a nice design.

One WCAG guideline is to provide a "skip navigation" link near the top of the pages. Since you want this link to be available for screen readers, but hidden for normal browsers, your first instinct would be to do something like this:

<div style="display:none"><a href="#content">skip to main content</a></div>

... a bunch of navigation here ...

<a name="content" />
Main content here ...

However, you'd be wrong. I found this screen reader test at Access Matters that indicates that many screen readers try to obey CSS commands, and so many "hidden CSS tricks" like display:none or a 1x1 blank pixel with ALT text end up not getting read aloud by browsers.

It seems like the best solution, if you need to hide the "skip to content" link, is to use something like this

<div style="position:absolute;top:-100px;"><a href="#content">skip to main content</a></div>

Edit: FYI, Jaws and Window-Eyes are the first & second most popular screen readers, at least in 2003 when they commanded 65 & 35 percent of the market, respectively. But more recent articles imply the same thing -- those are the two to support.

 

I found another online accessibility checker for Section 508 etc compliance at www.aprompt.ca. It's web-based but also has a downloadable Windows version.

I'm doing a web site where one of the requirements is Section 508 compliance and I wanted to find an online validator similar to W3C's XHTML and markup validator.

So, I found two online accessibility validators that seem to work well:

http://www.contentquality.com/Default.asp

and

http://bobby.watchfire.com/

Also, Stephen Walther has a good article on MSDN about how to configure your ASP.NET pages and controls for accessibility (credit Brian Russell with the link).