Archive for the ‘ WCAG2.0 ’ Category

AJAX accessibility for websites

AJAX or Asynchronous JavaScript and XML, is an innovative way of using existing technologies to create highly interactive web applications. AJAX allows portions of the page to be updated without having to refresh and reload the entire page. It can increase site performance significantly and provide cutting edge user interfaces. Unfortunately it can also be a source of concern for delivering fully accessible web sites.

What is AJAX?

AJAX is not a new technology in itself but a new approach to programming websites based on the following web standards:

  • JavaScript
  • XML
  • HTML / XHTML
  • CSS

The key word is asynchronous – AJAX applications work ‘behind the scenes’ with the web server to dynamically update the content of a web page. JavaScript plays an important role in this process, trading data with the server and manipulating the information on the page.

Accessibility benefits of AJAX

As well as significantly improving the user experience AJAX applications can also enhance accessibility. For example:

  • Auto-suggest dropdowns can help both users with reading difficulties and motor impairmentse.g. City and airport suggestions are offered as users enter text Screenshot of Kayak auto-suggest dropdown
  • Drag & drop sliders can help users with reading difficulties due to their illustrative naturee.g. A click-and-drag slider is used to filter search criteria Screenshot of Amazon drag & drop  sliders

Accessibility issues caused by AJAX

AJAX and JavaScript are usually used to update page content. When this happens screen readers respond in a variety of different ways, depending on both the screen reader and the browser:

  • Screen readers aren’t aware of the changes so will read out the unmodified version of the page. This means screen reader users don’t get the updated content of the page.
  • Screen readers are aware of the changes but will only read the modified content when they naturally reach it. This is fine unless the modified content precedes users’ current location. If this happens, they’re unlikely to hear this content.
  • Screen readers start reading the modified page but from the very top. This means that users have to essentially listen to all of the page content again. It can be difficult for these users to know which content has been updated and where in the page this content is.
  • Screen readers are automatically taken to the modified content so users instantly know that page content has been updated – this can however severely disorientate users.

Screen magnifier users might not notice changes that have occurred outside the areas they’re interacting with. They can therefore miss out on important information especially if the changed content takes place above their current location on the page.

Finally, AJAX requires JavaScript to be enabled. Although assistive technologies can now handle many uses of JavaScript they don’t all provide complete support.

Recommendations for AJAX and accessibility

There’s one key question to consider when planning the development of a website and the use of AJAX: Is there a real need to use AJAX?. If the answer is yes, then ensure the following is true to ensure AJAX accessibility is optimised:

Inform users early in the page that dynamic updates will occur
Not all users are familiar with AJAX interfaces. Let them know that changes may take place so they can expect and look for these changes. This is particularly important for screen reader and magnifier users as they may be unaware that changes have taken place.
Highlight the areas that have been updated
Using subtle changes to highlight areas that have changed, for just a short period of time, can be most helpful. It will inform users, in particular those with reading difficulties that updates have taken place.
Don’t change the focus
Do not move the focus of the page to where the change has taken place. Changing the focus can be disrupting for screen reader and magnifier users especially if there are no mechanisms to return to the previous position.
Offer the option to disable automatic updates
Allow users to manually request page updates, for example by providing links and/or form buttons to refresh the page on-demand. Screen reader and magnifier users may be unaware of on-the-page changes. It can also be difficult for users with reading difficulties to keep up with automatic updates. If possible, store users’ preferences for requesting page updates for future visits to the site.
Ensure the site works if JavaScript isn’t enabled
Build a standard application then overlay it with AJAX to improve its functionality. If JavaScript is disabled or not available then users will still be able to use the site.

In case of an advanced AJAX application, consider providing an HTML alternative. If the AJAX application is impossible to use by group of users (e.g. if it relies on the use of a mouse, such as the drag & drop sliders) then a link to an HTML alternative is a must.

Bookmark and Share

Twitter and Web Accessibility

