fix: rename id prop to id-{tagname} format for all affected components to fix screenreader issue

[Copilot]

Proposed changes

Screenreaders fail to read accessibility text (labels, messages) from components when the id attribute is set. This occurs because the id prop conflicts with the internal element's ID used for ARIA relationships.

Solution: Rename id prop to id-{tagname} format matching the internal HTML element. Properties are defined in camelCase in TypeScript (e.g., idInput, idSelect) which automatically render as kebab-case HTML attributes (e.g., id-input, id-select) across all frameworks.

Form Components:

• db-input, db-switch, db-checkbox, db-radio: id → idInput (renders as id-input)
• db-select: id → idSelect (renders as id-select)
• db-textarea: id → idTextarea (renders as id-textarea)

Additional Components:

• db-custom-select, db-tabs, db-tab-list: id → idDiv (renders as id-div)
• db-custom-select-list-item, db-accordion-item: id → idLi (renders as id-li)
• db-navigation: id → idNav (renders as id-nav)
• db-tooltip: id → idI (renders as id-i)
• db-accordion: id → idUl (renders as id-ul)

Before:

<db-input id="username" label="Username"></db-input>
<!-- Screenreader cannot read "Username" label -->
<db-switch id="my-switch">My Switch</db-switch>
<!-- Screenreader cannot read "My Switch" -->

After:

<!-- Angular/Vue (kebab-case in templates) -->
<db-input id-input="username" label="Username"></db-input>
<!-- Screenreader reads "Username" label correctly -->
<db-switch id-input="my-switch">My Switch</db-switch>
<!-- Screenreader reads "My Switch" correctly -->

<!-- React (camelCase in JSX) -->
<DBInput idInput="username" label="Username" />
<DBSwitch idInput="my-switch">My Switch</DBSwitch>

Implementation:

• Model files: Add new property to DefaultProps (e.g., idInput, idSelect), use Omit<GlobalProps, 'id'> to exclude conflicting property
• Component files: Update props.id → props.idInput (or corresponding property) in onMount hooks
• Showcase files: Update id prop references to use new property names (e.g., DBSelect with idSelect, DBTooltip with idI)
• Auto-generated IDs preserved when property not provided

resolves #3435

Types of changes

• Bugfix (non-breaking change that fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (improvements to existing components or architectural decisions)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Further comments

This is a breaking change for applications using the id binding on these components.

Migration path:

• Angular/Vue: Rename id to id-{tagname} in templates (e.g., id="username" → id-input="username")
• React: Rename id to camelCase property in JSX (e.g., id="username" → idInput="username")

The change affects all framework outputs (Angular, React, Vue, Web Components) as they're generated from the same .lite.tsx source files via Mitosis.

Showcase updates: Updated React showcase to use new property names for DBSelect and DBTooltip components.

Total components updated: 14 (6 form components + 8 additional components)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Setting id attribute on db-ux custom elements breaks screenreaders</issue_title>
<issue_description>### Which generators are affected?

• All
• HTML
• React
• Angular
• Vue
• Web components
• Power Apps

Reproduction case

Screenreaders, like the one built into Windows 11, are not able to read certain text from db-ux custom elements if the id attribute is present on the element.

For example in this case, the screenreader is unable to read the "Label of username" text from the label attribute if the id attribute is present:
<db-input id="username" label="Label of username"></db-input>

And in this example the screenreader is also not able to read the text "My Switch" out loud:
<db-switch id="my-switch">My Switch</db-switch>

If the id attribute is removed, the screenreader works as expected.
Interestingly, attributes like placeholder are not affected by the id attribute and always work as expected.

Expected Behaviour

Screenreaders should be able to read all accessibility related text from a db-ux element regardless whether the id attribute is set or not.

Screenshots

No response

Browser version

Chrome

Add any other context about the problem here.

No response

Which DB business unit do you work for?

DB Systel GmbH (please name your customer below)

”DB Systel” please enter your customer / ”other” please enter your area or business unit.

DB InfraGO AG

What project are you working on?

EBuLa Rückfallebene (IRE)</issue_description>

<agent_instructions>Please rename all id (props.id) properties in all components to the HTML tag-name that they are put through within the component followed by id, like e.g. inputid for the db-switch component.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Setting id attribute on db-ux custom elements breaks screenreaders #5462

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[changeset-bot]

🦋 Changeset detected

Latest commit: bf0e9dd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@db-ux/core-components	Major
@db-ux/ngx-core-components	Major
@db-ux/react-core-components	Major
@db-ux/wc-core-components	Major
@db-ux/v-core-components	Major
@db-ux/core-foundations	Major
@db-ux/core-stylelint	Major
@db-ux/core-migration	Major
@db-ux/agent-cli	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mfranzke]

