hinderlingvolkart/h123

Accessibility HTML5 Outliner

h①②③ – Accessibility HTML5 Outliner

See the headings like a screenreader!

Add to your bookmarks

Show Headings

h①②③ H1️⃣2️⃣3️⃣ h❶❷❸

Why you should

If you are a web developer, you might have heard of sectioning content. Those were introduced with article, nav, section and such to provide a scope for headings and footers. They allowed to semantically structure an HTML document.

<h1>I am a document</h1>
<section>
  <h1>I am a section</h1>
  <p>A great section really!</p>
  <aside>
    <h1>Some advertising in between</h1>
    <a href="https://www.chocoloco.com">
      <img 
        src="advertising-animated.gif" 
        alt="Some fancy sweet chocolate drink"
        >
    </a>
  </aside>
  <p>Still belong to the section</p>
</section>
<section>
  <h1>Another section</h1>
  <p>And more content for the people</p>
</section>

The main reason web developers embraced this change was a very practical one: it solved an annoying issue with the heading hierarchy. You'd always had to number the headings h1, h2 etc. imagine a teaser component. Now let's place this teaser into the body, but also into an accordeon. The heading now has to change depending on its place, because the accordion is some levels deeper. This is a nightmare for modular system. So that's why devs loved those h1 in sections.

But reality turned out to be different. While devs embraced the news, browsers and screenreaders (and most probably SEOs) did not: they sticked to the yet existing model. A document full of h1 (well structured within sectioning elements) is total rubbish for a blind user, denying him or her the most important navigational help. The above example has this structure:

1. I am a document
2. I am a section
3. Some advertising in between
4. Another section

The new HTML 5.2 spec takes a step back and now recommends to always set your h1, h2, h3 etc. according the actual level. For accessibility reasons though, you should rely on implicit sectioning at all: forget about sections and you're all set with screenreaders (and probably search engines too).

<h1>I am a document</h1>
<section>
  <h2>I am a section</h2>
  <p>A great section really!</p>
  <aside>
    <h2>Some advertising in between</h2>
    <a href="https://www.chocoloco.com">
      <img 
        src="advertising-animated.gif" 
        alt="Some fancy sweet chocolate drink"
        >
    </a>
  </aside>
  <h2>I am a section (continue)</h2>
  <p>Still belong to the section</p>
</section>
<section>
  <h2>Another section</hh21>
  <p>And more content for the people</p>
</section>

Thing is that many people don't know. Some outliners show the structure of the whole document, including hidden parts. But guess what, screenreaders only read what's visible. Yeah, funny thing, right. If you think about it, it makes just sense though. So this outliner will only consider headings that are actually visible, at least visible to the screenreader. (because you can visually hide elements that stay theoretically visible).

Our bookmarklet to the rescue!! :-)

h123's Issues

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'

This little bookmarklet served me very well for all these years.

It's the first time that I'm having a problem when triggering it:

In plain text:

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' https://static-beta.woz.ch". Either the 'unsafe-inline' keyword, a hash ('sha256-CjNGNj8URgGVcDemg+XsarcETiWp8ag2xSKWHb9iQrk='), or a nonce ('nonce-...') is required to enable inline execution.

iframe.onload @ VM1393:1
(anonymous) @ VM1393:1
(anonymous) @ VM1393:1
VM1393:1 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src-attr 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-sGIZx7apmviM7XhBJiBkgw41NQBTODshucwc4ePW/VE='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

iframe.onload @ VM1393:1
(anonymous) @ VM1393:1
(anonymous) @ VM1393:1
12Refused to apply inline style because it violates the following Content Security Policy directive: "style-src-attr 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-uOhIMM/vKV/KpUM3Q0VKr+HCNkFKMjYEFAmOWM+/c2U='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

31Refused to apply inline style because it violates the following Content Security Policy directive: "style-src-attr 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-HX7KALlcxM42b6D0nzyBnZp966dWKRyFJOduZQauzAQ='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

VM1393:1 Refused to apply inline style because it violates the following Content Security Policy directive: "style-src-attr 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-sGIZx7apmviM7XhBJiBkgw41NQBTODshucwc4ePW/VE='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

It still seems to work on a functional level, but the visuals are ugly:

Any easy way to solve this?

Make errors visible for color blindness

I really like this tool. Is there any way you could ask the developer to update the bookmarklet to use a red circle instead of a red square to indicate Headings errors? In other words, is it possible to update this bookmarklet to use a change in shape, as well as a change in color to indicate the error?

Does not ignore role=presentation or role=none elements

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.

Bookmarklet not displaying elements marked by role="heading" and aria-level="x"

Hi There,
I found your bookmarklet and it's very usefull. For a POC, I created a document simulating a correct header structure by using role="heading" and aria-level="x".

According to the source code of the bookmarklet, those simulated headings should be correctly detected, but when opening the bookmarklet, they "pseudo" headings do not get displayed.

You can see my example page here: https://www.widmer-web.ch/Heading-Structure.html

I inserted part of the bookmarklet's code into my example page. It is the part where you loop over all headings and elements having a role attribute. At least the console output seems to be correctly..

Any idea what I could be doing wrong?