SpeciFISHity: CSS Specificity

Some people are confused by CSS Specificity, especially with all of the (not-so) new CSS3 Selectors. The image below may help make sense of CSS Specificity.

X-0-0: The number of ID selectors, represented by Sharks
0-Y-0: The number of class selectors, attributes selectors, and pseudo-classes, represented by Fish
0-0-Z: The number of type selectors and pseudo-elements, represented by Plankton a la Spongebob
*: The universal selector has no value

Download the specificity chart and read the rest of the SpeciFISHity article here

HTML5 Input Attributes & Browser Support

I have updated the HTML5 Web Form Browser support grid to include the various input attributes, for what input type each is relevant, and which browsers support each attribute for each type.



Text, search, url, tel Email Password Dateandtime
range color Checkbox, radio file
accept WK, O,
autocomplete O O O O O O O
autofocus WK, O WK, O WK,O WK, O WK, O WK, O WK, O WK, O
checked WK, O,
disabled WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
Form O O O O O O O O
list WK, O WK, O WK, O WK, O WK, O WK, O
max O, WK O, WK O, WK
maxlength WK, O,
WK, O,
WK, O,
min O, WK O, WK O, WK
multiple FF, WK, IE FF, WK
Name WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
WK, O, FF, IE WK, O,
WK, O,
pattern WK, O WK, O WK, O
placeholder WK WK WK
readonly WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
required WK, O WK, O WK, O WK, O WK, O WK, O WK, O
size WK, O,
WK, O,
WK, O,
step O, WK O, WK O, WK
checked WK, O,
value WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
WK, O,
WK, O, FF, IE WK, O,
WK, O,
  • WK = Webkit (tested Safari 5)
  • O = Opera (10.5 on Mac)
  • FF = Firefox (3.6.3 on Mac)
  • IE = Internet Explorer (IE8 on XP)

Browsers that don’t support the type attribute may still support other attributes in the input as the browser may support attributes on the text input type (such as maxlength or size), and will therefore support those attributes on a type it doesn’t support, as the input will default to text type. For example, while IE and FF don’t currently support the email type, they do support the multiple attribute on that type, since they will accept a text type including space separated email addresses.

Resources for this effort include:

Alternative Text for Images: the ALT attribute

For a webpage to validate and be accessible, all images must have a value for the alt attribute, even if that value is empty. The XHTML DTD requires only two atttributes for the img element: src and alt. The XHTML DTD tells you it needs to be there. WCAG tells you a bit more about what it needs to look like. Unfortunately, W3C writings are is not always understandable. This entry will explain, in human terms, how to write the values for your alt attributes.

Section 508/WCAG alt attribute Guidelines:

The first Section 508 guidelines states, “A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content)”. Checkpoint 1.1, the first priority of priority 1 of the WCAG guidelines states the same thing: Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets… (I shortened it. the W3C tends to be loquacious.)

Decorative Images

Decorative images include background images, bullets, <hr /> equivalents, spacer images, etc. These types of images make the page prettier but have no semantic value for a webpage. The alt attribute for decorative images should be empty: <img src=”path/image.gif” alt=”” />.


  • If you’ve read any of my other blog entries, or other articles on web standards, you likely will never have an empty alt attribute, since you are separating the content layer from the presentation layer; and therefore not including decorative images in your XHTML; opting instead for the use of CSS.
  • If you include an empty alt attribute, screen readers will skip over the image. If you fail to put an alt attibute in, the screen reader will read the entire URL of the image. Can you imagine listening to a robot say “spacer gif spacer gif spacer gif” repeatedly, or, worse, going letter bu letter thru the underscores and extensions of a filename generated by ImageReady.


The alt attribute of an icon should describe the intention of the icon, since an icon can have differing meanings depending on the context, and someone who has never seen the icon wouldn’t understand whatit emant if only visually described.