@copilot please adapt these changes to the components custom-select, custom-select-list-item, navigation, tooltip, accordion, accordion-item, tabs and tab-list components as well.

[Copilot]

@copilot please adapt these changes to the components custom-select, custom-select-list-item, navigation, tooltip, accordion, accordion-item, tabs and tab-list components as well.

Done! Extended the id renaming to all requested components in commit 5735128:

• db-custom-select: id → divid
• db-custom-select-list-item: id → liid
• db-navigation: id → navid
• db-tooltip: id → iid
• db-accordion: id → ulid
• db-accordion-item: id → liid
• db-tabs: id → divid
• db-tab-list: id → divid

All builds, tests, and checks passed successfully. The framework outputs (Angular, React, Vue, Web Components) have been regenerated with the new property names.

[mfranzke]

@copilot please switch from {tagname}id to id-{tagname} syntax. id would be the common "namespace" through all components and a separator (-) would be beneficial as well.

[Copilot]

@copilot please switch from {tagname}id to id-{tagname} syntax. id would be the common "namespace" through all components and a separator (-) would be beneficial as well.

Done! Changed the naming convention from {tagname}id to id-{tagname} format in commit deb3eaf.

The properties are now defined in camelCase (e.g., idInput, idSelect, idDiv) which automatically render as kebab-case HTML attributes (e.g., id-input, id-select, id-div) in all frameworks.

Updated properties:

• Form components: idInput, idSelect, idTextarea
• Other components: idDiv, idLi, idNav, idI, idUl

Example usage:

<!-- Angular -->
<db-input id-input="username" label="Username"></db-input>

<!-- React -->
<DBInput idInput="username" label="Username" />

<!-- Vue -->
<db-input id-input="username" label="Username"></db-input>

All builds, tests, and checks passed successfully.

[mfranzke]

@copilot you would need to change the id reference for these components in the showcases as well.

[Copilot]

@copilot you would need to change the id reference for these components in the showcases as well.

Done! Updated the showcase references in commit 46e2f51:

• DBSelect: Changed id="select-test" → idSelect="select-test"
• DBTooltip (2 occurrences): Changed id="tooltip-01" → idI="tooltip-01"

All in showcases/react-showcase/src/components/form/index.tsx.

[michaelmkraus]

The description says

This is a breaking change for applications using the id binding on these components.

but it is marked as

Bugfix (non-breaking change that fixes an issue)

I think it should be marked as breaking because the id is no more part of the props (as it was before):

Omit<GlobalProps, 'id'>

The PR uses internal markup details via props like idI, idUl, ...
This is not a good approach, because internal HTML structures may change while the component concept stays the same, making the public API inconsistent.
A more stable approach would be to keep id and derive internal IDs from it (e.g. ${id}_input, ${id}_label). This would avoid breaking changes.

If this is intentionally a breaking change, it would be good to briefly explain why this approach was not chosen.

[mfranzke]

The description says

This is a breaking change for applications using the id binding on these components.

but it is marked as

Bugfix (non-breaking change that fixes an issue)

I think it should be marked as breaking because the id is no more part of the props (as it was before):

Omit<GlobalProps, 'id'>

The PR uses internal markup details via props like idI, idUl, ... This is not a good approach, because internal HTML structures may change while the component concept stays the same, making the public API inconsistent. A more stable approach would be to keep id and derive internal IDs from it (e.g. ${id}_input, ${id}_label). This would avoid breaking changes.

If this is intentionally a breaking change, it would be good to briefly explain why this approach was not chosen.

I like your suggestion, as it's simpler, but it would still be a breaking change (regarding expectations).

In general providing and transferring attributes on the outer component tag to specific elements on the inside was a simple promise on simple components, that mainly included one or a few tags that formed a specific "element". Regarding the id-HTML-attribute this would have meant to provide the user full control over the resulting id-HTML-attribute on the included form elements like e.g. input. On the other hand the main use case might be a predictable id-HTML-attributes-value, but not necessarily fully controlling the exact value. In other words, an approach like you suggested with a namespaced (by pre- or postfix) should be perfectly fine. As our users might rely on this feature and expect a specific value, it would still be a breaking change regarding the rendered values.
The additional problem with this approach would be that it wouldn't scale to more complex components – at the moment we do have a 1:1 relation in between the outer tag to it's inner elements HTMLs tags. But if components get more complex, we would need to provide some mechanism to target different elements, so that's why I've aligned with another colleague to provide a namespace by the exact included element from the very beginning.

We could postpone a discussion in the whole team will beginning of next year.