Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Make sure your application conforms to accessibility guidelines

Updated on September 14, 2020
Note: This article is not compatible with Pega Platform™ 8.1 and later.

For computer software, "accessibility" describes how usable a system is for people with disabilities of various types, including people who cannot use a computer mouse and people using assistive devices, such as screen readers, to use software applications.

According to Wikipedia, "The World Wide Web Consortium (W3C)'s Web Accessibility Initiative (WAI) is an effort to improve the accessibility of the World Wide Web (WWW or Web) for people with disabilities. People with disabilities may encounter difficulties when using computers generally, but also on the Web. Since people with disabilities often require non-standard devices and browsers, making websites more accessible also benefits a wide range of user agents and devices, including mobile devices, which have limited resources."

"WCAG 2.0 is organized around four design principles of Web accessibility: Perceivable, Operable, Understandable, Robust . Each principle has guidelines, and each guideline has testable success criteria at level A, AA, or AAA ."

Every development team needs to take into account how well the software it delivers conforms to the success criteria for accessibility established by WAI. A reasonable goal is to meet the success criteria for WCAG 2.0 (Level AA). The checklist below will help your efforts.

WCAG 2.0 (Level AA) Compliance Checklist

Images

  • All images, form image buttons, and image map hot spots must have appropriate, equivalent alternative text.
  • Images that do not convey content, are decorative, or contain content that is already conveyed in text must be given null alternative text (alt="") or implemented as CSS backgrounds.
  • All linked images must have descriptive alternative text.  
  • Equivalent alternatives to complex images must be provided in context or on a separate (linked and/or referenced via the longdesc property) page.

Forms

  • Form buttons must have a descriptive value. Example code:
    <input type="image" alt="Submit Search" value="Submit Search" src="https://docs-previous.pega.com/media/template/search.gif" class="transparent">
  • Form inputs must have associated text labels, or, if labels cannot be used, a descriptive title attribute.
  • Required form elements or form elements that require a specific format, value, or length provide this information within the element's label (or if a label is not provided, within the element's title attribute). Example code:
    <label for="firstname">First Name <span class="required">(required)</span></label><input type="text" name="firstname" id="firstname" />
  • If you use form validation, present error messages in an efficient, intuitive, and accessible manner. Clearly identify the error, provide quick access to the problematic element, and let the user fix the error easily and resubmit the form.

  • If an input error is detected (via client-side or server-side validation), provide suggestions for fixing the input in a timely and accessible manner.

Layout

  • Frames must have appropriate titles. If a page uses frames and the frames are appropriately titled, this is a sufficient technique for bypassing individual frames. Example code:
    <iframe title="Survey Form Frame" src="https://spreadsheets.google.com/embeddedform?formkey=" width="760" height="820" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe>
  • Use tables for tabular data only, not for general layout. Where necessary, associate data cells with their headers. Use data table captions and summaries where appropriate.
  • The reading and navigation order (determined by the order in which the elements appear in the source code) must be logical and intuitive. Child elements should appear in the code directly after their parents.

Emphasis

  • Use semantic markup to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), and other markup. Use semantic markup appropriately--for example, do not use <div class="primary-heading">...</div> when <h1>...</h1> already has the concept of primary heading.
  • Do not use color as the sole method of conveying content or distinguishing visual elements.
  • Do not use color alone to distinguish links from surrounding text unless the luminance contrast between the link and the surrounding text is at least 3:1. Provide an additional differentiation (e.g., it becomes underlined) when the link is hovered over or receives focus.  

Navigation

  • Instructions must not rely upon shape, size, or visual location (e.g., "Click the square icon to continue" or "Instructions are in the right-hand column").
  • All page functionality must be available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing).
  • Page-specified shortcut keys and accesskeys (in general, avoid using accesskey) cannot conflict with existing browser and screen reader shortcuts.
  • Keyboard focus must never be locked or trapped at one particular page element. The user must be able to navigate to and from all navigable page elements using only a keyboard. For this reason, avoid using iframes if possible.
  • If a page or application has a time limit, the user is given options to turn off, adjust, or extend that time limit. This is not a requirement for real-time events (e.g., an auction), where the time limit is absolutely required, or if the time limit is longer than 20 hours.
  • Automatically moving, blinking, or scrolling content that lasts longer than 5 seconds can be paused, stopped, or hidden by the user. Moving, blinking, or scrolling can be used to draw attention to or highlight content as long as it lasts less than 5 seconds.
  • Automatically updating content (e.g., automatically redirecting or refreshing a page, a news ticker, AJAX updated field, a notification alert, etc.) must  be pause-able, stoppable, or hidden by the user, or the user must be able to manually control the timing of the updates. For this reason, avoid automatic updates ("defer load") on change of focus.
  • Provide a link to skip navigation and other page elements that are repeated across web pages. If a page has a proper heading structure, this may be considered a sufficient technique instead of a "Skip to main content" link. Note that navigating by headings is not yet supported in all browsers. Example code:
    <div id="skip">
    <a href="#main-content-area">Skip to Main Content Area</a>
    </div>
  • Provide multiple ways to find other web pages on the site - at least two of the following:
    • a list of related pages
    • table of contents
    • site map
    • site search
    • list of all available web pages

General

  • The web page must have a descriptive and informative page title. Example code:
    <title>Work object 234</title>
  • The user must be able to determine the purpose of each link, form image button, or image map hotspot from the link text alone, or from the link text and its context (e.g., surrounding paragraph, list item, table cell, or table headers).
  • The user can readily distinguish links or form image buttons that have the same display text but that go to different locations.
  • Identify the language of the page using the HTML lang attribute. Example code:
    <html lang="en”>
  • Identify the language of page content that is in a different language using the lang attribute. Example code:
    <blockquote lang="es">
  • When a page element receives focus, it must not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user.
  • When a user inputs information or interacts with a control, it must not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user unless the user is informed of the change ahead of time.
  • Provide sufficient labels, cues, and instructions for required interactive elements via instructions, examples, properly positioned form labels, and/or fieldsets/legends.
  • Avoid significant HTML/XHTML validation/parsing errors. Check your code, using a tool like the one at http://validator.w3.org.
  • Use markup in a way that facilitates accessibility. Follow HTML/XHTML specifications and use forms, form labels, frame titles, and similar elements appropriately.
  • Text and images of text should have a contrast ratio of at least 4.5:1.
  • Large text (over 18 point or 14 point bold) should have a contrast ratio of at least 3:1.
  • The page should be readable and functional when the text size is doubled. Plan to do substantial testing to make sure that the UI works throughout the site when the browser is set to 200%.
  • If you can make the visual presentation you want using text alone, do not use an image to present that text.
  • Make sure page headings and labels for form and interactive controls are informative. Avoid duplicating heading (e.g., "More Details") or label text (e.g., "First Name") unless the structure provides adequate differentiation between them.
  • Make it visually apparent which page element has the current keyboard focus. As you tab through the page, you should be able to see where you are.
  • Do not change the order of navigation links that repeat on multiple web pages. The navigation should stay the same as the user navigates through the site.
  • Identify consistently elements that have the same functionality across multiple web pages. For example, a search box at the top of the site should always be labeled the same way.
  • If the user can change or delete legal, financial, or test data, make sure the user can confirm, verify, and reverse the change or deletion.
  • Previous topic Guidelines and design tips for accessible applications
  • Next topic Satisfying accessibility requirements in composite portals (6.1)

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us