icon possible relevant values for alt useless alt
“correct”, “open”, “start”, “completed”, “asset”, “” circle with check mark
“stop”, “wrong”, “delete”, “close window”, “”, “remove module”, “delete email” red cross
“RSS Feed”, “add RSS feed to reader, “” orange square with 3 lines.
“answer”, “enter password”, “”, “primary key”, “security feature”, “” gold key
“security feature”, “blocked”, “password protected” closed lock

The desription of the appearance of the icon is almost alwasys a useless alt attribute value. Unless you are writing a manual on graphic design or on understanging iconography, don’t include a description of the icon as the value of the alt attribute.

An empty string is a possible relevant value for all icon alt attributes. When an icon appears directly before an equivalent definition of the function of that icon, then the value of the alt attribute should be empty. The two most common examples of this are the print and email icons:

icon possible relevant values for alt useless alt
“open email”, “email messages”, “go to inbox”, “send an email, “” letter
print, “” printer

When an icon describes the text immediately preceding or following it, it is redundant to include a value for the alt attribute of the icon. The screen reader will read “print print”, or “email email”.

Sample alt attribute encoding for icons:


<a href="inbox.html"><img src="icon/email.gif" /> inbox</a> //missing alt attribute

Will validate, but not really good: Screenreader will say “go to inbox inbox”

<a href="inbox.html"><img src="icon/email.gif" alt="go to inbox" /> inbox</a> //redundant alt attribute

Better, and correct:

<a href="inbox.html"><img src="icon/email.gif" alt="" /> inbox</a>

Best: seperates content from presentation

<a href="inbox.html" class="email">inbox</a>

with the css of

