6.3 Form Validation, Edit Validate & WCAG Accessibility

Form Validation, Edit Validate & WCAG Accessibility

Data integrity and inclusive accessibility are two indispensable pillars of enterprise application architecture. A robust application must ensure that data entered by end users conforms to strict business rules, data types, and regulatory constraints before it reaches transactional persistence layers. Simultaneously, modern enterprise solutions must be accessible to every user, including individuals who rely on assistive technologies such as screen readers, screen magnifiers, and keyboard-only navigation.

This section explores Pega's multi-tiered validation architecture—contrasting Control-level validation, Validate rules (Rule-Obj-Validate), and Edit Validate rules (Rule-Edit-Validate)—alongside validation execution timing, WCAG 2.1 AA accessibility compliance via the Pega Accessibility Inspector, and multi-language localization.

---

1. Multi-Tiered Validation Architecture in Pega

Rather than relying on a single monolithic validation script, Pega provides a multi-layered validation architecture. Each tier operates at a specific level of abstraction and execution lifecycle:

+-------------------------------------------------------------------------+
|                  PEGA MULTI-TIERED VALIDATION ARCHITECTURE              |
+-------------------------------------------------------------------------+
| TIER 1: CONTROL-LEVEL VALIDATION                                        |
| - Configured on UI Controls (App Studio & Dev Studio)                   |
| - Required fields, min/max text lengths, numeric ranges, date limits    |
| - Immediate client-side browser feedback                                |
+-------------------------------------------------------------------------+
                                    |
                                    v
| TIER 2: EDIT VALIDATE RULES (Rule-Edit-Validate)                        |
| - Configured on Property definitions (Data Layer)                       |
| - Java regex pattern matching for scalar strings (SSN, ZIP, Email)      |
| - Fires automatically whenever the property value is set                |
+-------------------------------------------------------------------------+
                                    |
                                    v
| TIER 3: VALIDATE RULES (Rule-Obj-Validate)                              |
| - Business logic validation across multiple fields                      |
| - Compares dates, checks financial ratios, evaluates When rules         |
| - Executed on Flow Action submission (pyValidate) or Stage transitions  |
+-------------------------------------------------------------------------+

1. Control-Level Validation

Control-level validation is configured directly on individual user interface controls within App Studio or Dev Studio:

• Required Checkbox: Ensures that a field cannot be left blank when submitting a form.
• Data Type Restrictions: Enforces primitive formats based on property types (e.g., an Integer control automatically restricts input to numeric characters; a Date picker prevents alphabetic input).
• Minimum / Maximum Lengths: Restricts text strings to designated character boundaries (e.g., requiring a password to contain at least 8 characters).
• Date Range Restrictions: Restricts date pickers to future dates only (e.g., Appointment Date cannot be in the past) or past dates only (e.g., Birth Date cannot be in the future).
• Execution: Evaluated immediately on the client side in the browser, providing instant visual feedback (such as red outlines or inline error icons) without waiting for a server round-trip.

2. Edit Validate Rules (Rule-Edit-Validate)

An Edit Validate rule provides low-level pattern validation on a Single Value (scalar) property.

