ACCESSIBLE DESIGN THEMES

Similar documents
EPiServer s Compliance to WCAG and ATAG

Color: Are the Web pages designed so that all information conveyed with color is also available without color? Reference Section (c).

Duke Library Website Preliminary Accessibility Assessment

Section 508 Evaluation Template

Adobe Sign Voluntary Product Accessibility Template

Adobe Campaign (15.12) Voluntary Product Accessibility Template

SmartBuilder Section 508 Accessibility Guidelines

Lectora 508 Compliance Document

Adobe Bridge CS5.1 Voluntary Product Accessibility Template

Adobe Experience Manager (AEM) 6.2 Forms Workbench Voluntary Product Accessibility Template

Adobe Dreamweaver CC Voluntary Product Accessibility Template

Adobe Digital Publishing Solution for Windows Voluntary Product Accessibility Template

Agilix Buzz Accessibility Statement ( )

Voluntary Product Accessibility Template

Adobe InDesign CC Voluntary Product Accessibility Template

Adobe Business Catalyst Voluntary Product Accessibility Template

Adobe Fireworks CS6 Voluntary Product Accessibility Template

VPAT. Voluntary Product Accessibility Template. Version 1.3

Adobe Contribute 6.5 Voluntary Product Accessibility Template

Adobe Illustrator CS5.1 Voluntary Product Accessibility Template

SecurityCenter 508 Compliance

Adobe Illustrator CC Voluntary Product Accessibility Template

Adobe RoboHelp 9 Voluntary Product Accessibility Template

VMware vsphere Web Client 6.5 VPAT

Date: April 3, 2017 Name of Product: Cisco Prime Infrastructure v3.1 Contact for more information:

Date: March 15, 2017 Name of Product: Cisco Umbrella version Dashboard 2 Contact for more information:

Adobe Experience Manager (AEM) 6.2 Forms - Output Voluntary Product Accessibility Template

Adobe CQ5.4 Voluntary Product Accessibility Template

Date: December 21, 2017 Name of Product: Cisco WebEx Web App Meeting Center v3.4 Contact for more information:

Date: September 5, 2017 Name of Product: Cisco WebEx Product (web) Pages WBS32.3 Contact for more information:

Voluntary Product Accessibility Template PowerBroker Identity Services

Voluntary Product Accessibility Template (VPAT )

Section Software Applications and Operating Systems Web Conferencing Service (WCS) Detail Voluntary Product Accessibility Template

VMware vcenter Site Recovery Manager 6.1 VPAT

Fusion 4 General Help VPAT

All contents are Copyright Cisco Systems, Inc. All rights reserved.

Adobe Bridge CS6 Voluntary Product Accessibility Template

College Website Review and Revision for Accessibility

VMware AirWatch 8 VPAT

Adobe ColdFusion 10 Voluntary Product Accessibility Template

Adobe Photoshop Lightroom 3 Voluntary Product Accessibility Template

VMware vsphere Update Manager 6.0 VPAT

Axway Voluntary Product Accessibility Template (VPAT)

Teamcenter Voluntary Product Accessibility Template. Summary Table Voluntary Product Accessibility Template

Voluntary Product Accessibility Template (VPAT) ACUE Course in Effective Teaching Practice

Criteria Supporting Features Remarks and explanations Section Software Applications and Operating Systems. possible exceptions

Voluntary Product Accessibility Template (VPAT )

Adobe LiveCycle Reader Extensions ES3 Voluntary Product Accessibility Template

Voluntary Product Accessibility Template Retina Network Security Scanner

Google Forms. Summary Table. Date: 11/2014 Name of Product: Google Forms Point of Contact: Richard Wu. Criteria Supporting features Remarks

Voluntary Product Accessibility Template

Voluntary Product Accessibility Template

Adobe Omniture Discover Voluntary Product Accessibility Template

VMware vrealize Code Stream 6.2 VPAT

State of Colorado. ADA IT Accessibility Standards For the Blind and Visually Impaired

Section Software Applications and Operating Systems - Detail Voluntary Product Accessibility PageCenterX

