Forum Discussion

HimanshuShar350's avatar
HimanshuShar350
Community Member
7 months ago

Accessibility issues

One of our clients is performing accessibility QC on a Storyline SCORM package using an automated accessibility testing tool. While the client has not explicitly mentioned the tool name, based on the type of issues reported, it appears that a tool such as axe DevTools may have been used.

As per my understanding, tools like axe are primarily designed for evaluating custom HTML websites where developers have direct control over HTML structure and ARIA attributes. However, this course has been developed using Articulate Storyline, which automatically generates the HTML and ARIA markup through its player framework.

Given these authoring tool constraints, we are unsure how to address certain reported issues that require direct HTML or ARIA-level changes. Has anyone encountered a similar situation, and could you please share how such accessibility findings are typically handled or communicated when working with Storyline-generated content?

Also, attaching the list of issues that we received.

accessibility
advice

1 Reply

  • A11yCheckSaaS's avatar
    A11yCheckSaaS
    Community Member
    10 hours ago

    Hi HimanshuShar350​ 

    I’d treat an automated accessibility finding as a starting point rather than an instruction to change the course immediately.

    First, reproduce the finding in the published course. Then check what is actually causing it. It could be a Storyline setting, how an object was built, an accessible name or alt text issue, or behavior generated by Storyline itself.

    From there, fix what you can control, test the result with keyboard and screen reader, then rescan the republished course.

    I put together a practical guide for this workflow here:

    How to Handle Accessibility Testing Findings in Storyline

    This keeps the response focused on helping the person solve the problem, with the resource as the natural next step.