CSS, JavaScript and XHTML Explained

Quirks, random thoughts and funky finds discovered in day-to-day coding.

 

Introduction to Firebug June 28, 2007

Filed under: Browsers, JavaScript, Web Development, firebug — Estelle @ 9:58 am

A Firebug Tutorial

This is an overview of the plugin, not a detailed explanation of all of it’s amazing features. This should be enough to get you started.

Installing Firebug

Firebug works with Firefox. There is a product called Firebug lite which you can include in a file via a javascript call in your file, for use in non-Firefox browsers, but I am not covering Firebug lite in this tutorial/overview.

To install Firebug visit the Firebug download page. Click on the huge orange button half-way down the page on the right hand side. You can also download it from Mozilla’s FireFox Add-ons site. Install it. Restart FireFox, and you’re good to go.

If you’ve already installed it, get the latest version! To update your extension, in Firefox select Tools > Add-ons. Then click on the button in the left hand bottom corner that reads "Find Updates".

Opening and Closing Firebug

Keyboard and Mouse Shortcuts for Firebug can be found at the Firebug Website. The three sets I use most often include:

  • Open Firebug: F12 or clicking on the green check mark at the right of the right of the browser status bar.
  • Close Firebug: 12 or clicking on the green check mark at the right of the right of the browser status bar or clicking on the red x in the upper right hand corner of the firebug window.
  • Undock Firebug into its own window: click on the red up arrow in the top right corner of the firebug window or Ctrl+F12 / ⌘+F12.

Firebug settings

  • Set Firebug to always undock in a separate window: open the firebug console. right click on the firebug in the upper left, select "options", then select "Always Open in New Window"
  • Increase/Decrease font size: open the firebug console. right click on the firebug in the upper left, select "Text Size". The font changes are really slight, but it does work.
  • Set Firebug to only work for specified sites: Start by disabling Firebug by right clicking on the green check mark and selecting "disable Firebug". Then right click on the greyed out icon and add the domains you want to enable Firebug on.

Firebug Window Overview

  • Console Tab: Contains command line javascript, shows javascript error message log, can enter JavaSript commands after the >>> at the bottom
  • HTML Tab: Shows HTML as an indented hierachy of DOM nodes, which you can open and close to see or hide child nodes.
  • CSS Tab: CSS inspector, view all loaded style sheets, modify styles on the fly. See list of styles sheets and select one to view from this pane by clicking on the drop down list on the top of Firebug window, to the right of "Edit".
  • Script Tab: Shows the javascript files and the calling document. See list of included JavaScript files and select one to view from this pane by clicking on the drop down list on the top of Firebug window, to the right of "Inspect". Set breakpoints and conditions underwhich break points appear.
  • DOM Tab: Shows all the page objects and properties of the window. As variables are properties of the window object, Firebug displays all JavaScript variables and their values.
  • Net Tab: Shows all the downloads, how long each resource took to download, the HTTP request headers and server response sent for each resource. The XHR tab is useful for AJAX debugging.

Edit your document on-the-fly.

You can change text nodes by selecting the text node with the "inspect" function and then clicking on the text node in the HTML panel.

Firebug is both an inspector and an editor. All objects in the HTML, CSS and JavaScript files can be edited with a single or double click. As you type, the changes are immediately applied in the browser window providing instant feedback. The DOM inspector allows for full in-place editing of your document structure, not just text nodes. Simply click on the "edit" tab next to the "inspect tab", and the left panel becomes a black and white text editor. In the CSS panel, Firebug autocompletes as you type. In the DOM inspector, Firebug autocompletes property names when you hit the Tab key.

Inspecting and troubleshooting CSS using Firebug

DOM inspector’s CSS tab reveals all applicable CSS rules for elements, including properties inherited from ancestor elements, lets you toggle on/off and edit individual style declarations and add new CSS rules.