Adobe EchoSign Voluntary Product Accessibility Template

Voluntary Product Accessibility Template

Adobe LiveCycle Correspondence Management ES4 Voluntary Product Accessibility Template

VMware vrealize Code Stream 1.0 VPAT

Adobe Acrobat.com Voluntary Product Accessibility Template

Voluntary Product Accessibility Template

Adobe Experience Manager (AEM) 6.2 Forms - Reader Extensions Voluntary Product Accessibility

Web Accessibility Checklist

VPAT (Voluntary Product Accessibility Template)

Handshake Accessibility Overview

Voluntary Product Accessibility Template (VPAT) Applicable Sections

VPAT Voluntary Product Accessibility Template. Version 1.3

YuJa Enterprise Video Platform WCAG 2.0 Checklist

FAO Web Content Accessibility Guidelines

Adobe LiveCycle PDF Generator ES4 Voluntary Product Accessibility Template

Schoology Voluntary Product Accessibility Template (VPAT)

Adobe LiveCycle Digital Signatures ES3 Voluntary Product Accessibility Template

Adobe Story CC Plus Voluntary Product Accessibility Template

Adobe Experience Manager (AEM) 6.2 Forms - Digital Signatures Voluntary Product Accessibility Template

Voluntary Product Accessibility. Retina CS Enterprise Vulnerability Management

Networx Universal. Supporting Features. Remarks and explanations. Criteria

Adobe LiveCycle Rights Management ES3 Voluntary Product Accessibility Template

VPAT FOR WINDCHILL 11.X

Science. Voluntary Product Accessibility Template: Section 508

For a detailed description of the parent features and benefits, please refer to the following URL:

Voluntary Product Accessibility Template PowerBroker for Mac

WCAG 2.0 Checklist. Perceivable Web content is made available to the senses - sight, hearing, and/or touch. Recommendations

VPAT. Event Log Management v10 Accessibility. Version 1.3 of the VPAT Template

VMware Virtual SAN with vsan Health Check Plugin 6.0 VPAT

Adobe FormsCentral (Desktop Application) Voluntary Product Accessibility Template

Adobe Experience Manager (AEM) 5.6 for Forms Portal Voluntary Product Accessibility Template

Adobe FrameMaker (2015 Release) Voluntary Product Accessibility Template

Adobe Experience Manager 6.0 Voluntary Product Accessibility Template

Voluntary Product Accessibility Template (VPAT)

WorkCentre M118/118i. Voluntary Product Accessibility Template (VPAT) Learn more about Xerox and Section 508 at our website:

VPAT. Voluntary Product Accessibility Template. Version 1.3. Summary Table VPAT. Voluntary Product Accessibility Template. Supporting Features

Adobe LiveCycle Server Administration ES3 Voluntary Product Accessibility Template

Community Templates for Self-Service

Voluntary Product Accessibility Template

Adobe FrameMaker 12 Voluntary Product Accessibility Template

VPAT. Voluntary Product Accessibility Template. Version 1.3 *

VMware vcenter Orchestrator 5.5 VPAT

Guideline 1.2 Time-based Media: Provide alternatives for time-based media Success Criteria Recommendations Met

CBORD s Response to Voluntary Product Evaluation Template For GET

Transcription:

