Designing with accessibility in mind is critical for your application's success, and the legal responsibility of app-makers. We at Pega use the internationally-accepted WCAG 2 AA standards to evaluate an application (a standard now being used by Section 508, EN 301 549 and BITV).
By user-testing the various ways a person interacts with our interfaces, we craft compliant, inclusive, usable workﬂows to meet any impairment or disability head-on.
Last updated: Aug 2018
Making an application compliant to WCAG 2 AA standards can be difficult and confusing at first. To help, here’s a simple checklist for your applications:
- HTML is semantic and well-structured. JS is error free.
- Every interactive item can be accessed using only a keyboard in the expected order and without being trapped.
- All forms, field items, links, page titles, and headers are properly and clearly labeled. (e.g. Not “click here”, but “the article on WCAG”; or not “Name” but “Your full name”)
- All image tags must have an alt attribute set (also known as a tooltip in Pega). Images that are decorative (like an icon in front of a label in a button) can leave the alt value blank. All other images need a clear description. (e.g. Not “A picture of a girl”, but “A little girl on the beach smiling.”)
- Any 'All caps' text that is not an abbreviation should be typed in its proper casing, then use CSS to adjust it.
- All text has a contrast ratio of 4.5:1 (A sample contrast checking tool)
- Don’t rely on color or visual position alone to convey meaning and information.
- Users must be informed of any important notifications or document changes.
- The application is understandable and usable with CSS disabled.
- The language on the page and elements that differ from the page are set properly.
- Keyboard users should have a quick way to access the various areas of the application.
- Frames are named.
- Plugins are linked on the page requiring them.
- Anything with a timeout (except for live events) must allow a user to extend the time limit.
- Don’t flash anything over 3 times in 1 second.
- Don’t auto-play media unless the user set that option.
- Time-based media (audio/video) must have an alternate way to understand the content. (i.e. a transcript or captions).
- Finally, compliance != usable. Test your newly-compliant application with actual users.
Last updated: Mar 2017
Familiar interaction patterns are supported out-of-the-box to support common user expectations.
Keyboard — All apps must be navigable using a keyboard only. Do not use access keys or shortcuts as they typically conflict with the OS, native browser, and accessibility software.
Mouse — Single clicks are used to select / activate items. Hovering can reveal more information. Pressing can activate, pan, or drag some items. Releasing can stop panning or drop items being dragged. Do not use 2x, 3x and right-clicks for interaction as they can cause accessibility issues.
Voice — We support voice commands through third parties such as Amazon Alexa, but do not rely on voice commands for any specific interaction today.
Device sensor data — We support device sensor data, but only use device rotation and location data in UI Kit currently.
Touch and gestures — In UI Kit, a touch is handled like a mouse click. As for gestures, we support swiping on toggles and tab pages in UI Kit.
Last updated: Jun 2018
Never flash an object more than twice a second as it can cause seizures.
Avoid auto-playing animations (especially ones with sound) without user initiation as it can cause issues ranging from annoyance to sensory overload. WCAG 2 defines standards for the audio and video tag specifically, but the spirit of the rule applies here too.
Users with vestibular disorders can get vertigo when objects slide into or out of the screen. While there are currently no WCAG 2 standards around these issues, some browsers and OSes are beginning to support a 'Reduce motion' setting. Typical implementations convert movement animations into fades.
Last updated: Jun 2018