Omit redundant role="heading" when rendering native h1-h6 elements

[KAMRONBEK]

Problem

<Text accessibilityRole="header"> (or role="heading") renders <h1 role="heading">. The explicit role is redundant on a native heading element per the W3C ARIA-in-HTML spec, and it fails axe-core audits ("Page must contain a level-one heading" reports h1[role="heading"] as insufficient).

Root cause

createElement already maps the heading role to a semantic h1–h6 element via AccessibilityUtil.propsToAccessibilityComponent (using aria-level/accessibilityLevel, defaulting to h1), but createDOMProps then unconditionally emits domProps.role from propsToAriaRole, duplicating the semantics on the DOM node.

Fix

In modules/createDOMProps/index.js, skip emitting the role attribute only when it would be redundant: role === 'heading' and the resolved elementType is already h1–h6. All other roles, and role="heading" on non-heading elements (e.g. a <div role="heading" aria-level="2">), are emitted exactly as before. (Other roles that map to native elements, e.g. button, have the same pattern — this PR is scoped to heading, the case axe flags and #2780 reports; happy to extend if preferred.)

Tests

Added cases to modules/createDOMProps/__tests__/index-test.js:

• role: 'heading' on each of h1–h6 emits no role attribute
• legacy accessibilityRole: 'header' on h1 emits no role attribute
• role: 'heading' + aria-level on a div still emits role="heading" (and keeps aria-level)
• accessibilityRole: 'header' on a div still emits role="heading"

The two heading-element tests fail without the fix. Full jest dom + node suites, prettier --check, eslint, and flow all pass (no existing snapshots reference the heading role).

Fixes #2780

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 975af4d:

Sandbox	Source
react-native-web-examples	Configuration

[KAMRONBEK]

@necolas TL;DR: role="heading" (or legacy accessibilityRole="header") already renders a semantic h1–h6 via propsToAccessibilityComponent, but createDOMProps then also emits role="heading" on it — redundant per ARIA-in-HTML and flagged by axe-core. This skips the role attribute only when the resolved element is already h1–h6; role="heading" on non-heading elements (e.g. div + aria-level) is emitted exactly as before. Scoped to heading per #2780 — happy to extend to the other element-mapped roles (button, ul/li, …) if you'd prefer that in one pass.