[DREAM-833] Declare WP heading as heading level 2

[lwassermann]

Ticket

https://community.openproject.org/wp/DREAM-833

What are you trying to accomplish?

So that it appears in screenreader heading menus.

We can not make the element an h2, because h2 only allow for phrase content, and neither div nor form are that. Both of which are used for the inline editing form.
Thank you Alex for pointing this out.

Screenshots

Unchanged

What approach did you choose and why?

Add the explicit role and aria level to the HTML element

AI involvement

None/Assisted – No AI assistance used OR only autocomplete/pasted snippets. I effectively wrote and understand all the code.

Merge checklist

• Added/updated tests
• Added/updated documentation in Lookbook (patterns, previews, etc)
• Tested major browsers (Chrome, Firefox, Edge, ...). AI warns that just adding the aria declaration would not work with some assistive tooling. But VoiceOver together with all these browsers had no problem picking this up.

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved issues were identified.

Review effort: Lite
Findings: None

What changed in this PR

Adds accessible level-2 heading semantics to the work package subject while preserving its existing editing behavior.

Changes:

• Adds role="heading" and aria-level="2" to the subject container.

File	Summary
frontend/​src/​app/​features/​work-packages/​components/​wp-subject/​wp-subject.html	Declares the subject container as an ARIA level-2 heading.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Warning

Flaky specs

• rspec ./modules/wikis/spec/features/admin/internal_provider_spec.rb[1:1]
• rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]
• rspec ./spec/features/work_packages/new/attributes_from_filter_spec.rb[1:3:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25518, linked for reference only):

- `rspec ./modules/wikis/spec/features/admin/internal_provider_spec.rb[1:1]`
- `rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]`
- `rspec ./spec/features/work_packages/new/attributes_from_filter_spec.rb[1:3:1]`

Treat this as a standalone task, unrelated to PR #25518. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25518 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @lwassermann to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @lwassermann, and request a review from @lwassermann.
On every commit, set @lwassermann as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[myabc]

I've only checked this "statically" so far (not in the accessibility tree) – but the solution looks good!

The only caveat (which I need to read up on): with some other ARIA roles (e.g. listbox, grid, best practices can allow/disallow certain elements in the element's subtree. I'm not sure whether this is the case for role="heading" - e.g. disallowing nested attributes. – @bsatarnejad may know more?

I'm requesting changes because I'd like to see some sort of test coverage added.

There are a couple different options here:

• add a frontend (vitest) spec for wp-subject.component: since there is no existing spec, this might be a good exercise in adding specs for legacy Angular components. This component is very simple, so the amount of setup to bootstrap (via TestBed) should be minimal. Fortunately agents are also pretty adept at writing frontend specs.
• update some or all feature specs that currently find this header text via CSS (i.e. have_css(".work-packages--details--subject", text:) to find by semantic role instead (e.g.have_heading(text, level: 2)). I'm personally a big proponent of driving specs by semantic and accessibility metadata (CSS is an implementation detail that shouldn't leak into the spec suites IMHO).

Useful resources:

• Testing Library Queries
• jest-dom
• Capybara Accessible Selectors

I'd personally go for both – if time permits - since testing at these different levels serves different purposes.

[lwassermann]

I've adjusted the existing backend tests and added a new test suite for wp-subject. Please have a look @myabc

[github-actions]

Warning

Flaky specs

• rspec ./modules/gantt/spec/features/timeline/timeline_dates_spec.rb[1:2:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25518, linked for reference only):

- `rspec ./modules/gantt/spec/features/timeline/timeline_dates_spec.rb[1:2:1]`

Treat this as a standalone task, unrelated to PR #25518. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25518 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @lwassermann to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @lwassermann, and request a review from @lwassermann.
On every commit, set @lwassermann as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/roles/report_spec.rb[1:2]
• rspec ./spec/features/roles/report_spec.rb[1:3]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25518, linked for reference only):

- `rspec ./spec/features/roles/report_spec.rb[1:2]`
- `rspec ./spec/features/roles/report_spec.rb[1:3]`

Treat this as a standalone task, unrelated to PR #25518. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25518 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @lwassermann to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @lwassermann, and request a review from @lwassermann.
On every commit, set @lwassermann as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[myabc]

@lwassermann thanks for adding the specs! – this is looking better, but there are still a number of issues that need to be worked through.

[myabc]

(thinking aloud) should we wait for the form to appear? just to check it doesn't clobber the heading somehow? or would that be like testing for the absence of something – too defensive?

[myabc]

thanks both for delving into this! @bsatarnejad @lwassermann 💙

good to merge once CI is green.