WCAG GUIDELINES The Web Content Accessibility Guidelines (WCAG) has been made to guide the Web Content Developers and the Authoring Tools Developers in order to make the Web Content more accessible to a wide range of people. The current WCAG version 1.0 had passed the W3C recommendation on 5 May 1999. This is a revised and updated version of the previous WCAG which previously passed the W3C Recommendation on 24 Mar 1999. As the Users differ on the basis of devices they use for accessing the Web Content (e.g. desktop browsers, voice browsers, mobile phones etc.), the surroundings they work in (e.g. noisy surroundings, area with low speed internet speed etc.) and also the Operating Systems they work into, therefore this becomes an additional responsibility of the Web Content Developers to make the Web Content accessible to more and more people with varied usage styles. The Web Content Accessibility Guidelines was formulated so that the Web Content developers and the Authoring Tools Developers could have a platform on the basis of which they can manage the Web Content. These set of Guidelines provides the principles of accessibility and the design ideas. Before discussing any details of the WCAG the readers should consider the accessibility issues pertaining to the Web page design as the End users may be operating in contexts which are quite different from what we normally work in: The Users may have a difficulty in reading or comprehending the text mentioned on the Web Pages. The hardware devices that they are working on may not support the graphics or the screen may be a text only screen. The area from where they are operating or accessing the Web Contents has slow internet connection speed which prevents the heavy pages to load. The End Users might not be able to see, hear, move or may be not able to access the data on the Web at all. The End Users might be using an older version of the internet browser or a completely different browser entirely say, voice browser. The Operating System of the User might be different. The Content Developers are required to consider these points and many others that co exist with these issues during the page design. For example, when a Web Content developer uses the FONT tags for controlling the size and weight of the fonts on the web page then depending on the browser used the display of the same content differs. Therefore, the W3C standards suggest use of the style sheets (CSS) to control the formatting of the Web Contents.

ACCESSIBLE DESIGN THEMES The WCA Guidelines address the two major themes: 1. Ensuring the Graceful Transformation The Guidelines under this section dictate the Content Developers to create pages which can transform gracefully. Graceful Transformation refers to the fact that the Web Page is accessible despite of the constraints as described above. The constraints like physical, sensory and cognitive disabilities, technological constraints and working constraints should have no effect on the accessibility of the information that the Web page is delivering. In order to design the pages such that they transform gracefully one should follow the following points: 1.1 There should be text equivalents provided for every non textual element on the web page. This is especially applicable for the Users who are blind, as they can use the screen reader technology to render the text information on the Web page. 1.2 The Web Content Developers should design the pages in a manner such that they are not dependent on a particular type of hardware. This means that a User who has a low resolution screen or a black and white screen should also be able to access the full information from the Web page. 1.3 The Presentation of the content on the Web page should be separate and distinct from the structure that was defined for the page. 2. Making the Web Content Understandable and Navigable The contextual information provided by the Web pages is often not gathered completely by the Web Users because of their style of accessing the Web Content. The Users, if using the speech synthesis or Braille devices might be able to access only one word at a time. Also if they have a small sized screen display then they would be able to view only a small portion of the Web page at a time. These reasons prompt the Content Developers to make the Web Content Understandable and Navigable to a large set of Users. The Navigation tools and orientation information should be provided on the pages in order to maximize the accessibility and usability of the Web Pages. This section also prompts the Web Designers to design the pages in more iconic style so that the Users with a weak reading and comprehending power may not feel difficulty in accessing the Web Content. The Design of the pages with the use of more icons and symbols is also included in the Web 2.0 design specification.

PRIORITIES In accordance to the Guidelines followed by the Web Content Developers the Working Group of the World Wide Web Consortium (W3C) has formulated the Priorities of the Guidelines. This classification of the Priorities into three major sections is based on the impact of the checkpoints on the Web Accessibility by the End Users. The Priorities are classified into three different sections as: PRIORITY 1 A Web Content Developer must satisfy all the guidelines which are inclusive in the Priority 1 checkpoints. In case of escaping it one or more groups of people will find it impossible to access the information presented on the Web Page. This Checkpoint is the basic requirement for some groups of people for accessing the Web Documents. PRIORITY 2 A Web Content Developer should satisfy the guidelines listed under Priority 2 checkpoint. However, this is not mandatory to use but its usage eases the Web Content Accessibility by some groups of Users. The guidelines listed under this priority level if satisfied removes the significant barriers that a group of Users might face in order to access a Web Page. PRIORITY 3 The Guidelines listed under the Priority 3 checkpoint is optional for the Web Content Developers for using and implementing them onto the Web Pages. Satisfying these guidelines will improve the accessibility of the Web documents by nearly all class of Users. All the guidelines that are categorized into these three checkpoints are no hard lined, as their implementation is dynamic and completely dependent on the Projects.

