Electronic Accessibility

Last updated: 5/26/2025

Programming headings in Storyline

Storyline currently supports heading levels 1–4.

You can program in-slide text as a heading by selecting it, opening the Text Styles menu in the Home ribbon's Font section and:

• Assigning the Heading 1, Heading 2, Heading 3 or Heading 4 style, or...
• Assigning a custom style that is set to be published as a Heading 1–4

Heading hierarchies

If you're unfamiliar with how heading hierarchies operate, jump down to the Heading hierarchies explained section.

Heading hierarchies in Rise

Explore the Heading hierarchy section within the Rise accessibility best practices page.

Heading hierarchies in Storyline

If you have the course title displayed in the course player (which can be controlled through the Title field in the Player Properties panel), it will automatically be:

1. Programmed as a Heading 1
2. Positioned in the reading/focus order well after the slide region and all its contents

Unfortunately, these characteristics cannot yet be controlled by developers, and they combine to disrupt a proper heading hierarchy, because...

This may even be considered a WCAG 1.3.1 Info and Relationships failure, since the relationship that can be perceived visually — that the slide exists within the course — is not the relationship conveyed programmatically.

Storyline recommendations

• Because of the above, it's recommended you not include the course title in the course player
• Program slide titles as Heading 1s
• Additionally, any layer that uses the "Prevent the user from clicking on the other layers" layer property should have its heading programmed as a Heading 1, since:
  • The slide title Heading 1 will not be present while a layer with the "Prevent the user from clicking on the other layers" layer property is open
  • The layer should have its own heading: headings benefit users in a number of ways and represent a good first element for focus to land on when a layer opens
  • If there are going to be headings in an environment, the first heading should be a Heading 1

Heading hierarchies explained

Heading hierarchies communicate the relationships between heading-defined sections within a digital environment. Heading 1 is the highest heading level within a heading hierarchy and is typically reserved for document, web page or environment titles (more on this further below). Heading 2s are often used to introduce macro-topics within an environment; Heading 3s introduce sub-topics within those macro-topics; Heading 4s introduce sub-topics within sub-topics; and so on. It's the same hierarchical structure and relationships you're likely familiar with from other contexts, like tables of contents and bullet lists with various degrees of indentation.

In a heading hierarchy, a higher-level heading being above a lower-level heading communicates the relationship that the lower-level heading's section resides within the higher-level heading's section, so long as there is not another heading of the same higher-level between them. This is referred to as a "parent-child" relationship, where the higher-level heading is the "parent" and the lower-level heading is the "child."

For example, in the example hierarchies above, Heading 3 A.1's section resides within Heading 2 A's section, because Heading 3 A.1 is beneath Heading 2 A in the hierarchy and is a lower level — so, Heading 3 A.1 is a child to Heading 2 A, which is its parent.

Heading 3 A.2's section also resides within/is the child of Heading 2 A's parent section because it is beneath Heading 2 A without there being another Heading 2 between them; whereas, Heading 3 B.1's section is not within Heading 2 A's section, because there is another Heading 2, Heading 2 B, between them; Heading 3 B.1 instead resides within/is the child of Heading 2 B's parent section.

Two headings (or heading-defined sections) of the same heading level that have the same parent are referred to as "peers." In the example above, Heading 3 A.1 and Heading 3 A.2 are peers.

A lower-level heading being above a higher-level heading communicates no relationship between the two headings or their sections.

Why one H1?

A best practice you'll commonly encounter in accessibility circles is, "there should only be one Heading 1 per environment" — as in, per web page, document, app, etc. As it turns out, this isn't just some arbitrary rule; it's actually quite logical in a way that may help you understand heading hierarchies.

The rule stems from the logical application of another best practice, "program the environment title as a Heading 1," which benefits users in a number of ways: it provides a general sense of the environment's purpose or function; it provides a landmark at the start of the environment screen reader users can quickly jump to; and it helps users confirm whether the link or file they just opened is the link or file they intended to open.

The title represents the environment as whole, so by programming it as a Heading 1, you've established that the Heading 1 level represents the environment as a whole. Therefore, there can be no other Heading 1s within the environment because nothing within the environment could possibly be a peer of the environment itself; that would be a logical fallacy. Anything inside the environment inherently has to be a child, or other descendant, of the environment, requiring a heading level lower than Heading 1.