• Underlying Mechanism: Edit Validate rules contain Java code (typically regular expression pattern matchers) that evaluates whether a string matches a strict syntactic format.
• Association: Configured on the Advanced tab of a Property rule form (Rule-Obj-Property).
• Standard Out-of-the-Box Examples:
  • IsEmail: Validates that a string conforms to standard email syntax (name@domain.com).
  • SSN: Validates that a US Social Security Number conforms to the 9-digit format (###-##-####).
  • ZipCode: Validates 5-digit or 9-digit US postal codes (##### or #####-####).
  • AlphaNumeric: Ensures a text string contains only letters and numbers with no special symbols.
• Execution Timing: Unlike UI controls, Edit Validate rules are tied to the property itself. Whenever a client pushes a value to the Clipboard or a connector sets the property, the Pega engine automatically runs the associated Edit Validate routine. If validation fails, an error message is attached directly to the property on the Clipboard.

3. Validate Rules (Rule-Obj-Validate)

A Validate rule represents enterprise-level business validation. While Edit Validate rules inspect a single scalar string in isolation, Validate rules execute complex, multi-field, cross-property business logic.

• Capabilities:
  • Cross-Field Comparison: Validates relationships between two or more fields (e.g., LoanEndDate must be later than LoanStartDate; MortgageAmount cannot exceed 80% of PropertyAppraisalValue).
  • Conditional Validation: Uses When rules to apply validation only under specific conditions (e.g., If Applicant is Self-Employed, require two years of Tax Return attachments).
  • Calling Other Validate Rules: A Validate rule can call other Validate rules across child pages and Page Lists, enabling comprehensive hierarchical validation of complex data structures.
  • Functions & Logic: Evaluates mathematical expressions, Clipboard lookups, and business functions.
• Association & Invocation: Validate rules are typically referenced in the Validate field on the Action tab of a Flow Action (Rule-Obj-FlowAction, standard property pyValidate). When the user clicks Submit or Continue, the engine runs the Validate rule before allowing the case to advance to the next step.

---

2. Validation Execution Lifecycle & Timing

Understanding when validation occurs during user interaction is critical for designing performant forms:

+-------------------------------------------------------------------------+
|                      VALIDATION EXECUTION TIMING                        |
+-------------------------------------------------------------------------+
| 1. CLIENT-SIDE INSTANT VALIDATION (Browser Level):                      |
|    - User types in a control or tabs out (onBlur).                      |
|    - Browser evaluates Required state, primitive types, min/max lengths.|
|    - Immediate inline warning icons; zero network traffic.              |
+-------------------------------------------------------------------------+
                                    |
                                    v
| 2. ASSIGNMENT SUBMISSION (Flow Action Submit / HTTP POST):              |
|    - User clicks Submit / Continue button.                              |
|    - Browser transmits input values to Pega server engine.              |
|    - Property sets trigger Edit Validate rules.                         |
+-------------------------------------------------------------------------+
                                    |
                                    v
| 3. SERVER-SIDE FLOW ACTION VALIDATION (pyValidate Execution):           |
|    - Engine executes Rule-Obj-Validate attached to Flow Action.         |
|    - Cross-field rules and conditional When rules evaluated.            |
|    - If violations found: Engine attaches Page-Messages and             |
|      Property-Messages, halts assignment progression, and re-renders    |
|      form with highlighted error banners and field messages.            |
|    - If validation passes: Post-processing Data Transforms execute,    |
|      and case advances to the next lifecycle step.                      |
+-------------------------------------------------------------------------+

Error Presentation: Field-Level vs. Page-Level Messages

When validation fails on the server:

• Field-Level Messages: Error messages linked to specific properties (.ApplicantAge) are rendered directly beneath the corresponding input control, alerting the user to exact corrections needed.
• Page-Level Messages: General errors that span multiple fields or business constraints (e.g., "The combination of loan amount and term exceeds credit policy limits") are displayed in a prominent alert banner at the top of the form.

---

3. Web Accessibility (WCAG 2.1 AA Compliance) in Pega

Enterprise applications must ensure equitable access for all users, including those with visual, auditory, motor, or cognitive disabilities. Pega Platform applications are engineered to comply with WCAG 2.1 Level AA (Web Content Accessibility Guidelines) standards and Section 508 federal mandates.

The Pega Accessibility Inspector

Pega provides an integrated diagnostic tool called the Accessibility Inspector, accessible directly from the runtime developer toolbar in both App Studio and Dev Studio.

• The inspector analyzes the currently active UI screen in real time, scanning all layouts, controls, and dynamic containers.
• It groups identified accessibility defects into standardized categories:
  1. Missing Accessible Names / Aria-Labels: Controls (especially icon buttons, image links, and search bars) that lack descriptive labels for screen readers.
  2. Insufficient Color Contrast Ratios: Text or interactive controls whose contrast ratio against the background color falls below WCAG standards (requiring a minimum of 4.5:1 for normal body text and 3:1 for large text and UI components).
  3. Improper Heading Hierarchy: Skipping heading levels (e.g., jumping from an <h1> directly to an <h3> without an intermediate <h2>), which disorients users navigating via screen reader heading lists.
  4. Form Controls Missing Associated Labels: Input fields that lack explicit <label> bindings, preventing assistive tech from announcing what input is expected.

Key Accessibility Architectural Patterns

• Screen Reader Support & ARIA Attributes: Pega auto-generates semantic HTML and WAI-ARIA roles (such as role="navigation", role="main", aria-expanded, and aria-required). Architects must provide concise, meaningful Helper Text and Tooltips that populate aria-label attributes.
• Keyboard Navigation & Logical Tab Order: Every interactive element must be reachable and actionable using the keyboard alone (via Tab, Shift+Tab, Enter, and Spacebar). Pega layouts maintain a natural top-to-bottom, left-to-right tab order. Architects must avoid focus traps and ensure clear, visible focus rings.
• Color Independence: Information must never be conveyed through color alone. For example, a required field should not only have a red border, but also an asterisk (*) and an explicit aria-required="true" attribute. Similarly, a status indicator should pair color with an icon and clear textual status (e.g., "Rejected").

---

4. Localization & Internationalization: Field Value Rules

Enterprise Pega applications frequently serve global audiences speaking diverse languages across multiple geographic locales.

Field Value Rules (Rule-Obj-FieldValue)

Pega achieves full multi-language localization without duplicating business logic through Field Value rules:

• Field Value rules decouple translatable UI text strings—such as button labels ("Submit", "Approve"), dropdown prompt values, instructions, and error messages—from the underlying user interface definitions.
• When the Pega engine renders a view, it checks the current user's Locale setting (stored on pxRequestor.pxUseLocale, such as fr_FR for French, es_ES for Spanish, or de_DE for German).
• The engine uses standard Rule Resolution to search for a Field Value rule matching the property, field value key, and localized ruleset.
• If a localized Field Value rule is found in the user's language pack ruleset (e.g., HRApp_fr:01-01-01), the translated string is displayed; otherwise, the platform defaults to the base English string.

Localization Wizard

Pega provides an administrative Localization Wizard that exports all translatable UI strings, labels, and field values into an industry-standard translation package (such as an Excel or XML file). Translators update the text strings, and the wizard imports the completed translations directly into dedicated language-specific rulesets.

---

5. Comprehensive Comparison: Validation Mechanisms in Pega