I've been writing HTML/XHTML for the last decade or so, since a college internship. I taught myself the basics back in the mid-90's with the help or a friend and one of those "Learn HTML in 24 hours" books. It probably was something more like 10 hours before I really felt like I "knew some HTML". And the idea of making a website that anyone in the world could visit was fascinating to me being a journalism major at the time. Cutting out the middleman and becoming your own publisher was pretty spectacular to me.

I've literally been feeding myself on the proceeds of my markup ever since.

The coolest part about this is that despite spending so much time mastering web development skills, there's always something new to learn, a new approach to take or a better way to build your site. First it was Photoshop. Then it was JavaScript and CSS. And despite no real training in programming, and not really having the brain of a programmer, I learned some PHP. Then I took on ASP and ColdFusion. I was into Flash for about a year or so. Then back into CSS. Then I took up interest in accessibility. And before I knew it, I had to learn C#/.Net, and in the process, joined it with Web Standards to take my skills to the next level.

But after doing a code review today on a standards-based client site today, I realized just how satisfying it is to know that I've poured the last decade of learning into the templates I've just produced. I think that's pretty cool. Sometimes I have to remind myself that just because I read blogs of developers who really are professional site builders like myself, the fact of the matter is that it's still a rare breed of website developers who've been in the game this long and who are actually using web standards.

Labels: CSS, Flash, web-standards, XHTML

Access Matters recently confirmed what I knew was true of JAWS but was guessing about others: the leading screen readers speak your pages in the order in which they are coded and ignore CSS positioning. Good news for us; reordering your content with CSS is not only a best practice for search engine optimization, but also screen reader accessibility. So when you're dropping that two column layout with left navigation, put your content in the first <div> and your navbar in the second.

Another consideration would be the positioning of buttons in forms. If you want to position an action button above a table of data (or any other content), you could potentially code it after the table and use CSS-P to place it where you like.

Armed with this knowledge, we can now recommend another best practice: if you can't test your site in an actual screen reader, reading your xhtml in order for content comprehension is a good low-fidelity test to see if your content will make sense. Use Firefox's Web Developer extension to view your page without CSS or go into your code and do it manually.

I did a lot of testing recently with a screen reader for a client that was talking about screen reader accessibility, but balked when we explained that coding to Section 508 and WCAG doesn't guarantee anything and that we'd need to add a screen reader testing phase to declare their site "screen reader accessible."

Along the way, I learned quite a bit about JAWS 6, and realized that the learning curve for a sighted user is pretty significant, so I can imagine the hurdles facing blind users. I had to do quite a bit of Googling to find out that JAWS offers a "tables mode" and a "forms mode" that allows it interpret things like scope attributes on <th> tags, or to successfully select more than one item in a combo box.

It's been said several times elsewhere, but screen readers still have a way to go in standards support and just overall usability. In the meantime, the onus is on us to discover how to best accomodate users of assistive technology.

Labels: accessibility, CSS