Download 610 KB PDF

White Paper
Checking for Web
Accessibility Compliance
Organizations the world over are recognizing the
need for making their business accessible to all users,
regardless of ability, over the Internet. Apart from
helping businesses ensure that they fulfill their legal
obligations to disabled users (acts like the Americans
with Disability Act (ADA) and Disability Discrimination
Act (DDA) have made accessibility compliance a legal
requirement), accessibility encourages a more
inclusive experience, broadens the potential user
base, and delivers all-round benefits like improved
engagement, collaboration, searchability and
portability of the website.
The Internet World Statistics show that there are 2.4
billion Internet users worldwide as on June 30, 2012
and as per the United Nations Factsheet on Persons
with Disabilities, available as of March 2013, around
10%of the world’s population or over 650 million
people have some form of disability – which means
that over 27% of the potential users have special
needs when it comes to accessing the Internet.
However, many web applications continue to remain
inaccessible to these users, either fully or partially.
Web accessibility compliance aims at ensuring that
people with abilities and disabilities are able to use
the Internet – to navigate, interact, collaborate and
contribute, resulting in a more inclusive experience.
In continuation to our previous paper Making a Web
Application Operable by Physically and Mentally
Challenged Users, which addressed the Web
Accessibility guidelines and the underlying principles,
this paper discusses the methods and approaches for
ensuring web accessibility compliance. We also look at
a few code examples that can help improve the
accessibility compliance of a website.
2
About the Authors
Angeline George
Angeline George has a Bachelor's degree in Computer Science, and
has worked with Tata Consultancy Services (TCS) since 2008 as a
usability and web accessibility analyst. Her core experience has been
in designing and developing user-interactive, rich Internet web
applications. She is a Certified Usability Analyst (CUA) from Human
Factors International.
Muktikanta Sendha
Mukti is a Solution Architect with 12 years of experience at Tata
Consultancy Services (TCS). He has been involved with architecting
solutions on a diverse set of technology platforms for customers in
Financial Services, Insurance, Manufacturing and Retail industries.
Currently he is leading the User Experience Center of Excellence and
is a Certified Usability Analyst (CUA) from Human Factors
International.
3
Table of Contents
1. Introduction
5
2. Approach and Methods to Check Accessibility Compliance
6
2.1 Automated Checking
7
2.2 Specialized Checking
9
2.3 Manual Checking
11
3. Coding Examples that Improve Accessibility
12
4. Conclusion
15
5. References
15
4
1. Introduction
Businesses in a few domains have successfully used web accessibility to broaden their reach and deliver
benefits across users. This trend is especially dominant for Government and education sites. Government
websites use the web to offer citizens access to information about government services, applying for jobs
or benefits, providing tax information and accepting tax returns, etc. These services are of vital
importance to the entire citizen base and it is essential that people with disabilities do not face
accessibility barriers. Some of the leading Government websites that are accessibility compliant are:
1. http://www.cdc.gov/
2. http://www.ssa.gov/
3. http://www.ipaustralia.gov.au/
For educational institutions, the Internet has become a key medium for information dissemination,
service delivery, and course delivery and to connect with prospective students and their families. Because
core services and information are delivered via the Web, it is critical that all people, irrespective of their
disabilities, are able to access the information. Some good examples of accessible education websites are:
1. http://www.harvard.edu/
2. http://www.upenn.edu/
The Retail industry (especially businesses with a presence in the US) is also being driven by regulatory
mandates to ensure that retail and e-commerce websites are accessible to the disabled.
Scope of Accessibility Compliance
Accessibility refers to equal access to a website/application to everyone, irrespective of the user’s physical
or mental ability. Accessibility compliance ensures that people with disabilities can perceive, understand,
navigate, and interact with websites and applications. An accessible website/application is available and
comprehensible to people with disabilities including vision impairment or loss, physical impairment,
hearing impairment or loss, cognitive impairment, or literacy impairment, as well as to people who are
challenged by technological/infrastructure constraints such as low bandwidth or limited Internet
connection.
Some forms of disability covered under accessibility norms are:
n
Low visual acuity: needing the option to increase the size of text
n
No or low vision: needing assistive technologies that read the content aloud
n
Color blindness: needing higher contrast between foreground and background colors, and conveying
information by other means rather than color alone
n
Impaired hearing: needing visual and text alternatives for audio information
n
Impaired mobility: needing methods of navigating web pages other than by mouse alone
n
Cognitive disability: needing clear and simple presentation of content
5
Web Accessibility Guiding Principles and Laws
Accessibility requirements for websites are mandated by government policies and legislations. While
many countries have devised web accessibility compliance legislations, the underlying requirements and
protections for accessibility compliance of websites vary. Sometimes, the requirements are not explicitly
stated in relevant legislations as well, leading to inconsistencies in the level of compliance across the
world.
The following is a list of country-wise legislation in some major geographies.
Country Names
United States of America
Regulations
The Americans with Disabilities Act (ADA), 1990
The Rehabilitation Act of 1973 (Section 508 Amendment in 1998)
United Kingdom
Disability Discrimination Act of 1995 (UK, 1995)
Australia
Disability Discrimination Act(1992)
Germany
Ordinance on Barrier Free Information Technology or BITV (Germany, 2002)
France
Equal Opportunities Rights (France, 2004)
Netherlands
Dutch Law on Quality of Government Websites (2006)
India
Government of India Web Guidelines (2009)
Italy
Stanca Act
Ireland
Disability Act of 2005
Figure 1: Country-wise Accessibility Legislation
Non-compliance to accessibility legislations has led to several lawsuits and millions of dollars of
settlement in the recent past. Some of the famous accessibility related lawsuits in the United States are
the National Federation for the Blind (NFB) versus Amazon settlement (2007), Sexton and NFB versus
Target Lawsuit (2007), State of New York (Ramada.com & Priceline.com, 2004), Maguire versus Sydney
Olympic Committee settlement (2000), California Council for the Blind versus Bank of America & Wells
Fargo ATM settlements in Florida and California (2000).
2. Approach and Methods to Check Accessibility Compliance
There are many methods to check web page accessibility – automated as well as manual. While
compliance to some standards can be checked with automated tools, others need to be tested manually;
hence a combination of automated tools and expert testers is required to ensure accurate and
comprehensive conformance testing.
For example, an important requirement of accessibility is to provide equivalent text description for all
6
informational images, and null alternative (alt) message (alt=" ") for non-informational, decorative images.
An automated tool may search the HTML source code of a web page for the presence of image tags,
noting whether an alternative text (alt) attribute is present. A “fail” result might be returned when no alt
attribute is found. On the other hand, the automated tool may not be able to identify whether the alt
attribute was empty (null) or contained text, and whether that text description is an adequate and
meaningful equivalent of the visual data. Hence, to check for the success of meeting this requirement,
both automated and manual testing are required.
The following figure outlines a typical web accessibility assessment approach.
n
n
Online Tools like
aChecker, Wave, Cynthia
Says, Hawking Toolbar
Online Color Contrast
tool (juicystudio.com,
vischeck.com)
Assistive
Assessment
n
n
n
Test with Screen readers
such as JAWS, Windows
Eye, NVDA, Thunder
Test with captioning tool
(MAGpie)
n
n
n
HTML Validator
CSS Validator
Manual code review
End User Testing
(Wherever applicable)
Formative
Assessment
Summative
Assessment
Figure 2: Web Accessibility Assessment Approach
As a first step, during the website’s formative assessment process, a basic level of checking can be done
using online tools like AChecker, Wave etc to judge the level of compliance and identify the problem
areas within the application or the site. During the assistive assessment process, testing with technologies
like screen reader software, captioning tools can be done to find previously undetected problems or
strengthen the findings of formative assessment. However, problems that are not detected either by
formative or assistive assessment methods may still persist. Such problems need to be identified by
manual intervention and employing various manual checking methods like code review, testing using
keyboards etc.
2.1 Automated Checking
Automated accessibility tools can evaluate a single web page or the entire website, and this helps save a
significant amount of time and effort. For example, instead of checking availability of alternative text for
every image manually, - developers can run the site through an automated tool which will confirm
whether alt text is present for all images. The tools look for obvious problems within a web page, and
then generate a list of possible non-accessibility compliant issues.
7
There are two types of automated checking techniques which may be employed to check whether the
code (HTML & CSS) is compliant with technical specifications defined by standard bodies like World Wide
Web Consortium (W3C):
1. Code Validators
HTML Validator
Most web pages are built using mark-up languages, such as HTML or XHTML which have technical
specifications defined.
Validating web pages against defined standards and technical specifications can help improve the quality
and overall accessibility, and can save significant time and money spent towards accessibility compliance
at later stage. However, this validation is not a holistic quality check and is not, strictly speaking,
equivalent to checking for conformance to the specification.
The most commonly used HTML Validators are:
n
W3C HTML mark-up Validator
n
HTML Tidy
n
CSE HTML Validator
n
WDG HTML Validator
CSS Validator
Most web pages are written in HTML, which is used to create pages with structured information, links,
and multimedia objects. But for the proper presentation of the page, that is, for color, text, and layout,
HTML uses Cascading Style Sheets (CSS).
CSS validation services compare the existing style sheets to the CSS specifications, help in finding errors,
typos, or incorrect uses of CSS.
The most commonly used CSS validators are:
n
W3C CSS Validation service
n
CSS Portal CSS Validator
2. Web Accessibility Validators
There are many online tools that check the accessibility of a web page against the various web
accessibility guidelines. Some tools check against a particular guideline like WCAG and some check
against one or more guidelines. Using AChecker, developers can check the web page against Section 508,
Stanca Act, BITV 1.0(Level 2), WCAG 1.0 and WCAG2.0.
Listed below are some of the commonly used web accessibility validation tools:.
8
Achecker
AChecker is used to evaluate HTML content for accessibility problems by entering the location of a web
page, uploading an HTML file, or by pasting the complete HTML source code from a Web page. The results
of AChecker are captured in a report which highlights accessibility problems against specific guidelines.
Identified problems are categorized as::
1. Known problems: These are definite problems – barriers to accessibility, and developers need to
modify the page to fix these issues.
2. Likely problems: This category lists problems that are probable accessibility barriers, but human
intervention is required to evaluate them and make a decision. The page likely needs to be
modified to fix these problems, and even if these issues do not pose accessibility challenges, it is a
good idea to fix them.
3. Potential problems: AChecker identifies certain problems as potential accessibility issues, however,
developers need to confirm whether these are genuine problems or not, and subsequently fix them
when required.
WAVE
WAVE is a free web accessibility evaluation tool provided by WebAIM. It is available as an online tool and
as a toolbar that can be embedded in the Firefox browser. WAVE does not provide any complex report;
instead it shows the original web page with embedded icons and indicators that reveal the accessibility
of that page.
It checks for compliance issues with the Section 508 and WCAG guidelines .Other popular tools used for
accessibility evaluation are EvalAccess, JuicyStudio, Vischeck , Web Accessibility Toolbar(WAT), MAGpie
and others.
2.2 Specialized Checking
People with disabilities require the use of assistive technologies to access the web. For example, people
with low visual acuity or no vision make use of screen readers like JAWS or NVDA to read through web
content. Specialized checking using assistive technologies further ensures accessibility of the website.
n
Screen Readers
Screen readers transform the graphic user interface (GUI) controls such as text, graphics, action
buttons, and menus into an audio interface such as text-to-speech, sound icons or a Braille output
device so that disabled people who are blind, visually impaired, illiterate or learning disabled can
comprehend the content on screen.
Two of the most common screen readers are JAWS, from Freedom Scientific, and NVDA, which is a free
and open source screen reader. These programs can read not only web content but also the Windows
operating system, word processing programs, and other software.
9
These tools read the content in the web page or applications as the users tab through each section of
the page, or provide Braille output. For accessibility testing, we can use screen readers to check if the
website is completely accessible by a blind person or people with low vision.
We need to focus on the following aspects while using screen readers:
- Listen to the entire page to see if all content is included and makes sense.
- Confirm whether the link labels are descriptive. Screen reader users sometimes bring up a list of
links, so links like ‘read more’ or ‘click here’ are not helpful out of context.
- Check if tabulated information can be understood.
n Voice Recognition Programs
Speech recognition or voice recognition programs (VRP),, allow people to give commands and enter
data using their voices rather than a mouse or keyboard. Voice recognition systems use a microphone
attached to the computer, which can be used to create text documents such as letters or e-mail
messages, browse the Internet, and navigate among applications and menus by voice. These
programs are helpful to obtain required text inputs from disabled users including blind or visually
impaired users. Testing with VRPs should be undertaken to figure out the compliance level on this
aspect as many disabled users use them.
n
Speech Synthesizers
Text-to-Speech (TTS) or Speech Synthesizers receive information going to the screen in the form of
letters, numbers, and punctuation marks, and then ‘speak’ it out loud in a computerized voice. Using
speech synthesizers allows computer users who are blind or who have learning difficulties to hear
what they are typing and also provide a spoken voice for individuals who cannot communicate orally,
but can communicate their thoughts through typing. Testing with speech synthesizers should be done
to ensure the application/ website offers the necessary support to disabled users who use these tools.
n
Captioning Software Tools
Captioning software tools are designed to make it easy for multimedia content developers to add
captions to their audio and video content. MAGpie is one such tool which allows the captioning of
web audio and video content for use in leading media players like Quicktime, RealPlayer and Window
Media Player. Checking for captions using such tools eliminates the possibility of non-compliance in
comprehending multimedia content, especially for disabled users, including visually impaired or mute
users.
10
2.3 Manual Checking
Automated accessibility testing cannot check each aspect of web accessibility; hence manual
checking is critical. One of the most important aspects of manual checking is ensuring that
information is perceivable, controls are operable and pages are navigable using only the keyboard.
Keyboard accessibility of web content must be checked across all possible web browsers and a
keyboard input device. Checking for sufficient color contrast between the foreground and the
background color, to ensure text readability and overall page usability is essential to make content
available to users with lower visual acuity.
Manual checking can be done using the following techniques:
n
Using Check Lists
There are defined checklists based on the various guidelines to manually check websites for
accessibility
compliance . The most important checklists are those based on the WCAG1.0,
WCAG2.0 principles and Section 508 guidelines of The Rehabilitation Act, USA..
n
Keyboard-only
Keyboard-only access checks whether all site navigation and functionality are available using only the
standard keyboard, and the user can move freely through the page using only the standard keyboard
without getting caught in a ‘keyboard trap’ (the cursor is ‘trapped’ in one section, widget, or functional
region of the document, and cannot move to another section).
n
Color Contrast
Sufficient color contrast ensures that for text content, all foreground/background color combinations
provide the contrast needed for low-vision users or users with color blindness to view content. Figure
3 depicts how people with different forms of color blindness perceive the colors of a rainbow. People
with color blindness such as Deuteranopia/ Protanopia and Tritanopia face difficulty in distinguishing
between green-red and blue-yellow and their shades of color respectively.
No Color Blindness
Deuteranopia
Protanopia
Tritanopia
Figure 3: Colors of the Rainbow Perceived by Different Forms of Color Blindness
11
Websites like Colorfilter (http://colorfilter.wickline.org/) and Vischeck (www.vischeck.com) provide
different filters that replicate how a color blind person will perceive the content.
A website or application meets color contrast accessibility criteria if:
n All background and foreground color combinations contrast at a 4.5:1 ratio for 14 point text or smaller;
n All background and foreground color combinations contrast at a 3:1 ratio for text larger than 14 points
Color Contrast Analyser and Juicy Studio toolbar can be used to measure the color contrast.
3. Coding Examples that Improve Accessibility
AWe now look at some of the coding best practices that improve the accessibility of a web page: .
1. Abbreviations
Abbreviations are an obstacle to accessibility because screen readers attempt to read the abbreviations as
they are. There are four categories of abbreviations: truncations, contractions, initialisms and acronyms.
The title attribute is essential for the <acronym> and <abbr> tags as screen readers read these aloud.
<abbr class=”truncation” title=”etcetera”> etc. </abbr>
<abbr class=”contraction” title=”Limited”> Ltd</abbr>
<abbr class=”initialism” title=”Tata Consultancy Services”> W3C</abbr>
<acronym title=”Personal Identification Number” class=”acronym”>PIN</acronym>
Avoid using abbreviations in alt or title attribute, as there is no way to define such abbreviations and
screen readers mispronounce them. For instance, instead of the title=”Learn more about W3C” use the
title=”Learn more about World Wide Web Consortium”.
2. Dynamic Pop-Ups
Most dynamic pop-ups are inaccessible to users who cannot operate a mouse. Dynamic pop-ups
comprise of hover displays, date-picker calendars and in-context modal windows. These elements should
be openable, focusable, navigable, operable and closable by keyboard-only events as well as by mouse
events. In the title attribute of the calling link, indicate that the link opens a pop-up (for example, “Open
pop-up that displays ...” or “. . . pop-up window”). Once the pop-up is open, the focus should be placed on
the first table element of the page (for example, on the close link, or on the first text input field). The popup should be closable using keyboard whether by tabbing or pressing the <Esc> key.
3. Fieldset and Legends
The <fieldset> tag is for grouping related elements like checkboxes, radio buttons and related name
fields and the <legend> tag provides the title for the entire <fieldset> contents. Grouping such elements
associates them visually for sighted users and logically for non-visual browsers and unsighted users,
enabling all to navigate a form more easily. The<fieldset> tag draws a line around the related elements
12
and the <legend> tag defines a caption of the <fieldset> element.
<fieldset>
The result is as shown in the figure below:
<legend>Your favourite color</legend>
<input type="radio" name="color" value="red">Red<br>
Your favorite color
<input type="radio" name="color" value="blue">Blue<br>
Red
</fieldset>
Blue
Figure 4: Example of <fieldset> and <legend> tag
4. Form Elements
Form elements enable normal left-to-right, top-to-bottom, section-by-section tab order when designing
forms. Label and instructions should not form a part of form element text or options. The most important
consideration for the accessibility of forms is label configuration and positioning relative to each form
element. With regard to code order and visual presentation, form labels should precede text boxes, text
areas, and select menus but they should follow check boxes and radio buttons.
For accessibility compliance, every form element must have its own unique ID attribute that is associated
with a <label> tag. The ‘for’ attribute of the <label> tag should be identical to the ID attribute of the
corresponding form element. The <label> tags should not be different from a form element and should
be associated with only one form element. This logical connection allows assistive technologies for the
unsighted users to associate with form fields.
5. Headings
Heading tags should be used hierarchically and should ascend in sequence without any gaps (for
example, <h1>, <h2>, <h3> and not <h1>, <h3>, <h4>). When heading tags are styled with formatting
properties directly without regard to their hierarchical structure, screen readers like JAWS and Window
Eyes which use heading tags to navigate through a page are obstructed. In order to format the color, size
and other presentation attributes of the heading tags, use style sheets.
6. Images and Icons
Any image that is informational should be called from an <img> tag, an <area> tag or <input> tag with
type="image" and not from a span or div, so that the alternative attribute can be applied to the image.
This ‘alt’ message is a text equivalent of the image and serves as information to the users in case the
image fails to load or while using the screen readers. If the image is not informational and is used for
decorative purposes, then it should have a ‘null alt’ attribute, so that the screen readers do not read it.
Informational image example
<imgsrc="mobile.gif" width="100" height="100" alt="Samsung Galaxy Note" />
Non-informational image example
<imgsrc="spacer.gif" width="20" height="20" alt=" " />
13
For images that indicate different conditions or states by means of color or form, a text equivalent of the
image should include information about the condition or state. For example, the text equivalent of an
alert icon should not indicate just the visual information such as alt="Alert Icon-Red" or alt="Alert IconYellow" but provide status information such as alt="Alert:Error!" and alt="Alert:Warning!".
7. Skip Navigation
Skip navigation is a method that offers keyboard only users a means to by-pass repetitive global
navigation so that they can jump to the main content of each page. This is done by positioning a visible
link at the top of the page as the page’s first element. Some of the common names of the link are “Skip
Navigation”, “Skip to main content”, or “Jump to main content”.
The format of the calling link is as follows:
<a href="#maincontent" accesskey="2" title="Skip navigation(Acesskey 2)"> Jump to Main Content </a>
The format of the target name anchor depends on the HTML doctype:
For HTML 4, add the following at the top of the main content
<a name="maincontent"></a>
For XHTML 1.0, add the following at the top of the main content
<a name="maincontent" id="startcontent"></a>
8. Tables
Data tables must be properly coded so that information can be read by assistive technologies and
browser agents. Include a hidden <caption> tag that describes the purpose of the table. At a minimum, a
<table> tag should hold a unique id attribute, a class attribute and if <caption> tag is not used a
summary attribute.
Use the <th> tag for row and column headings including its appropriate scope attribute and <td> for
data cells. For screen readers, the scope attributes associates column cells with column headings and row
cells with row headings. Avoid nested and complex table layouts whose headings span multiple columns
or rows since the screen readers may have difficulty in handling them.
<table id=”tblExp” class=”tableclass”>
<caption class=”hiddenMsg”> Expenditure of money for production </caption>
<tr><th scope=”col”>Expenditure</th><th scope=”col”>2011</th></tr>
<tr><th scope=”row”>Quarter 1 </th><td> $2,500 </td></tr>
<tr><th scope=”row”>Quarter 2 </th><td> $3,200 </td></tr>
</table>
14
4. Conclusion
Web accessibility compliance is not a feature that should be added to the site after it has been built.
Instead it should be incorporated in the site development process right from the design phase. The cost
of making a site accessibility compliant after the implementation phase is much more than the cost of
making it compliant during development stage. This also implies less rework in coding and reduced
testing effort. From our past experiences, we have observed that almost 10-15 % additional effort is
required to make a site accessibility compliant if the activity is undertaken after the site goes live.
Some of the testing methods as mentioned in this paper could be employed during or after the
development stage in order to confirm whether a website meets accessibility compliance guidelines or
not. However, all these methods are not dependent on each other and can be employed either in
succession or in silos. The recommended approach would be to adopt or use at least some of the relevant
methods from the automated, specialized and manual checking areas such as testing with Screen
Readers, Captioning Tools, testing with keyboards, checking against standard checklists, analyzing the
color contrast ratio, checking against online tools such as AChecker etc. in order to get a holistic idea
about the level of compliance any particular website has. Validating the HTML,CSS and JavaScript codes
against HTML validators and CSS validators during the development cycle may prove beneficial in making
the site compliant with some accessibility guidelines and result in less rework at a later stage.
With virtually every form of business and service available online, organizations feel the increasing need
to offer an accessible experience, ensuring the engagement of a large and varied audience. A website/
application accessible to all users, irrespective of their physical or mental abilities, results in a more
inclusive Internet experience.
References
[1] Wikipedia, Web Accessibility, accessed Feb 2013, http://en.wikipedia.org/wiki/Web_accessibility
[2] Webaim, Principles of Accessible Design, accessed Feb 2013, http://webaim.org/intro/#principles
[3] w3.org, Introduction to Web Accessibility, accessed Feb 2013, www.w3.org/WAI/intro/accessibility.php
[4] Internet World Stats, Internet Users in the World (June 30,2012), accessed Feb 2013, http://www.Internetworldstats.com/stats.htm
[5] United Nations enable, Factsheet on Persons with Disabilities, accessed Feb 2013, http://www.un.org/disabilities/default.asp?id=18
[6] Tcs.com, Making a web application Operable by disabled users (Oct, 2012), accessed Mar 2013,
http://www.tcs.com/SiteCollectionDocuments/White%20Papers/ITServices_Whitepaper_Making-Web-Application-Operable-Disabled-Users_1112-1.pdf
[7] Usabilitygeek.com, 5 Simple Guidelines To Improve Your Website’s Accessibility, accessed Feb 2013, http://usabilitygeek.com/5-simple-guidelines-to-improve-yourwebsites-accessibility/
15
Contact
For more information about TCS’ consulting services, contact [email protected]
Subscribe to TCS White Papers
TCS.com RSS: http://www.tcs.com/rss_feeds/Pages/feed.aspx?f=w
Feedburner: http://feeds2.feedburner.com/tcswhitepapers
About Tata Consultancy Services (TCS)
Tata Consultancy Services is an IT services, consulting and business solutions organization that
delivers real results to global business, ensuring a level of certainty no other firm can match.
TCS offers a consulting-led, integrated portfolio of IT and IT-enabled infrastructure, engineering
and assurance services. This is delivered through its unique Global Network Delivery ModelTM,
recognized as the benchmark of excellence in software development. A part of the Tata Group,
India’s largest industrial conglomerate, TCS has a global footprint and is listed on the National
Stock Exchange and Bombay Stock Exchange in India.
IT Services
Business Solutions
Outsourcing
All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is
correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in
any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and
other applicable laws, and could result in criminal or civil penalties. Copyright © 2013 Tata Consultancy Services Limited
TCS Design Services I M I 04 I 13
For more information, visit us at www.tcs.com