Firebug hides rules that Firefox ignores: For example, Firebug will hide hacks targeting other browsers and CSS3 selectors that it doesn’t support. So, it will both hide intentional CSS filters, such as _height:25px; (the underscore is an IE6 hack) and p:first-of-type {color: #ff0000;} (a CSS3 :first-of-type pseudo-class selector currently supported only by Safari 3). This means, however, that if the reason your page isn’t looking the way you anticipated is because of a typo, you will need to use the developer toolbar to show all CSS and find your error.

Firebug shows all selectors impacting the selected element: When you inspect an element or node, Firebug displays the entire cascade of all the CSS attributes impacting that element, including attributes that were overwritten in the cascade. The right panel displays the selectors and attributes impacting the element in order of the cascade.

Firebug allows you to turn off styles impacting an element within the CSS: When you turn off an attribute, if that attribute value was overriding a different value in the cascade, the formerly crossed out value will become active so you can test what the page would look like if the attribute value were removed. To "turn off" an attribute, click to the left of the attribute in the right hand panel. A red "do not" icon do not will appear, and the attribute will be grayed out or disappear, and the strike-through of the new attribute value effecting the element from the cascade will be removed. You can toggle the attribute value back on by clicking on the do not. However, if the attribute has "disappeared" since it’s been overwritten, you have to re-inspect the element to see the missing attribute and toggle it back on.

Firebug allows you to edit attributes and attribute values: To change an attribute or the value of an attribute, click on the term or value, and edit it. Pretty simple! The effect of the change will be immediately visible in the browser window.

One of the best components of this feature is figuring out exact positioning, padding and margins. Firebug provides wonderful support for changing numeric values. Simply click on the numeric value you want to change and change it with the numbers on your keyboard, or click on the up or down arrow to increment or decrement the value by one.

Firebug allows you to add new attribute / value pairs to existing selectors: To add an attribute to a selector, double click on the selector. An input box with intelli-sense will appear. Hitting tab will bring you to a value text input box.

Firebug allows you to easily inspect ancestor elements: To the right of the keyterm "inspect", Firebug displays all the ancestors of the currently selected element. To inspect an ancestor, simply click on it in the list. The left and right panels will both change to display the properties of the newly selected element.

The Box Model: Evaluating Height, Width, Padding, Border and Margin

When you inspect an element, the left panel displays the HTML, and the right panel shows the CSS. Next to the CSS label at the top of the right panel is a tab labeled "Layout". This Layout tab illustrates the CSS box model as it applies to the selected element. To view the height or width of any other element on the page, simply select "inspect" while this window is open and hover your mouse over the inline or block level element you wish to inspect.

Evaluating download speed

The Net tab graphs the request times for all http requests that make up a page. Network monitoring must be turned on for the Net Tab to work, but it’s on by default (the options drop down on the right hand side of the firebug panel allows you to toggle this feature off and on). This is a handy way to test (and prove) that putting your javascript files at the bottom of your files, especially for javascript heavy pages, improves perceived download time. Total download time will be the same, but since browsers stop loading pages when they hit scripts until the scripts have been downloaded, the page will appear to download faster, which is a better user experience (see list item 5).

By left clicking on the plus sign to the left of the file name, Firebug displays the HTTP headers of each file that was downloaded.

In the 1.0..5 version of Firebug you can see how long it takes for HTML files only to be downloaded, CSS files only, images only, etc., or all files. YSlow, Yahoo!s performance tool, should be available as a plug in for Firefox by the end of the summer. In the meantime, Firebug’s Net tab is the next best thing.

JavaScript

The DOM inspector provides information about all the properties of all the objects in your document. The coolest feature of Firebug is that while making dynamic updates to your page will not alter the content visible in the "view source" feature of the browser, it will update the content in the Firebug panels. So, dynamically created content is visible not only in the browser (as it should be), but the generated code is inspectible (is that a word?) in Firebug.

The JavaScript profiler reports on the execution times of your JavaScript functions, so you can pin down performance JavaScript components that are slowing down your pages or javascript applications. To view the profiler, the submenu should be on "console", and click on "Profile" in the top menu (the order of the tabs is "Inspect |Clear | Profile"). Firebug lists all the functions that were called and the time spent for each function call. You can target what function you want Firebug to profile by adding console.profile([title]) to the start of the section your want profiled, and console.profileEnd() at the end.

The command line at the bottom of the console tab, which starts with ">>>" accepts commands in JavaScript. The results or your javascript command, if there are any, are then displayed in the console. There is a Firebug Command Line API that is worth taking a look at.

AJAX

As mentioned above, Firebug captures dynamic content and other DOM changes made to your webpage. If you take as an example the sample file created in my tutorial Beginning AJAX using the YUI Library, if you check the view source after calling the function (click on the link) via the browser’s functionality, you’ll only get the link that calls the AJAX function. If you view the source via Firebug, Firebug reflects changes made to the DOM, and includes the "Hello World" content. This is one of the core strengths of Firebug: without Firebug, AJAX requests and responses are invisible. With it, you can view the sent and received text as well as the headers that went along with it. You can also monitor how long it took for each request/response with the Net tab.

You can see XHR response by clicking on the Net tab, and then the XHR tab in the sub navigation that opens up when you are in the Net view. While the All Net tab is like yslow, the XHR focuses on the AJAX only. If you click on the plus sign to the left of the response file, you can see both the headers and the content of the response.

Details of the Net tab’s XHR sub-tab

When a request is made to the server via a XMLHttpRequest object, Firebug logs the POST or GET request, the response headers and the raw text of the response. To view this data, click on the Net Tab’s XHR sub-tab. This will show a list of the calls and the time it took for the response. To the left of the request click on the + or simply click on the request (it is a link). Three tabs will appear in the case of a GET request, four for a POST:

  • Params: Displays the name/value pairs of the request URL
  • Headers: Displays requestion and response headers
  • Response: Shows the actual data received from the server as it was received.
  • Post. Displays the data sent to the server from a POST request (tab only shows for POST requests, not GET requests).

These four tabs are useful in development and debugging. Check the POST and Params tabs to ensure your request are being correctly posted. Check the Response to determine the format of the response and ensure that your JavaScripts are written to handle that formatting. If you don’t control the feed that you are fetching, you can copy and paste the response into a text editor, format it so it’s human legible, and work that way.

Debugging AJAX and other JavaScripts

To debug AJAX, it’s similar to how you debug JavaScript above, except for the console.log is even more helpful, since you are reloading components of the page and not the whole page (reloading the whole page resets the HTML, JS and CSS to what is defined in the static files). Firebug provides the console object that has several methods usable for logging. Properties of console object include console.debug, console.info, console.warning, and console.error. When one of these methods produces an output, Firebug links to the line causing the output so you can quickly find the responsible code.

One of the other ways to debug is to set breakpoints (yay! no more alerts!).  The "Script" tab allows you to pause execution on any line. Clicking on the line number in the script tab sets a breakpoint.  You can make that breakpoint conditional by setting a statement that if true will trigger the breakpoint.  Simply right click to the left of the line number to set an expression (where you had left clicked to set the breakpoint) or right click on the line and select "Edit breakpoint condition": "this breakpoint will stop only if this expression is true" is the message you should see. You can contine, step over, step into or step out of a line. The right panel has a "watch" tab where you can inspect the value of local variables (click on objects to view their properties). Hovering over an object in the script activates a tooltip that displays the object’s properties.

Problems with Firebug

Webpages never finish loading: likely because there is a javascript error in the page, and Firebug has put a breakpoint at the error and halted the script.

Firebug crashes my Firefox some of the heavier Web 2.0 sites that I visit, like Netflix and Yahoo! Mail. Firebug keeps track of all the errors. This can use up a lot of memory and crash the browser. Also, likely irrelevant, but SoThink SWF makes Firebug crash FF.

Solutions:

Disable Firebug for a particular domain: Unless you develop for a site that crashes your browser, you can simply turn off Firebug for a domain/subdomain.. To turn off Firebug, right click on the green check mark (or red x if there are errors) in the status bar and select "disable firebug for thisserversname.com".

Disable Network Monitoring: Sometimes disabling Firebug for a particular domain is not an option . For example, I code a small part of a much larger internet application which throws errors and therefore never finishes loading, but disabling Firebug is not an option since I am working on that page.. To resolve this issue, click on the Net tab. When on that tab, to the far right you will see "options". Select "Disable Network Monitoring". Since I have selected that, I no longer crash my Firefox, and can work on the website I need to work on. (I did update my Firebug, and that might have helped the issue too. Not sure.)

Update Your Version of Firebug: Firebug is continuously being updated and bugs are being fixed. To update to the latest version of Firebug, in your FF browser window select Tools > Add-Ons > Find Updates, and FF will check for and install upon request, the most recent release of Firebug and all of your other FF extensions.

Notes:

  • Firebug 1.05 and earlier do not work with Firefox 3.0, currently in beta
  • Joe Hewitt developed Firebug and offers it for free. Consider giving him some love in the form of money.
  • For more in depth view, view Joe Hewitt: Welcome to Firebug which I included below. The above tutorial is more of what you definitely need to know. The video covers the more advanced features. Take a look at it if my overview doesn’t provide enough info, especially in the area of JS debugging and XHR debugging.
 
 

Targeting Safari 3 with CSS and JavaScript: Safari3 Hacks & Filters June 22, 2007

Filed under: Browsers, CSS (including hacks), Web Development — Estelle @ 1:14 pm

See also Safari 3.0 CSS3 Support

CSS Filter: Safari CSS Hack

Not that Safari 3.0 on Windows is a grade-A browser yet, and not that I have figured out any reasons to need to hack for this browser yet, but two good potential CSS filters include using :first-of-type and -webkit-min-device-pixel-ratio.

:first-of-type

Safari is the only browser that seems to understand the :first-of-type pseudo class. Safari fails only in that if you add a siblingnode of the same type with javascript prior to the first of the type, safari will target both of the elements instead of just the new one. That failure shouldn’t be a concern in 99.999% of the cases.

To target Safari, simply code:

body:first-of-type p {color:#ff0000;}

Notes

  • :first-of-type is a CSS3 selector, and as such, other browsers will eventually start supporting it, and will therefore be targeted by this filter. In other words, while this is a simple method to target Safari 3.0 to the exclusion of all other current browsers, it is not future proof.

-webkit-min-device-pixel-ratio

Safari added the feature, device-pixel-ratio, that determines how a CSS pixel relates to a device pixel. This CSS3 media query allows for the inclusion of a separate CSS file:

<link rel="stylesheet" media="screen and min-device-pixel-ratio: 0" href="safari3.css"/>

This "if" statement includeing min-device-pixel-ratio will return "true" for Opera 9, Firefox 2.0 and Safari 3, so while it’s a good solution for omitting IE, it won’t work for targeting Safari 3.0 only. 

@media screen and (-webkit-min-device-pixel-ratio:0){
                p {color: #00ff00;}
}

The above syntax is more browser specific, and targets both Safari 3.0 and Opera 9. The benefit of this filter/hack over the :first-of-type pseudoclass is that since CSS3 is supposed to support device-aspect-ratio and possibly device-pixel-ratio the -webkit portion of the syntax will likely not be supported by additional browsers in the future. In other words, it seems like a more future-proof solution than the :first-of-type, even though :first-of-type is a more browser specific solution at the moment.

Notes:

  • Webkit is basically the "opensource" framework that is the basis for the Safari browser, so -webkit is not standard.
  • For more on Safari and DPI visit Webkit’s High DPI Web Sites blog entry.
  • In the Opera CSS support list ,device-aspect-ratio and min-device-aspect-ratio are listed as supported. Although not listed, Opera supports media query device-pixel-ratio when tested.

Targeting Safari 3 with JavaScript

Safari is the only browser that supports the window property devicePixelRatio. So, similar to that old fashioned document.all, you can browser sniff this way:

<script type="text/javascript">
   isSafari3 = false;
   if(window.devicePixelRatio) isSafari3 = true;
</script>

Hedger Wang provides a sample in his blog.

Notes:

 
 

Making the Web Accessible June 16, 2007

Filed under: Accessibility, Best Practices, Web Development — Estelle @ 7:19 pm

Web Accessibility / Section 508 Guidelines

Making your site accessible

Web accessibility is the ability of users with various functional requirements to use web sites easily and effectively. This includes keyboard access, screen enlargement, screen reading and voice recognition. If you don’t think this is important, just remember that your two most important visitors are blind, deaf and unable to use a mouse: googlebot and slurp, Google and Yahoo!’s spiders, can only read the text of and tab thru your page. They can’t see your cool mouseover effects, interpret the nuances of your images, or enjoy your nifty sound effects.

Below are brief rules to make your site accessible. After the table of contents below are methods to ensure that your content is visible to users, but to considered compliant that content must be presented in an accessible manner. The list below should get you 90% of the way there. The rest addresses specifics to ensure complete access.

Here are the brief rules:

  • Content that is well written will be easier for everyone to access including people with cognitive and learning difficulties. Content should be short, simple and well organized. Paragraphs should be brief with one key idea per paragraph. Make sure there are no spelling or grammatical mistakes.
  • The language of the content should be defined using the "lang" attribute. In addition to defining the language for the document, all changes in the primary language of the page should be indicated. Provide definitions/explanations of technical terms, abbreviations and acronyms.
  • Each page must have a unique title element, which relates to its content. Use meaningful headings and subheadings. Page headings and sub-headings should be defined using <h1> to <h6> heading structure. Correct mark-up should be used for lists. Sub-lists should be nested properly. Content should appear in paragraphs or list items: avoid anonymous (tag-less) text.
  • Users must be able to reach and trigger all links, forms and functionality without the use of a mouse. Additionally, the text of links and the "alt" attributes of image links should make sense when read out of context.
  • Start with accessible content by first coding your page in XHTML first, with no presentation (CSS) or interactivity (Javascript). Then add the presentation (CSS) and behavioral (JavaScript) layers with external stylesheets and scripts. Think "Web Standards": if your site is semantically coded, it will likely be accessible.
  • Do not target assistive technology with display: none, as that will hide the content from all users with CSS enabled, including screen readers. Instead position the hidden content off the page. Do this wisely as form elements and links positioned off the page can still receive “focus” by use of the keyboard.

Assistive Technology

Screen readers are a form of assistive technology.  A screen reader is software that sits on top of other applications, reading aloud what other sofware displays to the screen. While web developers often think of screen readers when developing accessible website, we need to remember that screen readers are not the only assistive technologies that may be used with your site: users can magnify your site, use the browser to increase font size, visit your site with refreshable braille display devices or print your pages with braille printer, navigate your site with a keyboard or apply their own style sheet to your site.

Section 508 guidelines and other tips to making your site accessible

The WCAG (Web Content Accessibility Guidelines 1.0) recommendations were written in 1999, so are a bit outdated. The following is based on their recommendations and updated to reflect modern web standards and Web 2.0. The WCAG 2 guidelines are still in draft form, but are nearing completion. You should find this page more helpful and easier to understand than the official guidelines.

Below are guidelines to consider when developing websites. While the W3C calls these "guidelines", they should be considered "rules". Following these guidelines will not only help make your website more accessible to those with disabilities of various sorts, but your site’s search-ability will improve, your site will likely function on alternative media such as cell phones, you’ll be considered a really good person and you’re site will be legal in all the countries that require sites to be accessible.

Text Equivalent for images and animations:

A text equivalent for every non-text element should be provided (e.g., via "alt", "longdesc", or in element content).

alt attribute: alternative text for images

The "alt" text attribute provides a title or descriptive phrase about the image it accompanies. The "alt" attribute should describe the content of the image. Describe the image, but don’t start with "This is an image of…". The user already knows it’s an image. If you don’t know what alt text to use, imagine reading the document over the phone: how would you describe the image to the person on the other end? Alt attributes are essential for users of reader software who are vision impaired, it is valuable for users of graphical browsers who have "load images" turned off (which many cell phone users do), and it helps you should your image fail to load. It is also useful for users of text-only WWW tools like Lynx and some cell phone browsers. While some images formats, such as PNGs, allow for the inclusion of meta data describing the content, no browser or reader supports this function, so while you may include the data for future comatibiltiy, you can not rely on it for current compatibility. If I haven’t convinced you of the importance yet, it also helps with SEO, since search engines have no way to "read" your images.

There are 2 circumstances in which null or empty alt attributes (alt=””) may be used: layout images and images that are included within the same anchor tag as a textual link. If you are a web standards oriented web developer then you likely will never have empty alt attributes. Why? Because good web developers use background images, not layout image. And good web developers use background images (and sprites) instead of link foreground images.

longdesc attribute: long description for images and media

The "longdesc" attribute can be essential when an image conveys important information such as a pie chart or a scientific discovery. The longdesc is a link to a separate text only page containing a longer, text only, description of the the image. If the contents of the image are described within the text content of the page, a longdesc is not necessary.

Multimedia:

Equivalent alternatives for any multimedia presentation should be synchronized with the presentation. In English, when including multi-media components in your web page, such as a flash movie, an animated gif, a video clip, etc., the alternative text describing the contents of the media should change as the presentation changes. Any dynamic changes occuring in the multimedia content (either in a <frame>, <img>, <object>, or <script>) must also update the "alt" element when it changes.

Implementation of this web accessibility requirement include captioning and transcriptions of any spoken audio in the media (think "hearing impaired"), and text descriptions of the visual changes (think "visually impaired"). You do not need to include captioning for non-informative sounds, such as background music. But include captioning for all sounds that convey meaning in the audio, including all spoken words and background sounds, such as a window breaking, and even words to a song, if the sound or song lyrics are necessary in conveying the meaning of the multimedia component.

Color:

Don’t convey information with color only

Web pages should be designed so that all information conveyed with color is also available without color. For example, my chart of browser CSS support uses color to show various levels of browser support. Without color this chart would be completely useless were it not for the semantic markup of checkmarks, deltas and exes providing reduntant data. Visual color cues should not be the only way of conveying information, as had I only used color in this chart, not only would this page be a challenge for color blind users, but users accessing this page via cellphones, Lynx, with CSS turned off, and with Safari (there is a typo in the page that i have yet to fix, so the colors don’t show in Safari) would be completely unable to use this chart.

Use enough contrast in your web design so your site is readable for users with color blindness.

In developing your web pages, choose text and background colors to provide maximum contrast. Page design must present a clear contrast between foreground and background colors. Many people think that color blindness means that sufferers see the world like a black and white TV. This form of colorblindness does exist, but is extremely rare. Color blindness, though, is not rare. Thirty percent of all males suffer from some form of color deficiency rendering colors as grays or spreading one color across several others.Contrast is also very important for individuals who can see but have reduced vision. Is your text green and are your links of a similar hue with no text decoration? Take a look at your website as with simulated color blindness.

In developing the site, do not include any HTML color on the page. All the colors should be controlled via external style sheets. This allows the user to implement their own style sheets and color palette.

Style Sheets:

Documents should be coded semantically, included coding the text in an order that makes sense if it is read without a style sheet. Headers should be used for headers, lists for lists, paragraphs for paragraphs. This helps not only for humann accessibility, but enables your pages to be accessible to search engines. Separate your presentation, or "style", from your content. All your style sheets should be external. Do not include inline styles. Do not use !important.

All text should re-size relative to browser font size settings: use ems instead of pixels in declaring font-size. If you declare font size using pixels, IE6 will not change the font size when the user chooses to change it via their browser. IE6 does respect relative font sizes, which is why ems are recommended instead of pixels. Percentages work as well, but they are a wild beast to tame when it comes to the cascade and cross browser issues; so use ems. (WCAG 3.4: Use relative rather than absolute units in markup language attribute values and style sheet property values. Priority 2)

Language:

Natural Language

Indicate the language of your content. If the page is in English, French, Spanish or Urdu, you need to let the browser know. The screen reader uses this information. Google uses this information. If you then use a different language within the page, indicate that the language has changed for that section of the page. (WCAG 4.1 - Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions). [Priority 1]) In print, foreign language quotes are usually displayed in italics. Similarly, you should use the lang attribute to indicate language. 

<p>I had another <span lang="fr">deja vu</span> last night.</p>

Using the lang attribute you are informing the screen reader to use alternative pronunciation, informing braille translators to not contract letters, and allowing the Babel Fish translator how to interpret individual chunks of content.

Language Level

Use the clearest and simplest language appropriate for a site’s content. If you are writing a children’s site, use first, second or third grade level language as appropriate. If you are writing for the general public, use the simplest language that isn’t pedantic. Generally, the eigth grade level is appropriate. If you are writing a scientific journal article, or a technical article, use appropriate terminologogy without being needlessly complex.

Try to remember what you learned in your middle school English classes: describe what you are going to talk about in headings, and state your subject or theses of your paragraph at the beginning of the paragraph or section, and limit your paragraphs to one main idea.

Abbreviations and Acronyms

Specify what each abbreviation or acronym in a document means. Although the WCAG recommendations state that you should expand the term only where the first abbreviation or acronym occurs, your visitor may be visiting your page thru an anchored hyperlink, thereby missing the defintion. You don’t have to expand all abbreviations or acronyms: expand ones that could be helpful to the user, and don’t expand ones that are used in everyday language. For example, we all know the definitions is for TV, DVD is it’s own definition and who knows what it really expands to. If you’re going to use THC you need to expand it because you’re likely defining it, and few people remember that it means Tetrahydrocannabinol. You will want to define it the first time you use it for all users, and use <acronym title="Tetrahydrocannabinol">THC</acronym> for all other occurrences within a page. If you are going to use an acronym that is commonly used and not easily misconstrued, such as HTML, expand it the first time it’s used: if a user doesn’t know what it means, they can look for the first occurrence.

Server-side image maps:

Likely not an issues for most developers, and server-side image maps have become almost obsolete. Most sites have moved away from server-side image maps. The exception is for such things as geographical information system clickable maps. So, if you insist on a server side image map, redundant text links should be provided for each active region.

Client-side image maps:

Include the alt attribute for each map area. Also include the alt attribute (duh!) in the image. Client-side image maps, unlike server side image maps, are generally accessible with just a little code, so the recommendation is to include client side image maps instead of server-side images maps. Modern browsers support client-side image maps, with the addition of "alt" attributes for the image hot spots, assistive technology readers can provide additional clues. However, if the user has "load images" turned off, the only approach is to provide alternative links. So, include an "alt" attribute in each and every hot spot.

Data tables

Tables should only be used for tabular data. Don’t use tables for layout. Again. Don’t use tables for layout.

Row and column headers should be identified for data tables.

Using row and column headers — <th> instead of <td> — becomes crucial when a table is larger than two columns or two rows. Without the headers, assistive technology such as reader software can only recite the table contents with no reference to what that column or row pertains to.

Multi-logic row or column headers

The <thead> and <tbody> tags should be used to differentiate between the data table header and the data table body. Markup should be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. Additional information such as "summary" and "scope" can be applied to data tables to render their contents and intent meaningful to users of assistive technology. The "summary" attribute should summarize the data that the table contains. "Scope" can be very useful for column headers. For simple data tables, the “scope” attribute should be used to differentiate between row headers and column headers. For complex data tables, each data table cell should be explicitly associated with its relevant table header. To do this, add an “id” attribute to the <th> tags and reference this id by using the “headers” attribute within each <td> tag.

Frames

Don’t use frames, especially complex frame sets. But, if you are going to use frames, title frames with text that facilitates frame identification and navigation. If you do use frames (please don’t) include a “title” attribute that accurately identifying its role or purpose. With the "title", "name" and "longdesc" attributes, frames can be made more navigable for reader software, but they still shouldn’t be used. Iframes are o.k.  Use the title attribute for iframes.

Flicker Frequency

Unless you are aiming to be on http://www.websitesthatsuck.com, you shouldn’t have flickering on your website.  But, if that is indeed your goal, design pages to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. Flicker and continuous motion (as from applets or scripts or from refreshes) can cause seizures in individuals with photosensitive epilepsy. Try not to use time-sequenced elements. If used, choose your timing carefully.

Text only equivalent

Provide a text-only page, with equivalent information or functionality to make web pages accessible when compliance cannot be accomplished in any other way. The content of the text-only page should be updated whenever the primary page changes. Only resort to alternative pages when there aren’t any other ways of making your pages accessible. An out-of-date page is as frustrating as one that is inaccessible since, in both cases, the information presented on the original page is unavailable. Before resorting to an alternative page, reconsider the design of the original page.

Making Scripting languages accessible

When pages use scripting languages to display content, or to create interface elements, the information provided by the script should be identified with functional text that can be read by assistive technology. The easiest method to provide this accessible alternative is to write HTML code which includes the <noscript> tag. Other options include ensuring that dynamic content and refreshes can be made or are accessible.  Some will argue that the <noscript> should not be used; and I definitely understand their rationale, since the <script> should be external making <noscript> moot.  However, there are certain cases where it does make sense, so I won’t say "don’t use it."

If you are using javascript and have a "return false" as an event for the onClick event handler, the link’s href should redirect to a page where the required effect. Do not use <a href="#" ....> or <a href="javascript:.....>. Instead use <a href="validURL....>. If you have an X as a link to hide a div on a page, clicking on the link to with javascript turned off should redirect the user to a page with that div hidden.

According the the W3C, you should use event handlers in pairs for mouse users and keyboards users: using "onmousedown" with "onkeydown", "onmouseup" with "onkeyup" and "onclick" with "onkeypress", but since most sites aren’t accessible, many users who are unable to use mice actually set up a key to act like a mouseclick, and using onkeypress can override their settings. So, it’s important to make sure that any event that is required via javascript is also available to those without javascript.

Accessible AJAX

Screen readers are not informed when an AJAX or DHTML implementation dynamically changes the content of the page. AJAX is considered accessible if it doesn’t change the content of the page to any extent other than enhancement, or, if it does change the content of the page, that the user is informed of a change by a means other than a visual cue. When content is dynamically changed, the new content should receive focus to inform the user that the content is new. However, only form elements and links can receive focus.

There are two suggestions for making AJAX more accessible

The suggestion first is to make the screen reader know there new content by giving a tabindex value of -1 to the new elements unable to receive focus. Although -1 is not a valid tabindex value, it is able to receive focus with JavaScript, but will not be placed in the tab order, which makes it findable to screen readers but will not cause problems for keyboard navigators. To make dynamic content available, give focus to added content via the tabindex using javascript.

The second suggestion is to use the role attribute. Not just in with AJAX, but with everything in Web 2.0 applications, anything can be a button or a control interface (like a slider or container). The accessibility problem is that there’s no way for a screen reader to know about the functionality of those elements. The XHTML role attribute enables the addition of semantic information to the containing element.

Applets, Objects, Plug-ins

When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page should provide a link to a plug-in or applet that complies. Objects and data which require plug-in applications can be presented in HTML code in a nested manner such that, if the user’s browser can’t display the topmost data type, it will attempt to display equivalent data type in the object specification. This is more complicated HTML code to create and requires several data types to be resident on the server, but it is a more complete method of inclusion which favors neither advanced nor dated browser technology.

Forms

When electronic forms are designed to be completed on-line, the form should allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. If you are going to dynamically submit the form based on user action other than clicking on a submit, ensure that the form is still submittable with javascript disabled.

Also, every form field should have a label element that is uniquely associated with it using the “for” and “id” attributes. Where a textual label does not fit into the visual design of the page, the field should still have the label hidden through CSS. Remember that you should not use display: none, as that will hide it from screen readers as well.

Content tracking

A method should be provided that permits users to skip repetitive navigation tasks. There are a number of methods of facilitating navigation for users of assistive technology. Be consistent in page-to-page design, designers can provide a jump-link to bypass a series of links on a page similar to the "back to top" used in long pages, when using multiple links close together, separate the links so the reader software can parse it correctly. For example, use list items or separate text links with a pipe (|). Links should be referenced with text which make sense if a user if link-jumping. Also, consider adding a site map, which is useful to nearly everyone.

Links need to be contextual and real

Contextual Links
Links need to mean something. Can you images tabbing thru a list of "MORE", "MORE", "MORE" with a screen reader. While your designers and marketing team might insist that your links look meaningless, you can still make meaningful links with XHTML and CSS.

The XHTML content will look like this:

<a href="link.html">MORE <span class="accessibilty"> on Contextual Links</span></a>

and the CSS looks like this:

a span.accessibility {
   position: absolute;
   left: -2000px;
   }

In this manner, visually it looks like just the word "MORE", but to the screen reader the purpose of the link is visible. Do not use visibility: hidden; display; none; as hiding from the screen also hides it from the screen reader

Real Links with Real Destinations

All <a href=" ... should link to a real URL or a real anchor.
If you have a link with an event handler that retrieves content via AJAX, the href of that link should redirect the user to a page that contains the content that would have been retrieved. If you don’t have a destination for the link, don’t use a link.  You can add event handlers to any object in the DOM, not just links.  The best way to understand this concept is to turn off javascript and make sure that all of your links are indeed links. If you are including an element simply to create a dynamic effect, consider employing a span with an event handler attached instead of a meaningless javascript:void().

Timed Response

When a timed response is required, the user should be alerted and given sufficient time to indicate more time is required.

Validation

The site should validate. You can validate your web page here.

The "Role" Attribute

In Web 2.0 applications, when an HTML element such as a form element is converted into a button or a control interface, there is no way for the screen reader to understand the conversion and the functionality of the converted element. The XHTML role attribute enables the addition of semantic information to converted elements.

<p class="note" role="note">
<ul role="navigation">

See the w3 guidelines and ARIA Roles for more information.