Web Accessibility 10 Tips WCAG 2.0

Most web accessibility guidelines already go hand-in-hand with website development practices. In this article, we’ll explore 10 quick and easy ways to improve your site’s accessibility.



1. Use meaningful title attributes

Think of title attributes as short summaries that describe where the hyperlink will take the user who clicks on it.

It doesn’t help if the title attribute is the same as the link text, such as in the following example:

<a href="portfolio.html" title="Portfolio">Portfolio</a>

Why is that? Because for screen reader users, it’s redundant and gives them no added value.

In the above example, even though web accessibility and Section 508 validators won’t let you pass their automated tests without it, it’s actually better to leave out the title attribute.

A better title attribute to the example above is:

<a href=" portfolio.html" title="Some artwork of the artist">Portfolio</a>

2. Place important interactive elements higher up the web page

Here’s a simple web accessibility exercise for you: identify important hyperlinks and user interface controls that your users need access in one of your web pages. Then count how many times you have to press the Tab key to get to it.

Did you get to it fast enough? Or did you have to press the Tab key like crazy? Were you able to see which hyperlink of interface control was currently focused on when you pressed the Tab key?

Now imagine yourself in the situation where you can’t use a conventional point-to-interact device like a mouse; a situation where, in order to get to a desired interactive element, you have to traverse the ones the come before it on the web page. This gives you a partial picture how people who have limited or no hand functions interface with a web page.

Easy enough: place important links and other interactive elements higher up your web pages. It’s good practice anyways since most website users, regardless of physical or mental ability, expect important items closer to the top of a web page.

3. Don’t begin title attributes with the same text

You’ll often see hyperlink elements with title attributes that look like this:

<a href="/" title="Link to home">Home</a>
<a href="/products" title="Link to products">Products</a>
<a href="/contact" title="Link to contact">Contact</a>

This can be a result of default content management system configurations, or someone who did not want to take too much time with title attributes.

Users who use screen readers such as JAWS often rely on title attributes to find web links on a page. JAWS, for instance, has a feature for pulling together a list of links on a web page sorted in alphabetical order. If title attributes begin with the same text, it’s harder to use search functions that are built into screen readers.

4. Use headings correctly

Heading tags allow screen reader users to jump to the sections they’re interested in. Headings on a web page is an outline of the web page; using an <h2> right after an <h1> element denotes a section that is a subsection of the preceding <h1>.

Many of us neglect headings, including me. In every single instance where I’ve misused heading elements, I couldn’t find a reasonable explanation for doing so – and neither will you.

This simple web accessibility guideline can do wonders for people with vision deficiencies that use screen-reading technology.

Breaking up a long web page into logical subsections with headings makes it easier to get to your location of interest. Imagine that while reading the first paragraph of an article, that you immediately wanted to leave a comment, and the comment form is located somewhere at the bottom of a web page. For sighted users, this would be a snap: you just need to scroll down and visually locate the web form.

But on content-heavy sites such as the one you’re viewing now, the comment form is actually somewhere in the middle of the HTML structure even though visually, it’s right at the bottom of the web page. Without section headings that indicate where the web form begins, screen reader users would have to wade through a lot of content in order to get to the form. On Six Revisions, the level 3 heading “Leave a Comment” will allow screen reader users to quickly jump to it.

5. Use distinct and meaningful page titles

The first thing a screen reader user will encounter right after the web page fully loads is the text in between your <title> tags. The worst thing you can do, aside from not having the <title> tag, is having them all the same in all of your web pages. This makes it difficult for users who rely on your HTML markup to determine what page they’re on, or if the link they clicked on is the same web page they were previously on or not.

If your page titles are the same, or if you don’t have page titles, screen reader users will always have to read the content before determining that they’re on web page they want to be on. Keep page titles succinct and meaningful.

Good page titles to use that include repeating text are:

<head>
  <title>About Us - Six Revisions</title>
