Application building and testing for accessibility

Model‑driven, low‑code Pega Platform™ offers configuration tools to provide an optimal experience. Take full advantage of this offer by using the most recent Pega Platform version and applying the latest patches that are available for your platform before starting development.

By using the Pega Platform patch release process, you apply the most recent important security, supportability, and reliability improvements and bug fixes since the last minor release. Pega Platform patches apply only changes between the patch and your current version, which ensures backward compatibility and eliminates any regressions or feature updates that could negatively affect your application functionality. Pega applications always improve and introduce new features, including those that enhance the accessibility experience. The next patch release might potentially address any issues that you identify during your build process.

For more information about the patch process, see Stay current with Pega and Pega Infinity patch calendar.

Pega Platform is flexible. You can create your application in many ways to meet your unique needs. Ideally, at this point, you have completed your research, established your personas, and discussed with your team the outcomes of the case flows that you want to achieve. Now your goal is to build your application. To build your software with accessibility in mind, consider the following questions:

1. Which components to use?
2. How to optimize the components for your users?
3. How to create a UX design that provides ease of understanding and navigation for all users?

The intersection of these aspects drives the accessibility of your experience. 

Example: Creating a form

When you create a form, you select options for data entry. After you select which elements to use, such as an input box, a drop-down list, or a checkbox, you need to configure them properly to make them accessible to your users. Consider the following questions:

• Does the information have a proper label?
• Do the input fields need validation?
• Does the information need helper text or a tooltip to reduce confusion or incorrect entry?
• Does the overall form have sufficient instructional text?
• Do the sections in the form have proper heading levels for assistive technology to navigate?

For additional guidance on best practices, see Best practices for configuring UI components.

To create an accessible user experience, test early and often based on your defined user personas and the acceptance criteria for your user story. Ideally, the development and UX teams, business architects, and any defined users review and sign off every user story. The following list shows examples of some simple accessibility checks that you can run in your applications.

Quick accessibility checklist 

1. Can you use the keyboard to navigate all interactive features on a page without coming to a dead end? For example, can you navigate to and from any feature without using the mouse?

2. Can you visibly see a difference in an item to which you navigate with the Tab key so that you know where you are? For example, when you press the Tab key to get to a link or button, do you see an outline or box around it?  

3. Can you navigate to an item on the page with the Tab key but that element has no function? For example, when you press Enter, Spacebar, or an arrow key, nothing happens.  

4. Are the title and alternative text (or image description) present for all images or icons on the page? For example, if you use your developer tool and inspect the page, does an icon have an associated alt-txt= element? 

5. Are all actionable items still available if you turn off all styles (by using the web developer toolbar for Google Chrome or Mozilla Firefox)?

After you pass these basic checks, you can use a variety of testing tools to test your application more comprehensively. These tools fall into two categories:

• Automated testing solutions
• Assistive technology tests

By using both types, you can create an application that is optimized for both compliance and accessibility.

Automated accessibility testing 

Several free tools are available for testing basic accessibility compliance. They are useful for efficient scanning of individual pages. These scanning tools identify only twenty-five to thirty percent of accessibility issues, but the tools are a good place to start. Remember that an automated tool does not replace the experience of actual application use. The goal is not to code to the test, but rather to meet the needs of your users. 

Consider the following tools: 

• Pega Accessibility Inspector: An accessibility testing tool integrated with Dev Studio

• WAVE: Google Chrome and Mozilla Firefox extensions created by the Web Accessibility In Mind organization at Utah State University 

• ANDI: A tool created by the US Social Security Administration, for use with any browser

• aXe DevTools: Chrome and Firefox extensions created by Deque Systems Inc.

Testing with assistive technologies 

The only true method to test an application is manually testing with assistive technologies in use. Assistive technology enables and promotes inclusion and participation, especially for people who have a disability, aging populations, and people with non-communicable diseases. According to the World Health Organization, the primary purpose of assistive products is to maintain or improve functioning and independence for individuals to promote their well-being.

Perform this type of testing through the following means:

• By the development team in peer reviews as part of the Definition of Done
• By native users
• By a third, independent party 

Testing with native users of a technology is highly effective. These users are best to determine if they can complete a task as designed. See the following list of examples of assistive technologies:

• Screen readers: Provide users with limited visibility with means to interact with written content and interactive elements, for example, JAWS, NVDA, Narrator, and VoiceOver.
• Screen magnifiers: Show options to enlarge content and elements on the screen for enhanced visibility, for example, ZoomText, Windows Magnifier, MAGgic.
• Text to speech: Changes text into audio for enhanced comprehension, for example, ReadAloud, ReadMe, and ReadSpeaker.
• Voice command software: Includes tools for users with mobility challenges to interact with the software by using their voice, for example, Dragon Naturally Speaking.

After you thoroughly test your page or workflow, you can identify any accessibility-related issues. Prioritize the issues based on their severity and how well users can successfully perform their tasks.   

For each item in your list, review the workflow, components, and configuration options to verify whether you can make any modifications to help mitigate an issue. If you cannot identify a path forward, leverage the Pega Community or reach out to our support team.  For more information, look to the Pega Support Center.

Check your knowledge with the following interaction: