Heading ad hoc tools not displaying the updated aria-level of a heading

Describe the bug

Headings which have had their implicit level overwritten by use of an explicit aria-level are still showing up with their implicit level when using a11y insights’ ad hoc tools to highlight headings.

CodePen repro example

Go to the codepen: https://codepen.io/scottohara/full/qBpyeNW turn on the a11y insights for web ad hoc feature to display the headings of the page.

The first two elements of the codepen demo are h1 elements which have been modified with ARIA to be exposed as heading level 3s. The third element is a div with role=heading and aria-level=3. The div is being highlighted with the correct heading level by a11y insights.

Expected behavior

heading elements which have had their levels overwritten by aria-level should be labeled to match the level that is exposed in the browser’s accessibility tree.

Context (please complete the following information)

• OS Name & Version: Win 10
• AI-Web Version & Environment: version 2.31.1 browser extension
• Browser Version: Edge 99
• Target Page: https://codepen.io/scottohara/full/qBpyeNW

Did you search for similar existing issues?

Possibly similar to https://github.com/microsoft/accessibility-insights-web/issues/5126, but since the <div role=heading aria-level=3> did get flagged by a11yInsights as an h3, thought a new issue would be best.

[ferBonnin]

Reviewed with Peter, the aria-level should be the one we consider if we have both a native heading level and an explicit aria-level

Also interesting is that the H3 in the div has a lowercase ‘h’. Ran the same visualization in accessibilityinsights.io/docs, all the Hx have an uppercase ‘H’

[scottaohara]

thank you @ThanyaLeif

i don’t have the canary build of a11y insights, but reviewing the PR you linked to, the changes look like they address the issue i raised. so thank you.