CONFORMANCE On the basis of the Web Content Developers implementing the Guidelines the three levels of Conformance is defined as below: CONFORMANCE LEVEL A If all the Priority 1 checkpoints are satisfied then the Web Page is granted the Conformance Level A. CONFORMANCE LEVEL AA If all the Priority 1 and Priority 2 checkpoints are satisfied then the Web Page is granted the Conformance Level AA. CONFORMANCE LEVEL AAA If all the Priority 1, Priority 2 and Priority 3 checkpoints are satisfied then the Web Page is granted the Conformance Level AAA. WEB CONTENT ACCESIBILITY GUIDELINES Guideline 1: Provide equivalent alternatives to all non text content on the Web Page. The Web Content Developer should provide the contents to the User such that they convey the same function and/or purpose as auditory and visual content. Due to a variety of reasons, many groups of people are not able to view the images, movies, sounds, applets etc. directly. This asks for the demand of provision of the equivalent information about those auditory and/or visual contents of the Web Page. This Guideline emphasizes the importance and advantages of providing the text equivalents of the non textual elements used on the Web Pages like for the images, pre recorded audio/video. The advantages of using the text equivalent is judged by the ways in which the Web Content are accessible by a wide variety of Users of different disability groups using a variety of technologies that they use. By the implementation of the text equivalent on the Web Pages the speech synthesizers and Braille devices provides output readily and can be represented visually on computer displays and paper. Users who suffer from the slow internet connection speed face the problem of the page not getting loaded properly and if there are some information that are depicted with images, audio or video files then it becomes impossible for them to access this information. Use of the text equivalents provides an idea of the contents of the page.

For example, there is a Map of the area whose Web page is being browsed by the Users, then in any of the above cases if the text equivalent for the map has not been used then the information provided by the Map is not gathered by the End Users. Therefore on the implementation of the text equivalent for the map gives the User an idea that what exactly that element is for. The Checkpoints on which the implementation of this Guideline can be tested are as below: Provide a text equivalent for each and every non textual element used. This can be done by using alt, longdesc, or in element content. The non text element includes images, audio files and/or video files. [Priority 1] Provide the active region of a server side image map with the redundant text links. [Priority 1]. Provide auditory description of the important information of the visual track of a multimedia presentation on the Web page. This is helpful for some groups of people with physical disabilities. [Priority 1]. Provide and synchronize the text equivalent alternatives in the form of captions for a real time based multimedia presentation like a movie or a flash animation. [Priority 1]. Guideline 2: Color should not be the only parameter The Web Content Developers must ensure that the contents on the Web Page including the text and graphics used are understandable when the Page is viewed without color. Color should not be the only parameter to convey the information. This is because a considerable percent of the Web Users suffer from the ailment of color blindness because of which they are unable to differentiate between the colors which are of similar contrast. Also many people still access the Web contents on a monochrome display device therefore the information conveyed via the use of the different color schemes does not fulfill the purpose. The Checkpoints on which the implementation of the Guideline 2 can be tested are as below: The information that is conveyed with color must also be available without color. The information should be conveyed with the help of context or markup. [Priority 1]. The foreground and background color schemes used should be contrasting enough so that the Users having color deficits should be availing all the information conveyed. This is also useful when a black and white display device is used by the Users. [Priority 2 for Images], [Priority 3 for text].

