I think iPad apps like Flipboard may turn out to be one of the best things to happen to accessibility in quite a while. Not because they are accessibility tools themselves, because they are not. No, this is a bonus for accessibility because it will let users who would never think about accessibility see the consequences of bad code. Good semantic code with all the style controlled by CSS looks wonderful when it's pulled into Flipboard. Poorly written code using inline styles, spaces, and other tricks to control the design don't fair so well.

The obvious followup question to 9 Reasons Why Accessibility Matters is "How do I do that?" It's not really as difficult as it might seem. Answer these nine questions, and see how your site's accessibility can be improved.

1. Can you navigate your site easily? Are links and navigation obvious and intuitive? Look at it as if you'd never seen it before, would you understand how to get around quickly? Are your links visible or invisible?
2. Does your site use skip links? It should. This allows members of your audience to quickly jump over blocks of content to get to what they came for. This will benefit keyboard only navigation, various accessibility tools, and readers who use magnification or zoom a lot.
3. How much contrast does your site have? Use something like the Colour Contrast Analyser to see how your site rates. Good contrast can open up your site to people with a wide range of vision issues who otherwise might not otherwise be able to access it.
4. Is your site valid and standards compliant? A valid and standards compliant site will much more consistently displayed across browsers and accessibility tools. It's not a guarantee, but a good start. Try doing a site test to see where you stand with your site. I use tools like the ones on this list to do this sort of work.
5. How does your site look without CSS? Does it still make sense? CSS is a very powerful tool, but it can be abused. Screen readers and even your RSS feeds are going to display your site without CSS. If you use CSS to change one type of content to look like another, for instance to make a paragraph look like a unordered list, it's going to still look like a paragraph in your RSS feed.
6. Did you define your default language in the HTML element of your web page? This simple addition to you code let's people know what language to expect.
7. Did you define ALT text for your images? ALT, or alternative text, atributes will describe your images to your audience members that aren't viewing your images. Maybe they're using a screen reader, or maybe they just are saving download time while on dial-up. Without ALT text, they might not even notice they missed an important image.
8. Did you use headings to identify navigation lists? Using a H2-H6 heading before a navigation list will help with screen readers and with keyboard navigation. It helps break up the site into identifiable regions so that navigation is more intuitive. If you don't like the way these headings look, then change their appearance with CSS. This will allow you to keep the appearance you like, but keep the improved navigation too. Update: 52% of screen reader users navigate by headings whenever possible - WebAIM Screen Reader Survey .
9. Does your H1 heading at least partially match your page title? A simple thing, but it can significantly improve a viewers ability to identify where the are on your site, and to navigate. It also should improve your search engine results.

These items won't guarantee a perfectly accessible site, but they'll move you nine steps in the right direction. If you're interested in discussing how to improve the accessibility of your site, or accessibility in general, leave me a comment. Getting me to discuss accessibility is never a problem. To paraphrase Shrek, it's getting me to shut up that's the trick. Update: Thank you to Aankhen for checking my work.  Both of the errors you caught should now be corrected.

More bad news from Microsoft. Despite the uproar caused when they originally suggested making developers opt in, to get standards compliance mode in Internet Explorer 8 (IE8) they've now quietly returned to this unwise strategy. So developers are now back where we were a year ago, before Microsoft backed away from this plan. It seems we're being reprimanded for not making all of our sites compatible with a browser that hasn't been officially released yet. Why didn't I fix my sites for IE8 Beta? Because I'd have had to fix them again for IE8 Beta 2. Why not for Beta 2? Because I'd have had to fix them for IE8 Release Candidate 1. You get the picture.  Microsoft has a history of making significant changes right before the official release of their products, so I'll be waiting until I see a finished version before I change anything. Here's a few choice quotes about the progress of Internet Explorer 8. IEBlog : Compatibility View Improvements to come in IE8

With IE8’s Beta 1 release, Microsoft demonstrated its commitment to interoperability by making the most standards-compliant default view for web pages IE’s default.

With IE8’s Beta 2 release, we introduced the Compatibility View button. This button enables savvy end-users to resolve compatibility problems they encounter with sites that rely on legacy IE behavior.

When users install Windows 7 Beta or the next IE8 update, they get a choice about opting-in to a list of sites that should be displayed in Compatibility View. Sites are on this list based on feedback from other IE8 customers: specifically, for what high-volume sites did other users click the Compatibility View button? This list updates automatically, and helps users who aren’t web-savvy have a better experience with web sites that aren’t yet IE8-ready.

I translate this progression of quote like this

1. We'll be standards compliant
2. We give you the choice of being standards compliant
3. We'll choose whether you're standards compliant or not for you

