Hi All

I am using latest version Pega Customer Service for Communications and Pega 7.3.1 version , I found our current WCAG[ ] 2.0 not supporting all the below requirments, please suggest me how I can support below requirements using our current Pega WCAG 2.0

Requirements :

Without restricting the guidelines and requirements of the Web Content Accessibility Guidelines (WCAG) 2.0 in

any way there are four general requirements that provide the foundation for accessible software solutions:

perceivable, operable, understandable and robust. Following these requirements will make software

applications accessible to users with disabilities and also more usable for users in general. Mind that these

requirements aren’t concrete, they function as guiding principles and need to be detailed according to the used

technology.

2.1 Perceivable

Users with disabilities have different ways to access the information and interface components of a software

solution: blind people use a screen reader, visually impaired use screen magnifiers, deaf people can’t hear

audible information but read text and use sign language. To fit the software solution to different ways of

perception, it is necessary to separate design, content and interaction during the developing process. This will

not only make maintenance easier, but also allows to use different layouts, user agents and assistive

technologies.

To meet this requirement consider the accessibility of these components:

_ Non-Text contents

_ Video, Audio, Animation

_ Relations between objects

_ Visual Presentation

The objective is: All information and all user interface components must be presentable to users in ways they

can perceive.

Examples for more detailed requirements:

_ Any non-text information presented to the user (including figures, controls and input elements) must have

text alternatives.

_ Text alternatives are perceivable when using an assistive technology, e. g. a screen reader.

_ If non-text content is implemented in a way that it is ignored by assistive technologies (e. g. background

images in cascading style sheet), this content must not convey any information.

_ If non-text content is decorative or used for visual formatting only, it is implemented in a way that it can be

ignored by assistive technology, e. g. screen reader.

_ CAPTCHAs have to be designed accessible for a wide range of persons using output modes for different

types of sensory perception. Examples are: Gap texts, abstract questions or arithmetical problems, audible

CAPTCHA.

_ Text alternatives (e. g. captions in videos) are provided and presented in equivalent information for prerecorded

audio-only content.

_ An audio track or equivalent text alternative is provided that presents equivalent information for prerecorded

video-only content.

_ All contents should be implemented in a logical sequence (also in the source code), so that output

sequence of the assistive technology (e. g. screen reader) is comprehensible and relations between

elements can be recognized.

_ Instructions and operating content should be provided based on different contentual advices.

_ The following component should not be used as standalone: shape, size, visual location, orientation, or

sound

_ Programmatic access to color and other visual presentation coding should be used.

_ Elements for representing an action, a response or another visual element should not be color-coded only.

_ Large-scale text and images of large-scale text have a contrast ratio of at least 3:1. Small-scale text and

images of large-scale text have a contrast ratio of at least 4,5:1.

_ The visual presentations of blocks of text have to be available at all time although personal needs may

differ. Alternatively, the application could provide an own function (e. g. high contrast mode).

_ 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. The scale up to 200 percent should not

result in a loss of content or functionality. The distance between text elements should be used in a way that

those elements do not overlay each other once the font size is adjusted.

_ Text is used to convey information rather than images of text, except images can be visually customized

and assisitive technologies can interpret the information or a presentation of text is essential to convey

information.

2.2 Operable

People with certain motorical disabilities as well as blind people cannot use the mouse. Instead they are

working with keyboard navigation. Therefore all interactive components need to be operable through the

keyboard, time-based interaction is avoided and multimedia is controllable. Because keyboard navigation

differs from mouse navigation and blind users can’t see the displayed context, comprehensible orientation is

another important task to be implemented.

The objective is: All user interface components and navigation must be operable.

Examples for more detailed requirements:

_ All interactive elements should be operable through the keyboard.

_ All functions should be activatable through the keyboard.

_ The keyboard focus can be moved to a component and away from that component only by using the

keyboard interface.

_ Access keys should be used to enhance the efficiency of an operation. Access keys should be

documented and used consistently.

_ All contents can be perceived without unexpected changes in content or context that are a result of a time

limit.

_ If timing is enabled, it can be: turned off, adjusted or extended by the user.

_ When an authenticated session expires, the user can continue the activity without loss of data after reauthenticating.