a.email {
    padding-left: 18px;
    background: tranparent url(icon/email.gif) no-repeat 0 0;


  • Although it is generally best to use CSS background images (including sprites) if you are going to use an icon
  • If you use a sprite, the alt altribute should describe the relevant section of the sprite. Don’t write “sprite of icons”. Instead, follow the recommendations above (all those images are actually one transparent .gif — a sprite.

Buttons, navigation and other images with text

If you are still using images for the elements in your navigation bar (shame on you!), the general rule is that the value of the alt attribute must match the text of the image. If your image says only “about”, the value of the alt attribute should also read about. Then include more detail about the destination in the title attribute of the parent anchor tag.

<a href="about/index.html" title="About the Author"><img src="img/nav_about.jpg" alt="about" /></a>.

Include the text that appears within your image as the value of the image’s alt attribute.

If you are using mystery meat navigation, you should describe relevant text in the alt, not the an explanation of the iconography of the tab. This may go against standards guidelines, but since mystery meat navigation goes against web standards, at least make your website accessible to the visually impaired, even if it isn’t accessible to sighted users.

Instead of using an <img> for navigation, use text, and make your link attractive, including using your image, via CSS using image replacement. I will include a blog entry on image replacement in the near future, since i use it a lot. In the meantime, you can look it up on any search engine.

Images, without text, that link to somewhere

Sometimes it makes sense to actually use images, without image replacement, to link to a page. For example, on Facebook, Yahoo, and maybe on your company’s about page, thumbnail images of people or avatars may link to the person’s profile. If the image is within the same link as a text link, the alt attribute should be left empty. If not, however, the link should describe the purpose of the link: <a href="bios/jane.html"><img src="img/thmb_jane.jpg" alt="Jane Smith's profile" /></a>.

This is similar to the explanation on icons above. Let’s say you do use just the email icon (from the icon example above). The correct presentation would be:

<a href="inbox.html"><img src="icon/email.gif" alt="go to inbox" /></a>

Complex, detailed images that “convey 1000 words”

Sometimes images are worth a thousand words. Maps, Graphs and Charts are examples of images that contain information necessary to understanding the message of a page but too complex to be described in under 255 characters. If the complex image is followed by text explaining or detailing the content of the image, like you might find in a journal article, then a simple alt attribute value suffices.If there is information conveyed in the image that is not explained in the text following the image and is too complex to describe in 2 sentences, like you might find in a powerpoint presentation, then you need an alternative method of explaining the content of the image to those unable to view the image. In other words, if all the data presented in your image is reiterated as text, then an alt attribute value of “graph of blood pressure by age group” suffices. If there is information that is conveyed in the image that is not reiterated as text for all of your visitors to read (and search engines to find), then you should include a longer description of the image in the form of a longdesc attribute linking to content describing in full detail the contents of your image.

The longdesc attribute

longdesc is an optional attribute of the <img> and <frame> elements. The longdesc property specifies a url for a longer description of the contents of the current frame. The longdesc attribute is coded like this::

<img src="graph.gif" alt="graph of blood pressure by age group(long description available)" longdesc="supportfiles/graphdescribed.html" />

You then need to create a separate page for your longdescription. This page should include the description and a link back the current page. The longdesc attribute’s purpose is to provide a link to a separate page where a long description is available. This link is invisible to the sighted user but available to those using screen readers.

The longdesc functionality is rarely implemented in websites despite it’s being the recommendation of the WC3 and Section 508 guidelines. For this reason, you should:

  • Include the fact that a long description is available in the alt attribute value of the image: it’s used so infrequently that even those using screen readers may not otherwise notice you included it. alt="graph of blood pressure by age group(long description available)"
  • It’s better to not use the longdesc attribute, opting instead to fully describe the contents of the image in the text for all readers. This method provides more fodder for search engines, and explains the content of your graph that even sighted users may not have otherwise noticed or derived.
  • To test whether it’s necessary, turn off images and see if all the information conveyed in the image is presented in the text in the page. If yes, longdesc is not necessary. If not, either include more descriptive text, or include a longdesc.
  • When I receive data graphs, I usually include a datatable with the data conveyed in the graph. Most charts are created using MS Excel (open MS Excel, select “Insert” > “Chart”). Ask whoever created your chart image for the original Excel file, and present the data from the spreadsheet in a data table. If you don’t have the original spreadsheet, if the chart is detailed enough to require a longdesc, then it’s detailed enough to be able to cull the data.
  • WebAIM provides more information on the longdesc attribute.

Other images

This is for all other images! If you included a picture of yourself standing with Britney Spears, your alt attribute value should minimally read “Britney Spears and me”. You can, of course, add a few more details to better describe the image if there is other relevant information presented in the image that the visitor should know.

Making basic web pages accessible

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.


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.


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)


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.


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.


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.


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.

XHTML Elements, their parent, children, attributes and default browser presentation

XHTML Elements, their meaning, semantics and attributes
<ELEMENT> Element Name Block, Inline, etc. Element’s Parents Element’s Children 3 Browser Presentation


Elements occuring outside the body element
<!DOCTYPE> Document Type Declaration Not Displayed first line none   Required. Should be first in the document
<html> html   root element <head> and <body> xmlns Required
<head> document head Not Displayed <html> <base>, <link>, <meta>, <style>, <script>, <title> other than the title, all the other child elements are not visible to user profile, id, dir, lang. NOT class, style, title Required
<base /> url base for links Not Displayed <head> Empty3 href, no standard attributes1  
<link /> link Not Displayed <head> Empty3 href, charset, hreflang, type, rel, rev, media  
<meta /> meta Not Displayed <head> Empty3 content, name or http-equiv, scheme  
<style> style Not Displayed <head> text type, media  
<script> script Not Displayed <head> (allowed in <body> too. text or src attribute, not both type, charset, src, defer do NOT self close with slash. Use end tag
<title> document title   <head> text only seen in the chrome of browser id, dir, lang. NOT class, style, title Required
Elements Occuring in the <body>
<body> document body block <html> Block3   all non-core attributes are deprecated Required
<a> Anchor inline inline or semantic block Text and inline3 except <a> underlined and colored href, hreflang, rel, charset, type, name, rel, rev, shape (rect), coords cannot contain other <a> children


Abbreviation inline inline or semantic block only text / inline3 dotted underline with cursor, tooltip title  
<acronym> acronym inline inline or semantic block only text / inline3 dotted underline with cursor, tooltip title  
<address> address blocktext <blockquote>, <div>, <body>, <form> inline3 elements, <p> italic, block  
<area /> image map area Not Displayed <map> Empty3 makes hot areas on image alt, shape, coords, href, nohref ‘rect’ is default shape if omitted
<bdo> bi-directional override inline inline or semantic block only text / inline3 reversed text dir, lang  
<blockquote> long quote blocktext   block3 margin: 1em 40px; cite  

<br />

break return or forced line break inline   none line-break does not take internationalizaion attributes use as linebreak in poetry or addresses, not to separate paragraphs.
<button> push button inline   any inline3, except form elements and <a> push button disabled, name, type 2, value, accesskey, tabindex Cannot contain <input>, <select>, <textarea>, <label>, <button>, <form>, <fieldset>, <iframe> or <isindex> as children.
<caption> caption   <table> text and inline3 centered above table must be first child of the table
<cite> citation inline phrase element text and inline 3 italicized text
<code> code inline phrase element text and inline 3 monospace font
<col /> column Not Displayed <table> Empty3 char, charoff, span align & valign allowed, but use CSS instead
<colgroup> column group Not Displayed <table> zero or more <col>   span, char, charoff. align & valign allowed, but use CSS instead while empty, close with an ending </colgroup> tag.
<dd> definition description block <dl> Flow3 indented with a left margin
<del> delete inline or block inline or block Flow3 strikethrough cite, datetime don’t put block content in a <del> that is inline


definition inline phrase element only text italic
<div> generic block element block   Flow3
<dl> definition list lists (block)   one or more <dd> and <dt> only
<dt> definition term block <dl> text and inline3 only cannot have block elements as children!
<em> emphasized text inline phrase element text and inline3 only italics
<fieldset> field set block <form> <legend>, Flow 3 box around child elements with legend, if any
<form> form Block block element block elements and block form elements action, method, enctype, accept, accept-charset cannot nest a <form> within a <form>
<h1-6> headers heading (block) body or block inline and text varying font sizes and bold
<hr /> horizontal rule blocktext (block) body or block Empty horizontal line
<iframe> internal frame         longdesc,
<img /> image inline inline or semantic block Empty The image identified in the src src, alt, longdesc, usemap, ismap height and width are optional attributes best omitted.
<input /> input inline inside a semantic block located in <form> Empty depends on type type, name, value, check, disabled, readonly, size, maxlength, src, alt, usemap, accept type defaults to text if not declared, but you should declare it
<ins> Insert inline or surrounding blocks   Flow underlined cite, datetime don’t put block content in a <del> that is inline
<kbd> keyboard inline phrase element text (and inline) monospace font should really just be text
<label> label inline semantic block within a <form> text and inline for, accesskey cannot contain child <label> elements
<legend> caption for fieldset   <fieldset> inline and text top left section of the fieldset box  
<li> list item block <ul> or <ol> Flow bulleted new line  
<map> image map Not Displayed   one or more <area> OR block ID, name  
<object> object     <param>, if included, should come first. Flow   declare, classid, codebase, date, type, codetype, archive, standby, usemap, name, tabindex allowed in <head> by spec. height and width are optional attributes best omitted.


ordered list lists (block) block one or more <li> elements indented <li>s with numeric bullets  
<optgroup> option group   <select> one or more <option> bold, non-selectable header for a group of indented options. label, disabled  
<option> option   <select>, or within <optgroup> textnode appears within the select drop down as new row selected, disabled, label, value if value is omitted, submitted value is the text node value
<p> paragraph block block inline and text new line of text
<param /> parameter invisible <object> none not visible, though may cause visual effects id, name, value, valuetype, type can place params as name/value pairs in the object element
<pre> preformatted text blocktext (block)   inline, except <img>, <object>, <sub> & <sup> monospace font and nowrap whitespace Cannot contain <img>, <object>, <sub>, or <sup> elements
<q> inline quotation inline inline or semantic block inline and text quotes at start and end of content cite (URL) quote style depends on language. Poor browser support of quotes
<samp> sample computer code inline phrase element inline monospace font
<select> option selector inline inline or semantic block within <form> one or more <option> required, optional <optgroup> drop down list name, size, multiple, disabled, tabindex  
<span> span (generic non-semantic container) inline inline or semantic block text or inline  
<strong> strong emphasized text inline phrase element text or inline bolder text don’t use in <h1-6> as those are already emphasized
<sub> subscript inline inline or semantic block text or inline smaller, subscripted text do not include in <pre>
<sup> superscript inline inline or semantic block text or inline smaller, superscript text cannot be a child of <pre>
<table> data table block block or body <caption>?, (<col>*|<colgroup>*), <thead>?, <tfoot>?, (<tbody>+|<tr>+)) 4 data table summary (width, border, frame, rules, cellspacing, cellpadding)

width, border, cellspacing, cellpadding are allowed, but better to use CSS.


<tbody> table body block <table> one or more <tr> appears between thead and tfoot char, charoff in code flow, comes AFTER <tfoot>
<td> table data cell block <tr> Flow vertical align middle, text-align: left abbr, axis, headers, scope, rowspan, colspan,
width, align & valign allowed, but use CSS instead
<textarea> text area block <form> or block within form textnode or no text multi-line text field displaying textnode if there is one rows, cols, name, disabled, readonly  
<tfoot> table footer block <table> only one or more <tr> appears at bottom of table char, charoff, width, align & valign allowed, but use CSS instead comes before <tbody>
<th> table header cell block <tr> only Flow bold and center abbr, axis, headers, scope, rowspan, colspan, char, charoff. width, align & valign allowed, but use CSS instead  
<thead> table head block <table> only one or more <tr> only at top of table char, charoff. width, align & valign allowed, but use CSS instead follows opening <table> or <caption> if there is one.
<tr> table row block <table>, <thead>, <tfoot> or <tbody> one or more <th> or <td> new line char, charoff. width, align & valign allowed, but use CSS instead if any of the parent elements are present, there must be at least one <tr>
<ul> unordered list lists (block) block one or more <li> elements indented, bulleted on <li>s
<var> variable inline phrase element text (and inline) italic No reason to include inline elements. Should be just text as child
Elements you should not be using, that are still valid
<tt> teletype inline inline or semantic block text (and inline) monospace Purely presentational. Should be deprecated, but aren’t yet.
<i> italic italic
<b> bold bold
<big> big font bigger font
<small> small font smaller font
<frame /> frame block <frameset> Empty page within a page

name, src, longdesc, security. frameborder,
scrolling also allowed.

only allowed in frameset DTD
<frameset> frameset block <body> <frame>, <frameset>, <noframes> divides the browser window cols, rows. only allowed in frameset DTD
<noframes> no frames block <frameset> Flow can be found outside of frameset (for no iframe support)
<noscript> no script block Flow Flow Your site should work without scripts, so should not be necessary


  1. Attributes: All elements accept the standard and internationalization attributes of id, class, title, style, dir, and lang unless otherwise noted. The attributes column lists elements specific attributes and exceptions to the core attributes. Required attributes have been emphasized.
  2. Even though the type attribute is not required by the specifications, always define type because IE is stupid.
  3. Inline: <a>, <br>, <span>, <bdo>, <map>, <object>, <img>, <tt>, <em>, <strong>, <dfn>, <code>, <q>, <samp>, <kbd>, <var>, <cite>, <abbr>, <acronym>, <sub>, <sup>, <input>, <select>, <textarea>, <label> and<button>
    <p>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <ul>, <ol>, <dl>, <pre>, <hr>, <blockquote>, <address>, <fieldset>, <table>
    Flow: text < form > and all the inline and block elements
    Empty: self closing element, include a slash before the end of the opening tag to self close. Contains no children
  4. Table elements: 0 or 1 optional <caption> element, 0 or more optional <col> elements OR 0 or more optional <colgroup> elements, 0 or 1 optional <thead> element, 0 or 1 optional <tfoot> element, and REQUIRED either one or more <tbody> elements OR one or more <tr> elements.