While they suggest that users will get to choose to opt out of this "compatibility list" on installation, how many users will select "review and modify each setting individually" on installation? I'd guess very few. This setting will theoretically also be in the preferences, but I'd be willing to bet few IE users will go looking for it there either. Microsoft says that they're taking this course of action because they became aware that:

"...large groups of people were having a less than great experience because they weren’t aware of the manual steps required to make certain sites work."

They were surprised that a new feature was not being properly used in a Beta product? Did it occur to them that fixing the problems with the Beta product would alleviate this issue? How about educating their users about their new feature? Apparently not. Why spend all this time and money to improve their product, and IE8 is a big improvement, if you're going to force it to replicate the behavior of its flawed predecessor?

Unlike many others, our recommended method of implementing skip links ensures that all keyboard users ’see’ the skip link, as it appears visually on screen when a user tabs to it, and is of course read out by screen readers. The problem is this — although they find it, many web users simply do not understand what a skip link does, let alone how to use one.

I've used skip links on all my sites for quite some time, but a while back I made a change. The change was in using longer link text. Taking a page from Accessibility Field Notes, I realized that there is really no down-side to longer link text. Rather than the simple "skip" or "skip-link", I now favor "Skip to Main Content - press enter to activate". If you're not using the skip links, the length of the text doesn't matter, you don't see it. If you are using it, it helps, or you don't read it anyway. Win-win. What are skip links? Skip links are links, often hidden, that allow the viewer of a website to skip blocks of content. Why? It's an accessibility feature. Viewers using screen-readers, increased font sizes, no CSS, or a variety of other methods can have difficulty navigating web pages because of the complexity of modern web sites. Websites viewed using accessibility features are often made linear. So if a viewer wants to read the content of your page, they have to read everything that comes first, first. Thinks that's not much? Try reading your site.

1. Start with the header,
2. Then read the sidebar all the way to the bottom.
3. Now, if you're lucky, you found the content you were looking for.

What if it's the wrong page? What if the story it has a second page?

1. Start with the header,
2. Then read the sidebar all the way to the bottom.
3. Now, if you're lucky, you found the content you were looking for.

Third page? You see where this is going? Skip links let you "skip" over blocks of content like the sidebar. They eliminate the need to view irelevent and/or repetitive content you aren't interested in. Go to the page you want, and "skip" to the content you want. A simple solution to an annoying problem.

I was putting together a list of resources that I regularly use for someone, and I thought it might be helpful for someone else.

Firefox Resources

• Web Developer -  all purpose testing. Extremely helpful when checking CSS, but also good with images, forms, and other HTML elements.
• Firefox Accessibility Extension - evaluate accessibility on web sites and other HTML documents
• WAVE Toolbar - another good accessibility testing tool
• IE Tabs Plus - open IE within a Firefox tab
• LinkChecker - the name says it all
• MeasureIt - find dimensions of online content or space
• ColorZilla - find the exact color you're seeing in the browser.
• HTML Validator - a great validation tool for testing web pages.
• Fangs Screen Reader Emulator - emulates a screen reader for testing accessibility and other usability factors.
• Split Browser - open two pages in the same window.
• Live HTTP Headers - know what your page is loading, and from where
• FireShot - superb screenshot tool.
• Firebug
• Colour Contrast Analyser
• Multi Links
• Other helpful, extensions
  • All-in-One Gestures - makes browsing easier.
  • Profile Manager and Synchronizer - open multiple Firefox profiles at the same time.
  • Scribefire - designed as a blogging tool, it's also helpful for just collecting links and content in clean HTML.
  • IE View - switch from Firefox to IE in a click. No need to find the page again in IE, just open your current Firefox page in IE.
  • FoxView -open your current IE page in Firefox
  • OperaView - open your current Firefox page in Opera
  • Chrome View - open your current Firefox page in Chrome
  • Safari View - open your current Firefox page in Safari
  • Pencil Wireframing Tool

Resources for Internet Explorer

• Internet Explorer Developer Toolbar - Now built into base browser.
• Web Accessibility Toolbar for IE

Resources for Opera

• Opera Browser - A resource all by itself. If you're not familiar with it, it's another high quality browser that's useful to test pages in.
• Web Accessibility Toolbar for Opera

All Browsers

• xmarks - extensions available for most browsers.
• extension for government video

I'm still using the CSS Menu Writer that I got to evaluate. I have to say it's very slick. I'm working on a WordPress site that I hope to reveal soon, and it came in very handy. I've worked on tabbed navigation with CSS before, but this was relatively painless. A few quick menu adjustments and it gave me a set of beautiful tabbed menus. Of course it's never quite that easy. I had to track down a bit of a z-index glitch in IE6 and 7, but that was hardly the fault of the people at WebAssist.  The menus performed perfectly in my base page in all browsers. It was only when I introduced some additional CSS of my own that I had an issue. Why can't Microsoft come up with a browser that works as well as the new Chrome by Google seems to? If you're looking for a Dreamweaver plugin that takes some of the work out of clean CSS menus, I'd suggest giving CSS Menu Writer a look. Even if you use it like I did, to quickly build a base menu that I further customized, it is an incredible time saver.