Guideline 3: Proper use and implementation of Markup and Style Sheets The Web Content Developers are required to mark up the documents such that the display of the Web Contents is uniform in all the browsers and platform. In case the markup for a presentation is misused then it becomes difficult for the Users to navigate through the pages. Also if the Web Content Developers are using the presentation markup rather than structural markup for conveying the structure then it becomes difficult for the Users to render a page, if they are using some other devices. The Web Content Developers should consider the fact that the formatting tags used by them have varied results on the different browsers and more problems arise in case the End Users are using the older versions of the browsers. The Checkpoints on which the implementation of the Guideline 3 can be tested are as below: Implementation of the Markup instead of Images to convey the information. [Priority 2]. The formal grammars must be validated in the creation of the documents. [Priority 2]. Instead of using the HTML FONT tags use the CSS (style sheets) to control the size of the fonts on the Web Pages. Instead of using the absolute units like pt or px use the relative units like percentage lengths. On the basis of the specification document provided the Web Content Developers should use the header elements properly in order to convey the document structure. For example, the H1 tags are used for the document headings and then H2 for the sub headings and so on. The items which have to be displayed as listed items in the Web Pages should be marked up using the tags for the listings. For example, in HTML the tags like OL, UL and DL should be used to display the listed items in an ordered fashion. The Quotation markup should not be used for formatting effects like while using indentation. Guideline 4: The Use of the Natural Language should be clarified. This Guideline proposes the use of markup such that the pronunciation or interpretation of abbreviated text is facilitated. This also helps in the understanding of the foreign text written on the Web Page. The Web Content Developers are advised to markup the natural language changes in the Web Document so that the speech synthesizers and Braille devices can automatically switch to the new language and thereby making the document more accessible to the multilingual Users.

In order to do so the predominant language of the document should be identified by the Content Developers. The Web Content Developers are also advised to use the expansions of all abbreviated texts used on the Web Document. When the use of the Natural Language is clarified then the process of Search Engine Optimization (SEO) process becomes easy to find the key words and identify the documents in different languages. Use of the Natural Language Markup also improves the readability of the Web Contents by a wide variety of Users which also include the groups of people having learning and cognitive disabilities. The Checkpoints on which the implementation of the Guideline 4 can be tested are as below: Identification of the natural language of the document s text. [Priority 3] For all the abbreviations or acronyms used throughout the Web Pages their respective expanded forms should be mentioned there also. [Priority 3] Identification of the changes in the natural language of the Web Document. [Priority 1] Guideline 5: Graceful Transformation of the Tables created on the Web Pages. The Web Content Developers are guided to use the tables that transform gracefully. This is advised so that the information provided in the form of tabular data are accessible through different browsers. The Web Content Developers are directed to use the tables for displaying the information only when the information that has to be displayed is in the form of tabular data. Some Web Page Contents allow the Users to navigate through the table cells to access the table header and other tabular information, therefore if the tables are nor marked up properly then the Users will be unable to access the information. The Checkpoints of this Guideline also directly benefits the Users who access a table through auditory means or have small screen displays and hence can access only a portion of the data in one go. The Checkpoints are: Identify the Table rows and column headers properly. For example, in HTML TD is used for the identification of data cells and TH is used for headers. [Priority 1] Data tables having two or more logical levels of row and column headers the Web Content Developers are advised to use the markup in order to associate the data cells and header cells. [Priority 1] The data that is displayed on the Web page as tabular data should also make sense or should also be usable if they are presented linearly. [Priority 2] The structural markup of the Tables should not be used for the purpose of visual formatting. [Priority 2]

The summary equivalent of the Tables used on the Web Page should be provided. This attribute helps the User to gather some information of the Tabular data even in case if the tabular data is not displayed completely. [Priority 3] The abbreviations should be provided for the header labels of the Tables used in the Web Pages. [Priority 3] Guideline 6: Evolution in the Technologies should not hinder the Page Accessibility. With the evolution and implementation of the newer technologies the process of accessing the information through the Web Contents should not be hindered. This Guideline does not discourage the web Content Developers to work in compatibility with the newer technologies; instead it guides them to make their pages such that the Users who are dependent on the older technologies are also able to access the full information from the Web Pages. For example, a Web Page that is displayed correctly in Internet Explorer version 7 or version 8 should also be displayed concurrently on the earlier versions of the same browser like version 5 or 6. The Checkpoints those test the implementation of this Guidelines by the Web Content Developers are as follows: The Web documents should be readable without the CSS implied on those pages. This guides the Web Content Developers to organize the Web Contents logically such that even if the style sheets are either turned off or not compatible with the browser used it should be a meaningful. [Priority 1] In case of the usage of the dynamic contents for the Web Pages their respective equivalents should be updated along with contents. [Priority 1] The Web Content Developers must ensure that the pages are usable and render the same information even if the style sheets, scripts or applets are turned off or not supported by the User system. [Priority 1] The Scripts, applets and style sheets used for the Web Contents should be device independent. [Priority 2] The Web Content Developers should ensure that the dynamic content are accessible. Otherwise they should provide an alternative presentation or page. [Priority 2]

