I recalled having read something by Roger Johansson on the topic (Overdoing Accessibility) and dug up the link to get some expert opinion. One instance of improper tabindex use he pointed out was the following:

A good example is the comment form in a default WordPress installation. The form controls (input fields and submit button) all have tabindexattributes despite already being in a logical order in the source. The effect is that keyboard users will skip straight to the comment form when they start tabbing through the page. Very annoying and completely useless, though probably well-meaning.

After checking a few themes (including the default Kubrick, and Pressrow), I found that all of them suffered from this problem. Sandbox, on which this site’s theme is based, is slightly different, with tabindex 1 and 2 being set on the search form, and the numbers between 2 and 6 not being assigned at all. Still definitely not ideal.

You can check out this behaviour for yourself: go to a Wordpress blog using any of these themes and hit the ‘tab’ key on any page where a comment form is present, and you’ll be jumped down to the first field in the form. 

I plan to fix this on this site, and all the other Wordpress themes I’ve developed as soon as I can.

The default WYSIWYG editor, for instance, seems to purposely prevent you from entering your ampersands (&) as & which is required for XHTML validation. The way around this is simply to use a different editor; namely, JCE, or the Joomla! Content Editor. JCE will, among other nice features, automatically appropriately encode your typed ampersands, making it easier to ensure your code validates.

One annoying “feature” I’ve encountered with JCE so far, though, is the inability to insert empty alt attributes. Often, particularly in the case of an icon that is more than adequately explained by surrounding text, adding alt text would actually just be at best redundant and at worst confusing to people using screenreaders. However, to validate, you have to include an empty alt attribute (alt=""). JCE doesn’t seem to like this, and will strip your empy alt attribute. I’m sure there is a relatively simple hack to circumvent this.

Usability, accessibility and standards

• The website will conform to the following standards:
  • Validation to either the W3C XHTML 1.0 transitional or strict document type
  • Validation to the W3C’s CSS 2.1 or 1.0
  • JavaScript will be implemented as progressive enhancement
  • Will meet all WCAG Priority 1 Guidelines, except No. 1
• The website will render correctly in IE6+ and Firefox 2+
• All multimedia files will be available for download, and video will be provided via Flash
• Alternative stylesheets will be developed for printers and mobile devices
• Character encoding will be UTF-8

This is still not solidified, and I may decide to put HTML 4 in along with XHTML, though my preference is for the latter (for more on developing with XHTMl, see Jeffrey Zeldman’s “Better living Through XHTML” at A List Apart).

Some other notes:

• No XHTML frameset doctype allowed!
• Considered including the note about disallowing JavaScript browser detect methods  in favour of object detect, as mentioned in the article above, but sometimes you need both and there’s no point painting yourself into such a nitpicky corner. Specifying “progressive enhancement” instead of “graceful degradation” is a good idea.
• Why just level 1 priorities of the WCAG and why exclude Guideline #1? It’s a human resources thing. It would be great if we could provide transcripts of all the audio and video we post, but it’s unfortunately just not realistic.
• Why just IE6+ and FF 2+? We get almost zero % of our users running Safari or IE 5.5, and only about 0.7% running Opera. Anything below 5% and you have to seriously consider the time and resources involved in browser testing, tweaking and hacking–especially for IE 5.5. My guess is that pretty much anything that works for Firefox 3 will be fine for Safari 3 and Opera 9+, and anything that doesn’t is probably trivial enough to forget about. If we were a big e-commerce site, and that 0.7% translated into 5,000 potential customers then I would probably think differently.
• Flash–not quicktime (I always find it slow to load) and definitely not some Microsoft technology (that is also slow loading and may not work on a Mac). Flash is one of the most universally installed browser plugins.
• Alternative stylesheets are a great idea to have control over how webpages print, and are also increasingly important given the proliferation of Internet-enabled mobile devices
• Being a bilingual organization, we use a lot of French characters, and I find UTF-8 is the way to go.
• We could specify mime type but I really don’t want to go there. There are lots of important articles discussing and usually warning against serving XHTML as text/html (see here for the classic, and here for the official), but given that I expect all our pages to validate, I’m not incredibly concerned about this.