If you are a site designer, or a site owner, you will at some point need to evaluate a site. Do the bones of the site stand up, or it is a screaming wreck hidden behind a pretty facade? The first thing I do is look at the source code.  Beautiful code isn't the final answer on site testing, but it's a place to start.  Is it table based, or a CSS layout? A table based layout should put up a warning flag. Table based layouts are outdated... you can do better. You want CSS. It's more adaptable, and more accessible to a wide range of technologies. You can also make significant changes to your entire site by changing just one file. A quick look at the code should be enough to tell the difference. If the source code is filled with <table>,<td>,<font>, and <tr> then you're looking at a table layout. If it looks more like <div id="blah-blah">,<h2> and <ul> then you're likely looking at CSS. Validation is my next step. Just because it validates, doesn't mean the page works, but it does rule out a lot of common errors. If you just want to validation check one or two pages, for to WDG HTML Validator and type in their URL. You will get an immediate evaluation of the page's validation status. Quick, clean, and simple. If you're going to do this often, go get the Web Developer or Html Validator add-on for Firefox. You are using the Firefox web browser aren't you? If you aren't, then download that as well as one of the validation add-ons. They're free, high quality products.The Web Developer add-on is a powerful testing tool. It has all kinds of bells and whistles, so it may be more than you're looking for. If you only want to check validation, then just go with the HTML Validator. It does that one task very well. If your site is CSS based, you can validate your CSS file too. I'd suggest CSSCheck or once again Web Developer. Then we get to links. Any broken links on your site? It's annoying, but sites come and sites go, and invariably you will end up with broken links. Try out the Online Link Checker, or the LinkChecker add-on for Firefox. Accessibility is also important, I'd suggest trying the OCAWA accessibility validator. There are other tools and add-ons around, but that will get you started. If you need more testing options, Web Developer has some accessibility functionality, and there is the Firefox Accessibility Extension as well. Want an overall evaluation of the speed of your site? Try out the Web Page Analyzer. It will let you know how fast your site is running on various bandwidths, and make suggestions for speeding it up. I would suggest sticking with Firefox for most of your testing purposes, because of the wealth of testing tools available. There is however, an Internet Explorer Developer Toolbar. In my experience, it doesn't work as intuitively or as well as Firefox's, but it does work. This isn't everything you need to know to evaluate a site, but I hope it helped get you moving in the right direction. Good tools always make a task go smoother.  Good luck.

The nice people at WebAssist.com are letting me try out their new CSS Menu Writer extension for Dreamweaver. I got a demonstration of it yesterday, and I've been putting it though it's paces this morning. It is exactly what the title would suggest, a CSS menu writer. Working through four tabbed menus, you can easily create fairly complex, and valid CSS menus. I'm very impressed with it so far. The extension works well, and is quite intuitive. The two most significant aspects I see, are that it uses no proprietary coding as far as I can see, and that I can create my own preset templates. This means that any menu I create using this should be editable by anyone with a knowledge of CSS, and that I can adapt the software to my own design style. This has the potential to be a very significant time saver for me. I'll go into greater detail when I've had a few days to try it out.

Despite early announcements that IE8 would default to displaying pages as if it were IE7, Microsoft is now announcing that it will default to Standards mode. This will alleviate the need for designers to opt out, by opting in as I've written about before. Microsoft Expands Support for Web Standards

Consistent with its efforts to promote further interoperability across the Web, Microsoft Corp. is now configuring the settings in Internet Explorer 8, the upcoming version of its browser, to render content - by default - using methods that give top priority to Web standards interoperability.

This is the best news I've heard from Microsoft in quite some time. I was really hoping this issue would be resolved before IE8 came onto the market, but I was holding little hope. They have in the past seemed more inclined to use their own proprietary standards than to "give top priority to Web standards interoperability". I'm happy top see that that wasn't the case here.

A List Apart: Articles: They Shoot Browsers, Don't They?

This is gobsmackingly audacious. Imagine a new version of Word that behaves exactly like the old version of Word unless the document it is processing contains a hidden instruction to unlock any new features. That's what Microsoft is demanding that web developers implement. Unless you explicitly say otherwise, IE8 (and IE9 and IE10, ad infinitum) will behave exactly like IE7.

I've been following rumors about this feature for awhile. I thought they were going to turn out to be incorrect. It seems too audacious even for Microsoft. Forcing designers to use proprietary code in order or IE to work correctly? I can't see how this won't blow up in their faces in some way. It's sure not going to earn them any good will.