Guideline 7: The Content that changes on the basis of real time should have the User control on them. The styles those are used on the Web Pages like rolling, scrolling, blinking or automatic updating of the Page content should be having the User control over them. The user should be able to stop or pause the scrolling, auto updating and blinking of the objects used on the Web Pages. This guideline does not discourage the Content Developers from using these effects but instead they guide them to provide the additional functionality such that the Users with physical disabilities can access the information from the Web Pages. The BLINK and MARQUEE elements of the HTML are not defined anywhere in the W3C specification and therefore these should not be used. The Checkpoints on which the implementation of the Guideline 7 can be tested are as below: The screen should not be allowed to flicker unless allowed by the User Agents. [Priority 1] The blinking of the Web Contents should be avoided unless allowed by the User Agents. [Priority 2] The contents those are shown in the marquee style either through HTML or flash animation should have the room for the Users control to freeze the moving contents. [Priority 2] If the facility of auto refresh is provided on the page then the User Agents should be having the control to temporally stop the service. [Priority 2] Guideline 8: The User Interfaces used in the Web Pages should have direct accessibility. The Web Content Developers are required to make use of the accessible design principles in case they are using the User Interfaces for the Web Content. The content should be accessible independent of the devices those are used by the Users to access the information. In case there is no interface for the embedded object then the Web Content Developers should provide the alternative accessible solution for this. For example, the Users should be able to access the data without the help of mice. This means that there should be keyboard operability.

The Checkpoint on which the implementation of the Guideline 8 can be tested is as below: The elements those are driven by the program like scripts, applets etc should be directly accessible or compatible with the associate technologies present. Guideline 9: Aim for achieving Device Independence The Web Content Developers should not develop the pages on the basis of accessibility of one set of devices. The End Users access the Web Contents with a variety of I/O devices, therefore the Web Content Developers should not limit the choices of the End Users. Achieving the Device Independence means that the users are free to choose the device according to their comfort level to access the Web Content and the web contents should be compatible with these devices. For example, if a button in the form functions only on the mouse clicks then alternative solution should be provided to the End Users who are accessing the Web Contents without mice and are using only keyboards. The Checkpoints on which the implementation of the Guideline 9 can be tested are as below: The image maps provided should be preferred to be client based rather than the server based. The server based image maps should be used only in case the regions cannot be defined with an available geometric shape. [Priority 1] The Web Content Developers must ensure that the elements used in the Web Pages should have their own interfaces. There should also be an assurance that the interfaces should be working independent of the device configuration at the Users end. [Priority 2] If the Web Content Developers are using the scripts on to the Web Pages then the logical events handlers should be specified instead of the device dependent event handlers. [Priority 2] The tab controls used in the Web Pages should be made logical with the use of links, form controls and objects. [Priority 3] For the Web Pages in which the contents are large enough then the keyboard shortcuts should be used for easy navigation. [Priority 3]

Guideline 10: Use of Provisional/Temporary solutions. The Web page development and designing should be done in such a way that the assistive technologies that are used by a group of people are compatible for accessing the Web Contents. For example, if the User is using an old browser then they will not be permitted to navigate to an empty edit boxes. The Checkpoints on which basis the implementation of Guideline 10 is tested are as below: If on the click event of any element the spawned window is getting opened then there should be a proper message to the User about this. For example, in the text equivalent of the link it should be specified that Click here to view in New Window. [Priority 2] For the form controls with implicit associated labels, the labels should be properly positioned. [Priority 2] The tables with laid out text and word wrapped columns should be provided a linear text alternative. [Priority 3] The input fields those are provided in the forms should have default place holding characters so that the Users find it easy to know what they have to enter in that field.for example, in a Login form, there are two input text boxes, there should be default text written as Username and Password written so that it works as a guide for the users. [Priority 3] The Web Content Developers should not provide the links adjacent to each other without a break or period. There should be a non link character or a printable character after each link in case of adjacent links. [Priority 3] Guideline 11: Implement the W3C Technologies and W3C Guidelines. The Specifications and the Guidelines provided by the World Wide Web Consortium (W3C) Working Group should be followed wherever possible. The Web Content Developers should follow the accessibility guidelines and other specification for making the Web Pages in order to make it usable for a wide population accessing the information from the Web through a variety of platforms and technologies. In case the W3C technology cannot be implemented or after implementing the Web Content does not transform gracefully, there should be an alternative version of the content provided so that it is accessible.

