Recently in XHTML Category
We all have our favorite Web 2.0 apps (even cynical old me), but it cannot be denied that any new Internet technology must inevitably be followed by accessibility issues. That's just part of the new Internet cycle.
Fortunately, this is often followed by accessibility tools and recommendations.
Some Web 2.0 Pitfalls
- Where's the ALT Tag? - If you upload an image via a Web form and you don't have a chance to give it a title or description...you've probably uploaded an image with no ALT tag.
- Where's the Podcast transcript? - Just because it has a cool name, doesn't mean it's not an audio file which needs to be accessible to hearing impaired audiences.
- What did AJAX do the screen? - When an AJAX app like Basecamp puts a new message on the screen, your eyes will catch it. The screen reader, on the other hand, might miss it...
- How good is that code? - Some WSYWIG editors generate better structured code than others. You want to avoid ad hoc styles and breaks and go for headers and paragraph breaks. And if you're persnickety like me, you probably want access to the RAW code so you can fix it!
- Same Link Text - Some apps include multiple links with the same text (e.g. multiple "Read More" links which is not recommended). It's preferable for links to have unique text if possible...but it is more difficult to implement in the backend.
- Web 2.0 = scripts! - Scripted pages can be made accessible, but you do have to work at it
Some Good Examples
Some Web 2.0 developers HAVE thought about this already. For instance:
- The Web editor for Wikipedia does convert its Wiki syntax to well-structured XHTML.
- Both Movable Type and Drupal uses CSS to make Headers appear to be hot-looking page titles and sidebar widgets.
- Movable Type will also put in an ALT Tag for any uploaded image...but it will match the title of the image unless the saavy blog writer changes it. Drupal will also allow to edit in ALT tags...but have to be on the saavy side for this one also.
At the same time, there are new standards being developed...such as WAI-ARIA.
The gotcha for these is that you may implement them, but an old screen reader might still miss them...
I read an interesting article from HTML Goodies reminding me that the switch to XHTML was mostly hype for a long time
http://www.htmlgoodies.com/beyond/xml/article.php/3669451
As Philbin points out, most of the reasons given aren't valid. This is because XHTML and HTML 4 pretty much have the same functionality, so basically:
- Well formed HTML is as valid as well formed XHTML. HTML Strict is pretty strict by the way - no FONT tags or ALIGN attributes allowed.
- You can make the same stupid accessibility glitches in either HTML or XHTML (did you know that black on black text is valid code...but illegible?)
- Browsers will be supporting both HTML and XHTML for many, many years to come.
- Not all browsers support ad hoc combinations of XML and XHTML.
This may be a case of the future is coming, but it really takes 5-10 years for it to arrive.
By the way, Dreamweaver 8 was my "bestest" friend ever in the switch. You open any document, then go to the File menu, then Convert, then pick your format (I recommend XHTML Transitional for beginnners, unless you were already HTML Strict).
Once you do this, Dreamweaver magically converts all <br> tags to <br> tags, and all <img> tags to <img /> (and it adds the pesky slash to all your single line meta tags). It also adds the correct DTD statement (so I'm not having to cut and paste that either). After that your WSYWIG editors is set to produce the XHTML versions of the tags and Dreamweaver valildation is generally picker when it's XHTML so it finds basic glitches much faster.
Now...we just have to worry about XHTML 2!