[component name | framework | build | icons | theming | localization | i18n | typescript]:

Bug Description

Instance:

https://qacand.qa.hr.cloud.sap/login#/login - LRNWSMINTGE2E sfadmin hr
https://qacand.hcm.ondemand.com/login?company=TALSCMK&username=cgrant&password=pwd

Windows 10/Chrome /JAWS 2025

Steps:

Login to instance
Go To Employee Files from module switcher and choose Succession in sidebar then
find Nominations card and Click View All button. On detail page, click any row in table.
On Right side Nominations section is opened, goto Show More button and click history button.
With JAWS ON, navigate to on page in VPC mode
Actual Results:

In VPC mode, when the down arrow key is pressed, the card contents are read all at once. JAWS reads values without announcing their corresponding labels; label–value association is not conveyed and content is not announced as a definition list.

Root Cause Identified
Investigation revealed that label/value pairs in PPX forms are already using semantic definition lists (

) as designed, but lack explicit programmatic association for screen readers.

Technical Analysis
DOM Structure Found:
Using browser automation, inspected the actual rendered DOM of Personal Information view with [ui5-form-item] selector:

21 form items found
All using

and

elements (definition lists)
Structure:

+

The Issue:
While semantic HTML (

) is present, there is no explicit aria-labelledby association between the label (

) and value (

). JAWS cannot programmatically determine which value corresponds to which label, especially with slotted shadow DOM content.

Why Semantic HTML Alone Isn't Sufficient
Screen readers like JAWS need explicit programmatic associations when:

Content is in shadow DOM with slots
Multiple label/value pairs are adjacent
Virtual cursor mode is used
Without id and aria-labelledby attributes, JAWS reads the rendered content sequentially without announcing the term/definition relationship.

Recommended Fix
Location: UI5 Web Components repository
File: packages/main/src/FormItemTemplate.tsx
Function: contentAsDefinitionList

Minimal Change (3 lines):

Unable to find source-code formatter for language: tsx. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml
function contentAsDefinitionList(this: FormItem) {
  const labelId = `${this._id}-label`;  // Generate unique ID
  
  return <>
    <dt id={labelId} class="ui5-form-item-label" part="label">  // Add id
      <slot name="labelContent"></slot>
    </dt>
    <dd aria-labelledby={labelId} class="ui5-form-item-content" part="content">  // Add aria-labelledby
      {this.content.map(item =>
        <div class="ui5-form-item-content-child">
          <slot name={(item as SlottedChild)._individualSlot}></slot>
        </div>
      )}
    </dd>
  </>;
}

Impact
Scope: All UI5 Forms using accessibleMode="Display" (default for read-only forms)

Applications Affected:

All PPX detail views (Personal Information, Job Data, etc.)
Nomination History (this ticket)
Any SuccessFactors view using metadata-renderer Forms
Change Type: Enhancement to UI5 Web Components core library

Why This Fix Works
aria-labelledby creates explicit programmatic association that:

Works across shadow DOM boundaries
Works with slotted content
Is recognized by all major screen readers (JAWS, NVDA, VoiceOver)
Follows W3C ARIA best practices
Testing Evidence
Test Environment:

Instance: qacand.hcm.ondemand.com (ECMaxTest)
View: Personal Information (/personalData/personalInfo/)
Method: Playwright browser automation with shadow DOM inspection
Selector: document.querySelectorAll('[ui5-form-item]')
Results:

21 form items found
All have hasDefinitionList: true

innerHTML:

innerHTML: Next Steps Create issue in UI5 Web Components GitHub repository Submit pull request with proposed fix Add automated accessibility tests Deploy fix in next UI5 version Update PPX to use new UI5 version Alternative Considered metadata-renderer could add accessibleMode="Display" explicitly, but this won't solve the issue since forms already use definition lists. The problem is at the UI5 component level, not the application level.

Conclusion: This is a UI5 Web Components accessibility gap that needs a 3-line fix upstream. Once fixed and deployed, the issue will be resolved across all applications using UI5 Forms.

Reference: W3C ARIA labelledby

Affected Component

No response

Expected Behaviour

Expected Results:

Screen reader should announce each value along with its associated label. Key–value pairs should be semantically represented using

markup or appropriate ARIA roles/aria-labelledby attributes to ensure screen reader announce the relationship.

For reference : LRN-159263, ECT-258135, LRN-159263|https://jira.tools.sap/browse/LRN-159263]

NOTE
additional reference on how it should announce ECT-260244 and WSM-33820

Isolated Example

No response

Steps to Reproduce

...

Log Output, Stack Trace or Screenshots

No response

Priority

None

UI5 Web Components Version

2.24.0

Browser

Edge

Operating System

windows

Additional Context

No response

Organization

No response

Declaration

• I’m not disclosing any internal or sensitive information.

Start with packages/main/src/FormItemTemplate.tsx and the contentAsDefinitionList function, then inspect the existing FormItem accessibility coverage. Reproduce the label/value announcement issue with the described UI5 Form setup and screen reader context. Done means the rendered definition-list pairs have an explicit label association and automated accessibility tests cover the behavior.