</head>
<head>
  <title>All Articles: Six Revisions</title>
</head>
<head>
  <title>Six Revisions: Home</title>
</head>

6. Use skip navigation

Screen reader users have to read HTML documents from top to bottom, without the ability to scan the web page for the information they’re interested in.

Skip navigation allows screen reader users and persons who can’t use a mouse to skip long lists of links, such as the primary navigation on a website.

Skip navigation is simply a link right at the top of your web page that, when clicked, positions you to the content section. You can hide this link from able-bodied users by moving the link outside of the browser viewport using CSS.

Here’s an example: let’s say that you have the HTML structure below and you want to have a skip nav that positions the reader on the main content area (div#content).

<ul id="nav">
  <li><a href="home.html" title=" ">Home</a></li>
  <li><a href="about.html" title=" ">About</a></li>
  <li><a href="blog.html" title=" ">Blog</a></li>
  <li><a href="portfolio.html" title=" ">Portfolio</a></li>
  <li><a href="contact.html" title=" ">Contact</a></li>
</ul>
<div id="leftCol">
  <h1>My friends</h1>
  <ul>
    <li><a href="http://blogofafriend.com/" title=" ">Blog of a friend</a></li>
    <li><a href="ttp://friendofablog.com/" title=" ">Friend of a blog</a></li>
  </ul>
</div>
<div id="#content">
  <h1>Page  Title</h1>
  ...
</div>

You would place your skip navigation link right above your unordered list, like so:

<a id="skipnav" href="#content" title="Jump to content">Skip Navigation</a>
<ul id="nav">
  <li><a href="home.html" title=" ">Home</a></li>
  <li><a href="about.html" title=" ">About</a></li>
  <li><a href="blog.html" title="">Blog</a></li>
  <li><a href="portfolio.html" title="">Portfolio</a></li>
  <li><a href="contact.html" title="">Contact</a></li>
</ul>
<div id="leftCol">
  <h1>My friends</h1>
  <ul>
    <li><a href="http://blogofafriend.com/" title="">Blog of a friend</a></li>
    <li><a href="ttp://friendofablog.com/" title="">Friend of a blog</a></li>
  </ul>
</div>
<div id="#content">
  <h1>Page  Title</h1>
  ...
</div>

Some sites decide to keep the skip navigation link visible, but if you’d rather hide it from sighted users, you can use CSS to indent the link outside of the web browser viewport:

#skipnav {
  position:absolute;
  top:-10000px;

7. Label your form elements

HTML web forms are the primary way of interacting with a website. Because of the importance of web forms, making sure that you use correct markup is crucial for universal design.

Label your input elements with meaningful and descriptive text. This makes it clear to the user what information they should be providing.

<label for="searchbox">Enter key words to search:</label><input id="searchbox" name="searchbox" type="text"  />

With CSS, you can style that label element into an icon or hide it from plain view by pushing it out of the browser viewport, if you really must.

8. Test your web pages with CSS and JavaScript disabled

One of the simplest ways to determine how access-friendly a website is to users that can’t see content in a computer monitor, is to turn off CSS and JavaScript. Why?

With CSS, we can position elements wherever we want, regardless of where they are in the actual document object model.

With JavaScript, we can manipulate page elements by hiding, removing, and showing them, based on a user’s action.

Disabling these two web technologies allows you to see whether or not all of your web page content is accessible. It also shows you whether your web pages are organized in an optimum manner.

9. “See” what it’s like to use assistive technologies

Perhaps the best way to fully understand universal design on the web is to see an actual person use a website with assistive technologies. If you don’t know of a person with a form of disability that affects their ability to use the web, there are many simulators online that will help you at least get a partial picture of how assistive technologies render and interface with a website.

For screen reader simulations, try out WebAnywhere, a web tool created through a collaboration between University of Michigan and University of Rochester. If you want to feel how it’s like to be blind and interacting with a website: memorize a few keyboard shortcut keys the WebAnywhere uses. Navigate to your site using WebAnywhere. Turn off your monitor and unplug your mouse. Finally, try to read and interact with the web page you’re on.

To see if the colors you’ve chosen are universally accessible to individuals with vision impairments, check out the list of tools for evaluating colors I’ve put together a while back.

Additionally, there are many tools out there that will help you validate your work against common web accessibility standards and guidelines. There are many of them, and most of the good ones are free. See the article: 10 Tools for Evaluating Web Design Accessibility.

10. Web accessibility is not about degrading the overall user experience

The final tip I’d like to share is more of a philosophical viewpoint to designing with web accessibility in mind.

Many of us think that reaching a high level of web accessibility means that it’s at the cost of the general/average user experience. It’s not. It’s about offering multiple access points with varying levels of complexity.

I learned this lesson while looking at all-inclusive playground equipment.

I noticed that it’s not about lowering the difficulty of obstacles in a playground equipment (such as the one featured below), but that it’s about giving several point of access with varying levels of difficulty.

}

