Posts Tagged ‘ Accessibility ’

Expert user Vs Novice user

Expert users (meaning with extended experience in the application) expects advance features and capabilities. They will want more customization options. Since they have a stable mental model of the application structure they feel free to explore the application and try new things. They will not be too worried about making mistakes since they feel secure that they will know how to bypass them.

Novice users, on the other hand, are new to the system and will need a simple and basic interface. Since they are new in the system they will expect more secure ways of doing things in the system (for example they will choose the templates or wizards to do their first steps in the system). Novice users’ interface should provide simple ways to achieve important frequently performed tasks. When designing to novice users we should remember what the main use cases and don’t shadow them with unnecessary features.

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