The reasons for which the W3C technologies are recommended are as below: 1. They include built in accessibility features. 2. They undergo early review so that the accessibility features are considered during the design phase. 3. They are developed in an open, industry consensus process. Some formats like PDF, Shockwave etc. are non W3C formats and they are not accessed in case of using the standard applications. In case the inaccessible technologies are used then there should be the provision of equivalent accessible pages in W3c formats. For example, if there is an option to download a PDF format file then there must be an additional option of viewing the same document as HTML Document. The Checkpoints for the Guideline 11 are as below: The Web Content Developers should use the W3C technologies if they are available and should prefer the latest versions of them. [Priority 2] The Web Content Developers should avoid the use of the older/deprecated technologies. [Priority 2] There should be additional comments displayed on the Web Page so that the Users can access the documents according to their choice of the natural language and understanding. [Priority 3] In case the Web Content Developers are unable to create the pages according to the W3C technologies then there should be an alternative solution provided so that the Users should not face any problems while trying to access the documents. [Priority 1] Guideline 12: Providing the Users with the Help Information. The Web Content Developers should provide context and orientation information so that all groups of Users can use and access the documents. When the page contents are more complex then this becomes mandatory for the Content Developers to provide the Users with this added functionality. The Checkpoints for the Guideline 12 are as follows: Use the TITLE frame in order to facilitate the frame identification and navigation. [Priority 1] The relation between the frames should be made clear with the use of the description attribute in case only the frame titles are not appropriate. [Priority 2] If the Page contains large piece of Information then the whole should be divided properly into small and manageable groups. [Priority 2]

The Labels used on the Web Page should be explicitly associated with their controls. [Priority 2] Guideline 13: The Navigation methods and mechanisms should be clear. The Web Content Developers should use the navigation mechanism consistently and properly in a Web Page so that there is no hassle for the users while navigating through the Web Pages. The navigation mechanisms include orientation information, navigation bars and site map. This is done to increase the probability that the person will find the document for which they are looking for. If the navigation mechanism used is clear and consistent then it also do help the groups of people with cognitive disabilities and thereby increasing the User base of the Web Page. The Checkpoints to check the implementation of the Guideline 13 are as follows: The TITLE tags should be used for navigation links on the pages. [Priority 2] The metadata tag must be added to al pages in order to add the semantic information to pages and website. [Priority 2] The Site map must be provided for the Web site so that the Users can find it easy to find what they are searching for. [Priority 2] Consistency should be maintained while providing the navigation mechanisms. [Priority 2] The navigation bars and tags should be highlighted so that the Users can get a know how of which one is active. The tabs and bars should also be given the access to navigation mechanism. [Priority 3] The links which can be grouped together should be combined in a single group. [Priority 3] In case the Search functionality is present in the Web Page then the searches should be properly categorized for separate distinctive searches. [Priority 3] The multi line ASCII art symbols should be skipped. [Priority 3]

Guideline 14: Simplified and Clear Documents. The Web Content Developers must ensure that the documents are clear and simple so that a wide population of Users is able to understand this. They should maintain a consistent page layout throughout the website. The graphics used should be recognizable and the language used should be easy to understand in order to benefit all the Users. The Checkpoints for testing the implementation of the Guideline 14 are as below: The Language used for the documentation purpose should be clear and simple. [Priority 1] Graphic and auditory presentations should be used to supplement the text used on the Web Content. [Priority 3] The Style sheets that are made should be developed such that they are consistent across the pages. [Priority 3]