Accessibility
Equal access, uncompromised: Pega's accessibility-driven approach
Accessibility is imperative for businesses that want to successfully compete in a global economy and reach their broadest audience. Take the first step towards a more equitable future by leveraging Pega’s flexible application to create inclusive experiences for all your users.
Why it matters
Building accessibility into the design of your application from the beginning reduces risk, extends your market reach, and increases the strength of your brand. Testing your application for accessibility at the end of your project usually leads to unsatisfactory experiences that could have been mitigated in the design and development stages.
Training
Latest Missions
Latest Modules
Documentation
Recommended
Recently published
Events
Upcoming events
Event replays
Videos
Blogs
Support Center
Latest Questions
Latest Discussions
Latest Support Docs
FAQs
In a standard end-user portal for a Pega application, automated accessibility testing tools may pick up on several duplicate id attribute values in the DOM, such as “TABSPAN”, “PEGAGADGET”, "RULE_KEY" or "EXPAND-OUTERFRAME.”
This would typically pose an accessibility issue for assistive technologies, however — these attributes are placed on non-actionable, non-interactive DOM elements such as <div> elements that assistive technology users would never directly interact with. Any interactive elements such as text inputs, radio buttons, checkboxes, etc. will all have their own unique ID. As product engineering has stated, the values of these IDs are internally used in Pega code for necessary functionalities in the section-based UI. The scope of addressing these IDs would require a redesign of the current architecture and cause issues with backwards compatibility, so as such the product team is confident that any such elements containing a duplicate ID will not have an impact on individuals using assistive technologies.
In 8.6, Platform introduced a new navigation pattern for Repeating Dynamic Layouts (RDLs) that is enabled by default. For any interactive components contained in RDLs, navigation between elements now requires arrow keys to move between RDL rows ("cells"), then pressing Enter to bring focus inside the row cell. From there, users can arrow keys to navigate interactive elements within or press Esc to bring focus back out to the cell. This navigation is in line with the grid cell navigation in WCAG.
However, this has introduced some issues for keyboard and screen reader users, as the design of the RDL does not always give an indication that it is a grid. It also introduces attributes such as aria-hidden="true" or role="gridcell" on interactive elements (check for these attributes in the DOM to confirm RDL behavior or use live UI). To change this navigation pattern, go to the configuration dialog of the RDL in Dev Studio and scroll to the bottom of the General tab. You will see a configuration option, "Use form navigation (by tab)". Selecting this removes the arrow key method of navigating and allows for navigation using the tab key, along with removing any other attributes it introduced. As of Infinity’23, the default configuration for any RDL introduced in applications will be navigation "by tab".
Pega recommends the use of Smart Tip as an accessible helper text option.
However, in earlier versions of the product, screen reader users would actually hear the value for the smart tip override the label of the field it is configured on. So, for example, an input field with the label "First name" and smart tip value "enter your name". The expectation on the focus of the field: SR announced "First name edit, enter your name" Actual: "Enter your name" In 8.7.5, 8.8+, and 8.9, this issue has been addressed and fixed in future releases.
There are various known accessibility issues found in the existing Reporting module such as unlabeled interactive elements, inaccessible drag & drop, and poor usability with tables. Due to the numerous accessibility issues and other built-in limitations, Pega created a new Explore Data/Data Insights module. Explore Data/Data Insights is available as early as Platform version 8.6 and although built on the Constellation architecture, it can be integrated directly into your current application.
However, there are still some known accessibility gaps that are being targeted to be addressed in the 8.9 release. The Reporting module will not be going away and will continue to be supported, but it will not be seeing many enhancements or improvements soon as Explore Data continues to be built out.
When we have exacting layout and accessibility requirements on the generated PDF, it is recommended to use a hand-coded HTML fragment to act as the template for the PDF. You need to build data binding using JSP tags / Java code. The section UI generated is optimized for browser clients and NOT for PDF generation. The value of the out-of-the-box PDF generation capability is in terms of easy inclusion in the workflow and eliminating the need to stand-up external integrations or buy other licenses.
However, any complex PDF with AA/AAA requirements needs careful tuning of the input HTML. Keep the HTML minimal and semantic — include alt text for images, captions for tables, etc. (basically author the HTML to be accessible as if for the browser, and the output PDF will be accessible). For more information, see the Setting the PDF file versions article on our website.
