[ui5-file-uploader]: the required state is not announced on chromium based browsers

[unazko]

Bug Description

Issue Report: Evaluate use of native required attribute in ui5-file-uploader

Summary

Evaluate the feasibility of adding the native required attribute to the internal <input type="file"> in the ui5-file-uploader component. The goal is to improve accessibility announcements in Chromium-based browsers (Chrome, Edge) where aria-required is no longer consistently announced by screen readers.

---

Background / Preconditions

This analysis originates from the following incident:

#13305

During investigation of that issue, a cross-browser difference was identified in how aria-required is exposed for native file upload controls in Chromium-based browsers.

An isolated reproduction using native HTML is available here:

https://jsfiddle.net/torxcdhs/

This example demonstrates that the required state is announced in Firefox but not in Chrome/Edge when using aria-required="true" on <input type="file">.

---

Technical Analysis

Current validation architecture

• UI5 manages validation using the ElementInternals API (form-associated custom elements)

• The native <input type="file"> is encapsulated in Shadow DOM and is not directly part of the outer form submission flow

• Native browser constraint validation is not relied upon for form submission or validation logic

• All validation state is computed and exposed through UI5 mechanisms rather than native HTML validation

---

Impact of adding required

Area | Current | After adding required -- | -- | -- Required announcement (Chrome/Edge + NVDA/JAWS) | ❌ Not announced | ✅ Announced Required announcement (Firefox) | ✅ Announced | ✅ Unchanged Form submission behavior | ✅ Unchanged | ⚠️ Native validity state introduced, but UI5 flow unchanged Validation logic (UI5) | ✅ Unchanged | ✅ Unchanged Native :required CSS behavior (Shadow DOM) | Not applied | May apply internally

---

Key consideration: validity state exposure

Adding required will expose native constraint validation state.

A file input without a selected file will be in a valueMissing state. Depending on browser and assistive technology behavior, this may result in the control being announced as invalid before user interaction.

Currently, this state exists in the browser but is not surfaced via native HTML validation unless the attribute is present.

---

UI5 Component Context

Existing UI5 components show mixed patterns:

• Input uses native required + aria-required

• TextArea, Select, ComboBox, MultiComboBox use aria-required only

• FileUploader aligns more closely with components where the native input value is abstracted and not directly managed through native form validation

The file input is also special in that its value is controlled entirely by the browser and cannot be programmatically manipulated in a standard way.

---

Design Question

⚠️ Decision required

Should the ui5-file-uploader expose native HTML validation semantics (required attribute) in addition to aria-required, in order to improve accessibility announcements in Chromium-based browsers?

---

Options

Option A — Add required alongside aria-required

• Improves accessibility announcement consistency in Chrome/Edge

• Minimal implementation change

• Introduces native constraint validation semantics (valueMissing, :required)

• May surface "invalid" state earlier depending on browser/AT behavior

Option B — Keep aria-required only

• Preserves current UI5 validation model (UI-managed validation via ElementInternals)

• Avoids introducing native HTML validation semantics

• Maintains consistency with other abstracted form components

• Leaves Chromium accessibility behavior as external dependency

---

Acceptance criteria (if proceeding)

• Decision from design/architecture team on accessibility semantics

• If approved:

  • Add required to internal <input type="file">

  • Validate behavior in Chrome/Edge with NVDA/JAWS

  • Ensure no regression in UI5 validation behavior

  • Update documentation if accessibility semantics change

  • Add/update accessibility test coverage

---

Notes

This change does not directly affect UI5 validation logic or form submission behavior, but it changes how native browser accessibility and constraint validation states are exposed to assistive technologies.

Affected Component

ui5-file-uploader

Expected Behaviour

No response

Isolated Example

No response

Steps to Reproduce

...

Log Output, Stack Trace or Screenshots

No response

Priority

None

UI5 Web Components Version

Latest

Browser

Chrome

Operating System

Windows, Macos

Additional Context

No response

Organization

SAP SuccessFactors

Declaration

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