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 would have linked it, but I did not want to take the time to get permission first! You think I am kidding?  Here is section 11 in its entirety (emphasis is mine):

11. Linked Sites
Our Links to Other Sites: Our Site may contain links to Web sites of third parties. We provide these links as a convenience, but do not endorse the linked site or anything on it. While their information, products, services and information may be helpful to you, they are independent entities and we do not control or endorse them. You agree that any visits to linked sites are at your own risk and governed by their privacy policies (if any).

Your Links to Our Site: You are not permitted to link or shortcut to our Site from your Web site, blog or similar application, without obtaining prior written permission from us.

I have read many stories over the years about how Bill did not really understand the Internet back in the mid-to-late 90s, but if he approved this then it shows he still doesn’t understand.  Linking is at the core of the web; it is expected, even courteous, to link to sites that are mentioned.  I am not happy when I read an article that mentions another site/company/product but does not include a link so I can get the direct information without added opinion.  I cannot think of a good reason for requiring permission other than control.

Then there is the rather funny section 17:

17. System Requirements
Depending upon what you would like to do with the Foundation (e.g., if you apply for a job or grant or if you want to download certain items), you may need to make adjustments to your computer hardware or software so that you will be able to view or receive documents as intended by us. To deal with us electronically, you agree to obtain or use a system at least meeting these requirements:

Basic Requirements

1. a computer, monitor, cable or modem allowing Internet access or direct-dial accessibility, and a printer capable of printing documents (and website screens) or a hard drive capable of storing data;
2. one of these computer operating systems:
   a. Windows NT
   b. Windows 2000
   c. Windows XP
   d. Mac OSX 10.4.4
3. any of these Internet browsers:
   a. IE 5.5 (for Windows NT, Windows 2000)
   b. IE 6.0, IE 7.0 (for Windows XP, Windows NT, Windows 2000)
   c. NS 7.1 (for Windows XP, Windows NT, Windows 2000)
   d. AOL 7.0, AOL 8.0 (for Windows XP, Windows NT, Windows 2000)
   e. Firefox 1.5, Firefox 2.0 (for Windows XP, Windows NT, Windows 2000, Mac OSX 10.4.4)
   f. Safari 2.0 (for Mac OSX 10.4.4);
4. this software: Adobe Acrobat Reader 7.0 or Adobe Acrobat 5.0 or higher;
5. a printer of the ability to make, download or store an electronic copy of any contracts or legal disclosures that we may provide (such as in connection with a job application).

We reserve the right to change system requirements at any time without prior notice. If we were required to obtain your consent to dealing with us electronically and we change our system requirements, we will give notice and a right to withdraw your previous consent, if and as required by applicable law.

Is that VERY specific, or not?  When you are too specific you must regularly update your information or else it looks out of date and amateurish.  OK, it DOES say you need to “use a system at least meeting these requirements.”  So my Windows 7 system meets the qualifications, but does my Ubuntu 10.4 system with Firefox 3.6?  I think so, but does Bill?

There is more if you decide to read it for yourself, but at over 5,400 words it may put you to sleep

Anyway…I am still working on a SIMPLE terms of service, which includes only what is necessary and cannot be used as a sleep aid!

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!

I have been on the Internet since its stone age period (the fall of 1993 for you youngsters).  Back then the World Wide Web was just beginning to take off. Heck, Microsoft did not have a web presence yet, not even an FTP server!  Anyone else remember downloading Windows 3.1 driver updates from Microsoft by dialing long distance to Redmond to use their BBS (bulletin board service) by modem? Or later when Windows 95 was released and Microsoft provided updates by CompuServe?  Yes, those were the good old days (NOT!).

Anyway, back then servers for different protocols tended to be physically separate, and using a prefix to designate the type of server( www [HTTP], ftp, gopher, mail [SMTP]) made sense.   And software was separate too: you had an FTP program to access FTP sites, a browser (Mosaic) for HTTP, etc.

But things are different now. Most traffic is HTTP or SMTP, with various multimedia protocols and good old FTP hidden behind URIs.  Many web sites, including this one, no longer use the www prefix.  Sure, you can access this site with the www, but your browser will get a permanent redirect (301) to a URI without the www.  My feeling is that the www is redundant, and just makes the URI longer and harder to remember.  I have no public FTP, or anything else in my domain (yet).

Most Internet users would not even notice whether a URI they click on has the www prefix, or would even notice if the browser was redirected.  To these users the Internet is whatever they access through a browser, or browser enabled software such as RealPlayer.  Most do not even consider e-mail to be the Internet!  So, unless some new protocol comes along to challenge HTTP, I will continue to leave off the redundant www prefix on the sites I manage.

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.

The Browser Sandbox is a free service that allows you to run Windows browsers on-demand without installation, although you must install a plug-in the first time you use it.  Currently the following browsers are provided:

• IE 6, 7, and 8
• Firefox 2, 3, and 3.5
• Safari 3 and 4
• Opera 9 and 10
• Google Chrome 2

Officially this service is a demo for the company’s actualization product, but hopefully it remains available for a while.