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
HTML heading elements that are assigned other (non-heading) roles are still appearing in this tool's outline, but probably shouldn't be.
In my case I am retrofitting an existing website that used heading elements incorrectly. To do so I am modifying elements e.g. from
<h3>We put some sort of intro text here, and it shouldn't actually be a heading!</h3>
to:
<h3 role="presentation">We put some sort of intro text here, and it shouldn't actually be a heading!</h3>
My understanding is that this should take those elements out of the outline, sort of the opposite to how role="heading" aria-level="3" of #1 works to put them in. But this bookmarklet continues to display such presentation elements in its outline. I believe that is incorrect behavior.
It also occurs to me that while it is the presentation and none roles that might most commonly be associated with a "non-heading" heading element, I think technically ± any other roles would have a similar effect. Meaning, if I had elements like <h1 role="status">…</h1> or <h3 role="term">…</h3> or any other non-heading role then iiuc the accessibility tree would not include those as headers.
The text was updated successfully, but these errors were encountered:
This project does not appear to be open source licensed so I hesitate to make a public copy of it and submit a PR. But since the source is available in case it helps others, the following patch may be of interest:
diff --git a/src/bookmarklet.js b/src/bookmarklet.js
index ae3becf..1c2ea5d 100644
--- a/src/bookmarklet.js
+++ b/src/bookmarklet.js
@@ -113,7 +113,8 @@ function getOutline() {
for (var i = 0; i < els.length; i++) {
var el = els[i];
var visible = isVisible(els[i]);
- var n = parseInt((el.getAttribute('role') == 'heading' && el.getAttribute('aria-level')) || el.nodeName.substr(1));
+ var n = getHeadingLevel(el);
+ if (n === null) continue;
if (visible) {
var wrongLevel = n > previousLevel && n !== (previousLevel + 1);
previousLevel = n;
@@ -207,6 +208,11 @@ function isVisuallyHidden(el) {
}
}
+function getHeadingLevel(el) {
+ var role = el.getAttribute('role') || 'heading',
+ level = parseInt(el.getAttribute('aria-level') || el.nodeName.substr(1))
+ return (role === 'heading') ? level : null;
+}
function highlightElement(el, disableAutoScroll) {
Building requires an older version of node, e.g. in a VM you might:
# install NVM
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
. ~/.bashrc
# use NVM to install old node.js
nvm install 8
# use old nodejs to build project
npm install && npm start
The updated bookmarklet can then be found in the docs/index.html page.
HTML heading elements that are assigned other (non-
heading
) roles are still appearing in this tool's outline, but probably shouldn't be.In my case I am retrofitting an existing website that used heading elements incorrectly. To do so I am modifying elements e.g. from
to:
My understanding is that this should take those elements out of the outline, sort of the opposite to how
role="heading" aria-level="3"
of #1 works to put them in. But this bookmarklet continues to display such presentation elements in its outline. I believe that is incorrect behavior.It also occurs to me that while it is the
presentation
andnone
roles that might most commonly be associated with a "non-heading" heading element, I think technically ± any other roles would have a similar effect. Meaning, if I had elements like<h1 role="status">…</h1>
or<h3 role="term">…</h3>
or any other non-heading
role then iiuc the accessibility tree would not include those as headers.The text was updated successfully, but these errors were encountered: