Element Status in Storyline

Last updated: 5/23/2025

Note: Articulate uses the term "objects" to describe individual components within Storyline slides — text boxes, images, shapes, etc. — whereas the term "elements" is commonly used to describe individual components within web pages — headings, paragraphs, sections, etc. Since eCourse components are encountered in both contexts — Storyline and web pages — either term could arguably be used, but for the sake of consistency and clarity, this Checklist will strive to use the term "elements" to describe eCourse components, whether they're being discussed in a Storyline context or a web context. The term "objects" will primarily be used to describe categories of elements within Storyline.

Certain element statuses can be programmatically determined in digital environments. For example, if you're reading through a typical website with the JAWS screen reader, JAWS will be able to programmatically determine whether links have been previously visited or not and will automatically announce that status as each link is read.

Storyline currently supports the following programmatically determinable element statuses, which means you don't need to employ separate techniques to ensure these statuses are communicated to assistive technology users:

  • Disabled state, when applied to buttons: the disabled state, when applied to buttons, is currently the only built-in Storyline state whose status is programmatically determined
    • When a screen reader reads a button that is currently in its disabled state, the screen reader will announce the button as "button unavailable," conveying both structure and status
    • This applies for any content that is structurally recognized as a button, so it includes not just the button object category within Storyline but also any shape, image or other element that has been given a When user clicks trigger, thus structurally turning it into a button
    • This also applies for the Prev and Next course player buttons, which can be set into their disabled state using triggers
    • Tip: the disabled state is recommended over the hidden state for situations where a button is initially unavailable but becomes available based on a certain event — such as a Next button that cannot be used until a slide timeline completes or learners perform certain in-slide actions — as the button being present but unavailable may help screen reader users understand the situation and predict behavior; whereas, if the button was hidden, screen reader users may be less equipped to understand the situation and find the button once it did become available
  • Radio buttons and check boxes being checked/selected or not checked/not selected: this includes these object types as added through the Insert ribbon's Input menu and as provided through Storyline's Graded Question and Survey Question features

Conveying other statuses

Other element statuses may need to be conveyed to learners even if they are not programmatically determinable within a Storyline eCourse; it's typically recommended that you use alt text assigned to specific element states to convey these statuses:

  • Buttons that are currently selected or unselected: any button that is not a radio button or check box but has selected and unselected states needs to convey whether it is currently in its selected or unselected state
    • This is true not only for buttons that use the built-in Selected state but also for buttons that use a custom state intended to mimic selected behavior
  • Buttons that have been "visited": that is, if a button is intended to track and show when it has been visited/used, it needs to convey whether it's been visited/used yet or not
    • This is true not only for buttons that use the built-in Visited state but also for buttons that use a custom state intended to mimic visited/used behavior
  • Any other button or element status that can be perceived visually needs to be conveyed to assistive technology users as well, in accordance with WCAG 1.3.1 Info and Relationships (A)
    • Also, remember that, in accordance with WCAG 1.4.1 Use of Color (A), if an element has distinct statuses, like selected and visited, you must visually convey those statuses via a means other than, or in addition to, color, such as using an icon or unique text

See also within the Checklist