The downside of the above technique is that, although it will work for screen reader users, it won’t help users who can’t use a mouse since they won’t be able to use the Tab key to navigate to the skip navigation link. An improvement to the method above can be found on WebAIM: Links that become visible with keyboard focus.

Skip navigation is easy to implement, but very useful to have in web pages with a lot of content above the primary content area.

WebAIM has a very thorough discussion of skip navigation that includes several techniques (and their pro’s and con’s) that you should read.

Recommended Reading

There are many methods involved in making websites universally-accessible, with varying levels of difficulty for integration. I’ve just touched on a few of them. Even if you take just a few hours of your time today to read the following resources, I promise you that you’ll learn a lot about web accessibility.

Introduction to Web Accessibility

The W3C Web Accessibility Initiative group has an introductory level document for those who want to learn about web accessibility, but don’t know where to start.

WebAIM

WebAIM (Web Accessibility In Mind) promotes universal design on the web and has plenty of articles on web accessibility; just studying the site’s design and HTML/CSS source code can give you an idea of what a web accessible site is.

Dive Into Accessibility

This online book was designed as a 30-day course that educates its readers about one accessibility technique per day, but you can read it all in one sitting, and an average reader can probably get through it in about a few hours.

How People with Disabilities Use the Web

A document on W3C that gives readers an overview of how persons with handicaps use the web.

2. Place important interactive elements higher up the web page

Here’s a simple web accessibility exercise for you: identify important hyperlinks and user interface controls that your users need access in one of your web pages. Then count how many times you have to press the Tab key to get to it.

Did you get to it fast enough? Or did you have to press the Tab key like crazy? Were you able to see which hyperlink of interface control was currently focused on when you pressed the Tab key?

Now imagine yourself in the situation where you can’t use a conventional point-to-interact device like a mouse; a situation where, in order to get to a desired interactive element, you have to traverse the ones the come before it on the web page. This gives you a partial picture how people who have limited or no hand functions interface with a web page.

Easy enough: place important links and other interactive elements higher up your web pages. It’s good practice anyways since most website users, regardless of physical or mental ability, expect important items closer to the top of a web page.

3. Don’t begin title attributes with the same text

You’ll often see hyperlink elements with title attributes that look like this:

<a href="/" title="Link to home">Home</a>
<a href="/products" title="Link to products">Products</a>
<a href="/contact" title="Link to contact">Contact</a>

This can be a result of default content management system configurations, or someone who did not want to take too much time with title attributes.

Users who use screen readers such as JAWS often rely on title attributes to find web links on a page. JAWS, for instance, has a feature for pulling together a list of links on a web page sorted in alphabetical order. If title attributes begin with the same text, it’s harder to use search functions that are built into screen readers.

4. Use headings correctly

Heading tags allow screen reader users to jump to the sections they’re interested in. Headings on a web page is an outline of the web page; using an <h2> right after an <h1> element denotes a section that is a subsection of the preceding <h1>.

