Accessibility - Who are you excluding?

There is a lot of hype out there concerning accessibility. When I started out I did not know what accessibility was or who cared. Once I started down "The Road to Glory", by applying to awards programs, I had to find out about this subject real fast. I had no idea that I was excluding a section of the population through my ignorance. You may have noticed that points are either added or subtracted for accessibility issues. Some Awards Programs require that you achieve Section 508 compliance as a bare minimum. I decided since I was attempting to transform a "sows ear" into a "silk purse" with my wimpy little Genealogy website I couldn't really afford to give points away that easily. The first time I ran a page through WatchFire WebXact I had more errors than Carter had pills. I decided to lower my sights to Section 508 compliance and try to conquer that. AAA Accessibility seemed to be way beyond my skill level. I started out by trying to make my home page 508 compliant due to the fact it had the least amount of elements. There is a small but meaningful learning curve involved in learning to program accessibility issues out of your code and I leapt out onto that slippery slope with all the enthusiasm of a "first timer". After dabbling with 508 compliance on that first page I began to see a pattern emerging. I actually spent about 5 "spare time" hours making that page run through the validator without errors. One of my nicknames, in my past, was "The Hammer". I say that with a straight face because I had a reputation for not quitting or walking away from any issue until I had "made it mine". Programming was one of my greatest challenges that I ever faced. In the beginning I entertained the idea of becoming a "programmer". When you meet someone and they tell you that they are a "Computer Programmer", that carries some weight. You look them in the eye and they appear to be "all knowing". It's almost like you are talking to someone who was in on inventing computers, sort of like the "Wizard of Oz". My first professor told me that I was "a natural" at programming. I was the oldest person in class and one of only three Caucasians. Initially it was an intimidating experience. Through programming I learned a lot about myself. Your brain is the most powerful muscle in your body and becomes stronger the more that you use it. It taught me that the learning curve for life is never ending and you really never quite reach that plateau where you can just relax on your laurels. I went in to Computer Science to learn Java Programming and stayed with it until I had a firm grip on that and then dropped the "Computer Programmer" idea after learning how tedious and monotonous it really is. I realize that someone has to do it but it wasn't fast paced enough to hold my interest. Now that I have a background in programming I can read the "syntax" easily and come up with valid solutions. I began to notice that my mistakes were, if nothing else, extremely consistent and therefore easy to spot and fix. I have worked with the validator to the point that I can write the mark-up to reflect Level A, AA, AAA Accessibility and only use it to catch the "stupid" mistakes made from going too fast. Well, enough of the primer , lets dig into this thing and see what it is all about.

The basic issues of accessibility.

The first thing to look at is the combinations of font - size, color, family, and background colors that makes or breaks the first three choices. You have to examine what it is that you are actually trying to communicate and why. Fonts of different sizes and families usually don't work for accessibility. Consistency with font-size and font-families "Rule" as far as accessibility issues go. Keep in mind that there is a whole spectrum of disabilities out there and while considering every one of them would be impossible, considering a majority will give you a lot of personal satisfaction. When they developed the Web Access Initiative (WAI) it gave us something to aim at and it also gave some folks the hope that accessibility would be forthcoming so they could be informed, using the internet, just like everybody else. Most Award Programs are promoting accessibility and that is a great thing. It has to start somewhere. If not for the Award programs it would have never gotten to be a consideration for me and, I suspect, for a lot of other people as well.

The first topic will be tables.
These are actually quite easy to deal with. For the most part you only need to add a table summary to make it validate. Speaking of validation it is an extremely good idea to have your mark-up validate as most accessibility validators will fail your page if the mark-up does not validate. An example of a table summary might look like this:

Generally speaking you can populate the summary or leave it blank depending on the validator that you are using. I prefer to use Watch Fire WebXact but I have also found a couple of good alternatives and one of them identifies every table as a "lay-out" table and requires the inclusion of the summary attribute but will give you an error if you enter a description into the summary. Some alternative "free" accessibility validators are located at:
The University of Toronto at http://checker.atrc.utoronto.ca/servlet/Submit and at
OCAWA - Web Accessibility Expert at http://www.ocawa.com/en/faireaudit.htm.
Notice that I am not giving you a link to either of these validators. They have both been responsible for giving me errors when I run this page through the validator. This wouldn't be much of a tutorial if my pages did not pass through the validator, without errors, and deliver an A, AA, AAA level of accessibility, huh? They will give me an A and a AAA level but not the AA level because the links sometimes "timeout". You can copy and paste these addresses into your web browser to visit the sites. The first validator is tough but it gives you examples on how to fix your problems, a lot like WatchFire WebXact. The last validator website also has a download that can be used with the FireFox browser and can be used on demand, way cool. The only drawback on the first one is that you have to select your level of validation frequently as it regularly defaults to a lesser level than the WAI WCAG 1.0 AAA level. The upside is that you can test the file on your computer before you upload it to your sever.

The next topic is navigation.
This is a biggie. You can usually achieve single A rating no matter how you display your navigation. As you can see I am writing in XHTML 1.0 and I am also achieving the triple AAA rating for accessibility as well, why not?
One of the first things that came to light was "you cannot use the same link text" to point at different targets.
You have to be very careful how you display navigation links in general.
The easiest way to build menus, or display two or more links in close proximity, is with lists either ordered or un-ordered. You cannot use white-space to separate links so you end up using the square brackets or pipes to separate. What I am aiming at here are the problems you will run into using tables to contain your navigation. The validators will see your links running together without any sort of separation . Line breaks <br /> are out of the question as well.
It can be done but it becomes complex to style it to the point that you can pass the AAA validation. I built the tables on my Rated Awards pages and spent a lot of time and effort making them beautiful AND functional and in valid XHTML 1.1. Then I ran them through Watch Fire and had them come back with LOTS of errors. I studied the situation and decided that rather than totally rebuild the tables that I would go ahead and "fix" the problems using the old tables. I created a CSS class called <span class="disappear"> and applied it to the elements I wanted to become invisible so as to maintain the original look. I believe that the way the table looks nobody could become confused with what my intentions are in that presentation.
Speaking of the "Return to top" navigation element. You will run into issues if you use the <a id="top"> attribute. This will give you an error in the accessibility validator. To fix this I added <h1><a id="top"></h1>. Ta Daa, this will pass validation but now appears to make no sense to me. How intelligent is that looking to you? I used this for a while because it worked. I took a close look at this issue one day and came up with a bulletproof solution that makes sense. It's simple, instead of the previous code snippet use <div id="top"> instead and it validates easily. It makes sense and you still use <a href="#top"> to get there.
Using JavaScript for navigation. The "return to top of page", "history+1" and / or "history-1" all appear to work flawlessly and are seen quite extensively. I believe that the more JavaScripts that you use the less accessible your pages become whether they validate or not. Keep it light. If you use JavaScript for your page navigation you must also provide a text navigation menu as an alternative.
Next we will touch down on JavaScript Pop-up windows on the next page of this tutorial.