ThePacielloGroup / ARC-Toolkit

Quickly uncover and resolve accessibility issues on any web page with TPGi’s single-page, on-demand, accessibility testing tool.
https://www.tpgi.com/arc-platform/arc-toolkit/
7 stars 1 forks source link

headings (native + aria-level, or div role+ARIA-only) are not indicated accurately in Highlights #45

Open wittjeff opened 1 year ago

wittjeff commented 1 year ago

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.):

\

This is an H1\

\
This is a div with role='heading' and aria-level='2'\
\

This is a H1 with aria-level='2'\

\

This is an H2 with aria-level='3'\

Expected behavior

I suggest you mark these as below: H1: \

This is an H1\

H[2]: \
This is a div with role='heading' and aria-level='2'\
H[2]: \

This is a H1 with aria-level='2'\

H[3]: \

This is an H2 with aria-level='3'\

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

screen capture of test with DOM view in Dev Tools screen capture of this bug report as written because GitHub is parsing my HTML, which isn't helping

Version information

ferllings commented 1 year ago

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.