Many of us neglect headings, including me. In every single instance where I’ve misused heading elements, I couldn’t find a reasonable explanation for doing so – and neither will you.

This simple web accessibility guideline can do wonders for people with vision deficiencies that use screen-reading technology.

Breaking up a long web page into logical subsections with headings makes it easier to get to your location of interest. Imagine that while reading the first paragraph of an article, that you immediately wanted to leave a comment, and the comment form is located somewhere at the bottom of a web page. For sighted users, this would be a snap: you just need to scroll down and visually locate the web form.

But on content-heavy sites such as the one you’re viewing now, the comment form is actually somewhere in the middle of the HTML structure even though visually, it’s right at the bottom of the web page. Without section headings that indicate where the web form begins, screen reader users would have to wade through a lot of content in order to get to the form. On Six Revisions, the level 3 heading “Leave a Comment” will allow screen reader users to quickly jump to it.

5. Use distinct and meaningful page titles

The first thing a screen reader user will encounter right after the web page fully loads is the text in between your <title> tags. The worst thing you can do, aside from not having the <title> tag, is having them all the same in all of your web pages. This makes it difficult for users who rely on your HTML markup to determine what page they’re on, or if the link they clicked on is the same web page they were previously on or not.

If your page titles are the same, or if you don’t have page titles, screen reader users will always have to read the content before determining that they’re on web page they want to be on. Keep page titles succinct and meaningful.

Good page titles to use that include repeating text are:

<head>
  <title>About Us - Six Revisions</title>
</head>
<head>
  <title>All Articles: Six Revisions</title>
</head>
<head>
  <title>Six Revisions: Home</title>
</head>

6. Use skip navigation

Screen reader users have to read HTML documents from top to bottom, without the ability to scan the web page for the information they’re interested in.

Skip navigation allows screen reader users and persons who can’t use a mouse to skip long lists of links, such as the primary navigation on a website.

Skip navigation is simply a link right at the top of your web page that, when clicked, positions you to the content section. You can hide this link from able-bodied users by moving the link outside of the browser viewport using CSS.

Here’s an example: let’s say that you have the HTML structure below and you want to have a skip nav that positions the reader on the main content area (div#content).

<ul id="nav">
  <li><a href="home.html" title="">Home</a></li>
  <li><a href="about.html" title="">About</a></li>
  <li><a href="blog.html" title="">Blog</a></li>
  <li><a href="portfolio.html" title="">Portfolio</a></li>
  <li><a href="contact.html" title="">Contact</a></li>
</ul>
<div id="leftCol">
  <h1>My friends</h1>
  <ul>
    <li><a href="http://blogofafriend.com/" title="">Blog of a friend</a></li>
    <li><a href="ttp://friendofablog.com/" title="">Friend of a blog</a></li>
  </ul>
</div>
<div id="#content">
  <h1>Page  Title</h1>
  ...
</div>

You would place your skip navigation link right above your unordered list, like so:

<a id="skipnav" href="#content" title="Jump to content">Skip Navigation</a>
<ul id="nav">
  <li><a href="home.html" title="">Home</a></li>
  <li><a href="about.html" title="">About</a></li>
  <li><a href="blog.html" title="">Blog</a></li>
  <li><a href="portfolio.html" title="">Portfolio</a></li>
  <li><a href="contact.html" title="">Contact</a></li>
</ul>
<div id="leftCol">
  <h1>My friends</h1>
  <ul>
    <li><a href="http://blogofafriend.com/" title="">Blog of a friend</a></li>
    <li><a href="ttp://friendofablog.com/" title="">Friend of a blog</a></li>
  </ul>
</div>
<div id="#content">
  <h1>Page  Title</h1>
  ...
</div>

Some sites decide to keep the skip navigation link visible, but if you’d rather hide it from sighted users, you can use CSS to indent the link outside of the web browser viewport:

#skipnav {
  position:absolute;
  top:-10000px;
}

The downside of the above technique is that, although it will work for screen reader users, it won’t help users who can’t use a mouse since they won’t be able to use the Tab key to navigate to the skip navigation link. An improvement to the method above can be found on WebAIM: Links that become visible with keyboard focus.

Skip navigation is easy to implement, but very useful to have in web pages with a lot of content above the primary content area.

WebAIM has a very thorough discussion of skip navigation that includes several techniques (and their pro’s and con’s) that you should read.

7. Label your form elements

HTML web forms are the primary way of interacting with a website. Because of the importance of web forms, making sure that you use correct markup is crucial for universal design.

Label your input elements with meaningful and descriptive text. This makes it clear to the user what information they should be providing.

<label for="searchbox">Enter key words to search:</label><input id="searchbox" name="searchbox" type="text"  />

With CSS, you can style that label element into an icon or hide it from plain view by pushing it out of the browser viewport, if you really must.

8. Test your web pages with CSS and JavaScript disabled

One of the simplest ways to determine how access-friendly a website is to users that can’t see content in a computer monitor, is to turn off CSS and JavaScript. Why?

With CSS, we can position elements wherever we want, regardless of where they are in the actual document object model.

With JavaScript, we can manipulate page elements by hiding, removing, and showing them, based on a user’s action.

Disabling these two web technologies allows you to see whether or not all of your web page content is accessible. It also shows you whether your web pages are organized in an optimum manner.

9. “See” what it’s like to use assistive technologies

Perhaps the best way to fully understand universal design on the web is to see an actual person use a website with assistive technologies. If you don’t know of a person with a form of disability that affects their ability to use the web, there are many simulators online that will help you at least get a partial picture of how assistive technologies render and interface with a website.

For screen reader simulations, try out WebAnywhere, a web tool created through a collaboration between University of Michigan and University of Rochester. If you want to feel how it’s like to be blind and interacting with a website: memorize a few keyboard shortcut keys the WebAnywhere uses. Navigate to your site using WebAnywhere. Turn off your monitor and unplug your mouse. Finally, try to read and interact with the web page you’re on.

To see if the colors you’ve chosen are universally accessible to individuals with vision impairments, check out the list of tools for evaluating colors I’ve put together a while back.

Additionally, there are many tools out there that will help you validate your work against common web accessibility standards and guidelines. There are many of them, and most of the good ones are free. See the article: 10 Tools for Evaluating Web Design Accessibility.

10. Web accessibility is not about degrading the overall user experience

The final tip I’d like to share is more of a philosophical viewpoint to designing with web accessibility in mind.

Many of us think that reaching a high level of web accessibility means that it’s at the cost of the general/average user experience. It’s not. It’s about offering multiple access points with varying levels of complexity.

I learned this lesson while looking at all-inclusive playground equipment.

I noticed that it’s not about lowering the difficulty of obstacles in a playground equipment (such as the one featured below), but that it’s about giving several point of access with varying levels of difficulty.

Bookmark and Share

Web accessibility WCAG 2.0 short Guideliness

What’s good in WCAG 2.0 :

The latest version of web content accessibility guidelines 2.0 (WCAG 2.0) are divided into 4 principles (POUR) –

  • Perceivable,
  • Operable,
  • Understandable
  • Robust

Each principle is divided into guidelines with priority levels A, AA, AAA.

The WCAG 1.0 has 14 guidelines but are not divided into blocks.

This has been taken care in WCAG 2.0 in the form of principles. The explanations of the checkpoints are given in separate hyperlinks.

Important Issues in WCAG 2.0

1.Table:

Tables are one of the most widely used attributes in HTML and they do create problems in the accessibility of the web page. Even though tables are not used for the visual layout in the recent era ,they are used to present the important data in a tabular form. WCAG 2.0 provides no information about tables and the ways in which they can be used whereas WCAG 1.0 guideline 5 entirely speaks about HTML tables.

