JavaScript or Flash in themselves are not really the problem; it is how they are used.  I am most familiar with JavaScript, so I will use it for my examples.  I suppose you can also abuse Silverlight, but I am not familiar with people using it for dynamic menus.  Basically, your menus should either gracefully degrade when scripting is not available or you should provide an alternate menu.

There are some very cool JavaScript menus.  Most work by dynamically hiding/displaying links based on what your mouse pointer is hovering over.  If the menu is made up of an unordered list, or nested lists, the menu will likely expand so that all choices are visible when JavaScript is disabled.  The menu may look ugly, but it will work!

Other menus are actually based on CSS – the CSS controls the hiding/displaying – and JavaScript is just an enhancement.  The State of California template does it this way.

Before you choose a JavaScript menu try disabling JavaScript in your browser to see what happens.  If it does not degrade to something usable you either need to keep looking or add an optional menu in a noscript tag.  Personally, I would avoid the noscript tag option because it means you need to maintain another menu.

The last thing you need to do is to insure the menu is accessible without a mouse (both with and without scripting).  Try using just your tab and enter keys to navigate your site; you just might be surprised how hard or tedious it is!  While it is good practice to have your most used links near the top, or beginning, of your menu, it is critical for keyboard-only users.

I will talk more about menus and accessibility in a future post.

For these reasons I always validate my pages as they are being developed, and occasionally I perform spot checks later.  So I was VERY surprised when I validated my last blog entry and discovered it was no longer valid XHTML Strict due to an attribute I had never heard of:  ‘aria-required’.The W3C Validator was not much help, it simply said ‘there is no attribute area-required’.  So on to Google…

ARIA stands for Accessible Rich Internet Applications, and it is currently a W3C draft. It was created by the Web Accessibility Initiative (WAI).  The ARIA specifications are designed to allow an author to properly convey user interface behaviors and structural information in document-level markup, to assistive technologies (browsers).

I then found this is a common issue with current WordPress themes.  The issue is within the templates for comments, the comments.php and comments-popup.php files.  If the author name and email address are required then the template adds the area-required attribute to these two text  input fields.  This may at first seem redundant; the template will also add the text (required) to those fields.  However, by including the attribute the assistive browser can insure the user completes those fields before they are allowed to submit the form, helping to eliminate the  confusion of an error box or error page.

The  bottom line is this is a great addition for web accessibility, and I commend the creators of the current WordPress theme templates, but the ARIA specifications are still draft.  As a purist when it comes to standards, it puts me in a though spot: do I leave it and live with pages that do not pass validation; do I use a JavaScript hack to add the attribute to the input tags so that the Validator is happy (but the final XHTML presented to the browser will still not be valid); or do I remove it?

Well, for now I have decided to leave it in the hope that the ARIA specification will be adopted soon.  I think if it helps just one of my users then it will be worth it.  But that does not mean I will stop looking for other alternatives to pass validation!

I have been advocating the use of CSS instead of tables for layout for over six years after I was convinced by several articles on the subject.  This has been considered a web ‘best practice’ for many years now, so it is very surprising that so many websites STILL use them for layout.  I see several reasons this is so:

• The continued use of old templates
• The persistence of old books and guides introducing people to web page creation
• Perfectionists who need pages to be perfect

I can really understand the continued use of old templates.  The State of California moved from a nested-tables layout to a fully CSS based template in 2007.  The old rule “if it isn’t broken don’t fix it ” can be difficult to get past when things seem to be working fine, and when time and money are in short supply.

Libraries are filled with old books from the mid to late 90s on beginning HTML.  Before CSS it was the only way to create columns and fancy positioning.  And there are also plenty of web pages that provide examples of using tables for layout.  One web site even says it is  “ideal for beginners who are not ready to learn CSS.”   I say learn it right the first time!

The last category, which I have personally run into, is the artist/perfectionist.  They design a pixel-perfect layout and then want it to look EXACTLY the same on all major browsers.  These people are inclined to use tables because it is easier to get pixel-perfect than with CSS.  Do they really think people will critique their website with multiple browsers in side-by-side comparisons, and even if they did, would they care that it is not perfect?  Actually, they do, and that is too bad.

Since I began using CSS for layout I have NEVER come across a style that can be done with tables that cannot be done with CSS.  You may need to think outside the box and perform a search to figure it out, but you can do it!

When creating a page, it can help to visualize the headings like this:

<h1> page name
    <h2> major section
        <h3> subsection
        <h3> subsection
    <h2> another section
    <h2> another section
        <h3> subsection
        <h3> subsection

And if that is not enough motivation to properly use headings, it is likely that search engines use headings when calculating page rankings.

Basically, <b> and <i> only effect the visual presentation of text, while <strong> and <em> effect the visual AND spoken presentation of text.

Visually there is no difference between <b> and<strong>, or between <i> and <em>, but an HTML screen reader interprets them differently.  If you simply want to set some text apart visually, for example, paragraph numbers or citations, then use <b> or <i>.  However, if in a conversation you would use emphasis, use <em>, or if you would use strong emphasis, use <strong>.  A visually impaired user will appreciate the effort.

• Don’t use tables for layout, use CSS.
• Don’t use font tags, use CSS.
• Don’t use <b></b> to emphasize words, use <strong></strong> instead.
• Add alternate text to all images.
• Add a “Jump to Main Content” or similar link at the top of your navigation bar.
• Use progressive headings; do not skip levels.
• Validate pages with a tool such as http://validator.w3.org/ .
• Test pages by viewing them with a text browser such as Lynx.

Web accessibility is not only the law (for government websites), it is simply good business.  What business would purposely turn away customers and invite a lawsuit? Especially when accessibility, once integrated into a website, is not hard to keep up.

Many of these guidelines are obvious, but I will provide more in-depth explanations in future posts.  I am sure I will learn a thing or two while looking for examples, and I will update and add to my list above as I do.