_ Content that is updated periodically by software or that is streamed to the user agent has to be controllable.

_ Any moving, blinking, scrolling or any auto-updating information can be started, paused and stopped by

the user.

_ Flickering or flashing content should be avoided.

_ The topic or the purpose is described by a heading or a label and can be programmatically determined.

_ Topics and purposes are structured logically.

_ If the purpose of related elements is described by a surrounding label, all of those elements must be

programmatically linked to that label.

_ Interface components and their labels should be linked with each other so that it can be programmatically

determined.

_ Related elements, an alphabetical order or an enumeration should be structured as a list so that those

elements can be programmatically determined.

_ In data tables, all columns should be described by meaningful column headings. All rows should be

described with meaningful row headings, if needed. Table headings can be programmatically determined.

_ Layout tables which are only used to position elements (e. g. in markup languages like HTML), should not

be programmatically determined as data tables by assistive technologies, e. g. screen readers.

_ Blocks of content that are repeated in various dialogs or that need disproportional effort to pass can be

bypassed.

_ The navigation sequence with the keyboard should meet the logical order of elements of a dialog and

therefore not affect the meaning or the operation of focusable elements.

_ Focusable components should get focused in the order that preserves meaning and operability.

_ The focus indicator on an user interface with operable interface components should always be visible.

_ Dialogs (e. g. web pages, HTML frames or window dialogs) should contain unique and meaningful titles.

Titles should be used to identify the subject of a dialog.

_ The position in an application can be identified. The current location within the navigation should be

indenticated. In web pages a breadcrumb and a site map should be provided. In web pages a link to the

main page should be provided on each subpage.

_ Objective and purpose of each link or interactive element can be identified. Link texts as well as labels of

interactive elements should be short, but still unique and meaningful. Links/interactive elements should

include the type of a linked document as part of the description.

2.3 Understandable

This requirement aims on the usability of the user interface for people with disabilities. All users need to

understand the information and operation of the user interface. For people with disabilities logical structured

texts, predictable behaviour of the user interface, usefull error management as well as context-sensitive help

information are essential for an understandable user interface.

The objective is: All Information and the operation of the user interface must be understandable.

Examples for more detailed requirements:

_ The default human language used in the application can be programmatically determined using assistive

technologies, e. g. a screen reader.

_ Each passage or phrase in the content can be programmatically determined if the content differs from the

default language.

_ Specific definitions of words or phrases, including idioms and jargon, can be identified.

_ An expanded form or meaning of abbreviations is available.

_ A change of the context is not initiated when any component receives the focus.

_ Changing the setting of any user interface component does not automatically result in a change of context.

_ A user should be advised before the context is changed by using a component.

_ A mechanism should be available to turn off automatic changes of context, if needed.

_ The relative order of the navigation should be repeated on each dialog (e. g. web page or within a page),

unless a change is initiated by the user.

_ Navigational elements, which are labelled identically, should contain the same functionality.

_ Clear and appropriate terms should be used for the elements of the navigation.

_ The item that is in an error state can be identified and the error is described to the user in text.

_ Input errors by the user should be automatically detected and suggestions should be provided.

_ A mechanism is available for reviewing, confirming, and correcting information before finalizing the

submission of an entry.

_ Labels or instructions should be provided in an application when the content requires user input. An

additional advice for a required element should be implemented as part of the label, e.g. as an asterisk.

Additionally, those form elements can be color-coded to increase the awareness.

_ Context-sensitive help is available which helps to fulfil a user’s task.

2.4 Robust

People with disabilities use different user agents and assistive technologies, such as internet browsers , screen

readers or screen magnifiers. Therefore the software solution has to be compatible with these technologies.

The objective is: All content must be robust enough that it can be interpreted reliably by a wide variety of user

agents, including assistive technologies, e. g. screen readers and screen magnifiers.

Examples for more detailed requirements:

_ Markup languages should be parsed correctly.

_ All information is perceivable when using a screen reader.

_ Name, role and value (including states and properties) of each interface component are programmatically

determined and perceivable when using an assistive technology, e. g. a screen reader.

_ Role and name of interface components can be programmatically determined.

_ A user is able to set states, properties, and values for corresponding interface components.

_ Notification of changes to these items is available to user agents, including assistive technologies.