Example:

The following example consists of two parts: the CSS code, which specifies a margin on all sides of the table, and padding for the table cells; and the HTML code for the table, which does not contain spacer images and is not nested inside another table.

Code:

table { margin: .5em; border-collapse: collapse; }
              td, th { padding: .4em; border: 1px solid #000; }

            ...

              <table summary="Titles, authors and publication dates of books in Web development category">
                <caption>Books in the category 'Web development'</caption>
                <thead>
                  <tr>
                    <th>Title</th>
                    <th>Author</th>
                    <th>Date</th>
                  </tr>
                </thead>
                <tbody>
                  <tr>
                    <td>How to Think Straight About Web Standards</td>
                    <td>Andrew Stanovich</td>
                    <td>1 April 2007</td>
                  </tr>
                </tbody>
              </table>
Refer: http://www.w3.org/TR/WCAG-TECHS/C18.html

2.Users of older browsers and turn-off features:

WCAG 2.0 includes the turn-off feature for the ones who use older browsers that do not support images, java script and so many new features.

3.Auto refreshing and auto redirecting:

The features such as auto refreshing, auto redirecting and causing pop-ups create problems for visually impaired users who can be both low vision and screen reader users. These features are explained clearly in check points 7.4 & 7.5 in WCAG 1.0 but were not defined in WCAG 2.0.

4.Usage of deprecated features of HTML:

WCAG 2.0 does not contain any information about deprecated features of HTML, that cannot be used as per WCAG 1.0.

5.Usage of frames:

The usage of frames is clearly explained in checkpoints 12.1 & 12.2 of WCAG 1.0 but were left unexplained in the latest version of WCAG.

6.Usage of style sheets:

Nowadays, most of the web designers are using CSS for visual lay out of the web pages. WCAG 2.0 do not contain any relevant information about the usage of style sheets.

7. Usage of HTML doc type:

There are no guidelines about doc type declaration in WCAG 2.0 where as WCAG 1.0 has it explained. The latest version did not focus much on the alidation of HTML and its perfect usage.

8. Usage of links in meaningful sequence:

WCAG 2.0 guidelines 1.3.2 defines that the links should be presented in meaningful sequence so that the user can use the track to find the required information easily. In the checkpoint 1.3.2 it is given that any audio or video should not play continuously for more than 3 seconds, if it plays the user has to be given an option to pause or stop, or at least have a mechanism to reduce the volume without changing the over all system volume.

9. Input errors:

This is one of the issue, where WCAG 1.0 didn’t focus  much, but it does have a vital role in web pages. This was nicely explained in the guideline 3.3 of latest version.

Some more issues raised by WCAG 2.0 are:

1. Foreground and background colors selected by the user.
2. Width should not be more than 80 characters or glyphs (40 if CJK).
3. Text is not justified (aligned to both the left and the right margins).
4. Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
5. Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

Test Tools:

WAVE – http://wave.webaim.org/toolbar
Firefox Accessibility extension
Add-ons of Mozilla Firefox https://addons.mozilla.org/en-US/firefox/search?q=accessibility&cat=all

Screen Readers
NVDA – http://www.nvda-project.org
JAWS for Windows – http://www.freedomscientific.com
Screen Magnifiers
ZoomText Xtra – http://www.aisquared.com
Dolphin Supernova – http://www.yourdolphin.com
Alternate Input devices –
Track ball and switch – http://www.ablenetinc.com
Dragon Naturally Speaking
http://www.nuance.com
Talks – a screen reader for mobile S60 phones
http://www.nuance.com/talks/

Some Useful Links:

http://www.bentoweb.org/XHTML1_TestSuite3

http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/wcag-guidelines-20.shtml

http://www.it-analysis.com/business/compliance/content.php?cid=11303



Introduction of WCAG 2.0

Introduction to Web Accessibility and WCAG2.0

Bookmark and Share