You just found out your application or website needs to be accessible and are handed a set of Section 508 standards. Where do you start? After the question came up on the IXDA discussion list recently, I realized it still seems like a scary prospect for people new to accessibility. So hopefully this will help.

Validate

It’s not a Section 508 standard, but before you do anything else, validate your code. Why? Because when assistive technologies are looking through code and trying to translate that into spoken text, Braille displays, etc., they’re trying to figure out what’s what. If you have unclosed tags, improperly nested tags, etc. they don’t know what’s what and choke. Take a listen to some bad code with JAWS (popular screen reader) – you won’t know what hit you.

There are free tools out there like the W3C Validator tool (http://validator.w3.org) and many IDEs like Dreamweaver have built in validation options. It can take a few minutes per site or page, depending on what type of site you have (content or application), and it will make a huge difference.

Content Sites

If your site contains content, which even web-based applications will, look at it in this way:

• Navigation / links – can you reach all navigation (including nav bar menus) via the keyboard? if not, do you have landing pages that can be reached by keyboard as alternative to mouseover menus?
• Text – if you use images for headings, nav links, etc. do you have alt attribute or text behind it (and is your image still readable when zoomed in?)
• Headings – are they identified via <h1>, <h2>, etc.? That helps people jump to different parts of the document and bypass nav menus
• Tables of data – do you have table headers identified with <th> (CSS classes like “heading” etc. aren’t enough)
• CSS for general site and content layout, not a table-based layout - and following on tables, imagine hearing there are 10 tables on a page? or checking to see if your tables are used for data and need <th> tags? If the web standards mavens haven’t convinced you to go with CSS, run your page through Fangs (mentioned below) or JAWS and maybe that will convince you! “3 tables…table with 1 column and 20 rows…table with 3 columns and 18 rows” (and nothing contains any data worthy of a table! ugh)
• Search, contact fields – when you have form elements, do you use label tags or title attribute to provide labels? (preferrably visible onscreen to help all visitors) if you have drop-down menus, can users select from them and then select the action (e.g., select a category, then click Go; vs. automatically moving to another place as they select)
• Unique labels for documents – if you have PDFs and other doc lists, are the links or icons labeled with unique on-screen text (preferrably) or title attribute (so someone using screen reader doesn’t har “PDF PDF PDF” etc.)

Web-based Applications

If the site’s a web-based app, forms and tables for presenting record/data collections are usually more of the beast. You’ll want to check items above, and then really go deep into the forms, checking that:

• <label> tags are used, preferrably explicitly (e.g., <label for=”idforfield”>labelname</label><input id=”idforfield”>…
• <fieldset> and <legend> are used with groupings of related fields (e.g., multiple parts to an address block, phone numbers with extensions, etc.)
• Error messages and feedback can be communicated to users, possibly via <span> tags within the <label> tags (set span to hidden when there’s no error message, and then set to visible when there’s an error so it’s picked up by assistive technology)
• Any data-dependent items (e.g., lists refresh based on selection)? is the change downstream?
• You’ve used CSS for laying out forms, rather than using a table-driven layout
• If you’re using AJAX and other RIA components, and want to know about ARIA, well, that can cover several posts or a full-day tutorial! (talk to me)

There’s more (e.g., image maps, frames, etc.), but the above covers most of the usual problems.

Favorite Plugins & Tools

Firefox is great if you have the flexibility to use it for checking pages. Here’s a list of my favorite plugins…

• Web Developer Toolbar (https://addons.mozilla.org/firefox/addon/60) – great for displaying information about various fields, content, etc. so you can see if heading tags, labels, etc. are missing
• Firebug (https://addons.mozilla.org/en-US/firefox/addon/1843) – one of the greatest tools ever, lets you inspect elements on a page and figure out what’s happening. So handy when used with JAWS and other screen readers / tools as you’re checking.
• Fangs, a screen reader emulator – it’s not a perfect emulation, but does give you an idea (https://addons.mozilla.org/en-US/firefox/addon/402)

The Opera browser’s great for checking accessibility too.

If you’re using IE, you can install the Web Developer Toolbar that’s useful. Jim Thatcher has some great favelets as well to help tweak the Web Developer toolbar.

Hope it helps. This may seem overwhelming – once you run through it once or twice, you become familiar with what to check.

For what it’s worth, the automated tools can help spot items to check, but you’re better off with a good approach and plugins for Firefox / IE to check things. The automated tools can give some false positives and negatives that could be pretty critical. I’ve seen organizations get excited when the tools give a green light (despite major accessibility flaws, especially where forms are concerned), and concerned customers when the report shows all the “warnings” for elements that needed manual checks. And the times, they are a-changing, so the techniques that were givens 5 years ago aren’t the only way to provide information to users anymore.

Delicious Resources

If you’re brave, check out my Delicious bookmarks on Section 508 and accessibility – I’ve bookmarked a bunch of tools and articles I’ve found over the years at http://delicious.com/walserk/accessibility.