You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I appreciate the Highlights/Headings feature, but it doesn't always give accurate or complete info relative to the Accessibility Tree.
Specifically:
<hX> is accurately highlighted as HX.
<div role="heading" aria-level="X"> is highlighted as DIV[heading], which does not help me visually validate the semantic structure of the headings.
<hX aria-level="Y"> is highlighted as HX (so the aria-level is ignored, despite the fact that JAWS, NVDA, and VoiceOver (for Mac) interpret this as HY.
<hX role="heading" aria-level="Y"> is highlighted as HX, when it should be HY.
As a side note, the engine rules checker throws a warning if aria-level is used on a , whether the role="heading" is included or not. I'm of the opinion that using aria-level on a heading () is not something we should be throwing warnings about, and in particular we should not be requiring use of role="heading" when aria-level is used on an .
To Reproduce
I think this is clear from above.
Test Case (CodePen/JSBin/etc.):
<h1>This is an H1</h1>
<div role="heading" aria-level="2">This is a div with role='heading' and aria-level='2'</div>
<h1 aria-level="2">This is a H1 with aria-level='2'</h1>
<h2 role="heading" aria-level="3">This is an H2 with aria-level='3'</h2>
Expected behavior
I suggest you mark these as below:
H1: <h1>This is an H1</h1>
H[2]: <div role="heading" aria-level="2">This is a div with role='heading' and aria-level='2'</div>
H[2]: <h1 aria-level="2">This is a H1 with aria-level='2'</h1>
H[3]: <h2 role="heading" aria-level="3">This is an H2 with aria-level='3'</h2>
So the brackets say "this was cast to level X" without taking up a lot of screen space. Still easily quick-scannable on the page.
Screenshots
Version information
Browser and version: Chrome 117
ARC Toolkit version: 5.5.3
The text was updated successfully, but these errors were encountered:
This is not a bug, Toolkit simply highlights the element native type and role for divs.
But there is definitively room for improving the label with more useful value.
Describe the bug
I appreciate the Highlights/Headings feature, but it doesn't always give accurate or complete info relative to the Accessibility Tree.
Specifically:
As a side note, the engine rules checker throws a warning if aria-level is used on a , whether the role="heading" is included or not. I'm of the opinion that using aria-level on a heading () is not something we should be throwing warnings about, and in particular we should not be requiring use of role="heading" when aria-level is used on an .
To Reproduce
I think this is clear from above.
Test Case (CodePen/JSBin/etc.):
<h1>This is an H1</h1>
<div role="heading" aria-level="2">This is a div with role='heading' and aria-level='2'</div>
<h1 aria-level="2">This is a H1 with aria-level='2'</h1>
<h2 role="heading" aria-level="3">This is an H2 with aria-level='3'</h2>
Expected behavior
I suggest you mark these as below:
H1: <h1>This is an H1</h1>
H[2]: <div role="heading" aria-level="2">This is a div with role='heading' and aria-level='2'</div>
H[2]: <h1 aria-level="2">This is a H1 with aria-level='2'</h1>
H[3]: <h2 role="heading" aria-level="3">This is an H2 with aria-level='3'</h2>
So the brackets say "this was cast to level X" without taking up a lot of screen space. Still easily quick-scannable on the page.
Screenshots
Version information
The text was updated successfully, but these errors were encountered: