Can't get screen reader to indicate when a listed item is bulleted

Hi Kellie,

First, I'd want to confirm that you're working on local project files as described here and testing the published output within the intended environment. Next, I believe JAWS only supports the latest release (Version 16 I believe) and to be used in the latest version of Internet Explorer (IE11). 

If you're testing under those conditions, and still having difficulty could you share your sample file in the forums or send the file here so that we could see how you've set up the bulleted text and any other settings? 

Hi Ashley,

I am working with local files, using the latest storyline version, and testing in IE11. I will try to put together a sample file to send. As it's courseware for a federal client, it will take some time to get a sample I can freely send.

Hello. I'm interested in this discussion, because as of Sept. 25, 2020, the situation is the same. The bullet and number buttons in Storyline create visual lists, but they aren't "real" lists, and are read as @Kelly Sims indicated as a "run on sentence." We have come up with tricks that can make this more usable, but NONE work to make it a list that will be recognised by a screen reader (JAWS/NVDA). Here's what we've been trying:

1. Put every paragraph into it's own text box. Good: Slows down the screen reader, because it reads each as a separate "paragraph"/object, so if the screen reader is in "read whole page mode" there's a pause, and if the user is pressing keys, they press down arrow to get to each one. Bad: Not a list, doesn't say that it's a list, doesn't read "bullet." Also, the screen reader user can't use list tools with their screen reader, like pressing "L" to jump to a list. Also, high risk of mis-aligning individual text boxes, takes time to do, and text revisions are a complete pain.
2. Method #1, except leave the original text box and hide if from screen readers by de-selecting the "Object is visible to accessibility tools" checkbox, and making individual text boxes on a copy of the original. The copies have one paragraph each, and ARE visible to the screen reader. Change their state to "hidden" and then the screen reader "reads" the copies, and the original isn't read. Has almost all the bad stuff the 1st method has, except that revisions and alignment are way easier (because the copies aren't visible so don't have to be lined up etc.)
3. Method #2 (or original text box with bulleted list), but add additional alt text at the beginning and throughout, e.g., "list with 4 items, bullet. <item text> bullet <item text>" This makes it sound like you have a real list (good) but (bad) it's NOT a list, so L still won't work to jump to the list, and is really misleading the user. 
4. Method #2 so you get the nice pauses, and add alt text to each one with ONLY the work "bullet" at the beginning. You aren't telling users that it's a lit, but you are indicating through a) pauses and b) the word bullet that you have various items and they're bulleted.
5. Method #2, but instead of adding "bullet" to the alt text, add "(1 of 3)" which seems to be read by screen readers in a different voice, and is helpful to know how many there are. 

I'd love for Articulate to, forgive the pun, fix this with a bullet, because there's no way to pass this important accessibility requirement otherwise. Also, every Microsoft Office product has this built in, and there's really no excuse to not have your bullet and number list buttons create genuine programmatic bulleted and numbered lists.

Hello Karin!

Thank you for these details! I can understand how frustrating this is, especially since screen readers read bullet points in Microsoft products. This is currently on the roadmap! It is included in Semantic Formating on the Feature Roadmap.

Thank you for sharing these workarounds as well! We'll make sure to update this discussion when these features are released!

It's important to add that the list needs to be "seen" by a screen reader as a list, so that the screen reader will jump to it (or back to it) when the user presses keys to read the next/previous list.  This is in addition to other prompts that screen readers use such as telling you how many items are in the list (list with 3 items), and NOT reading the character used to create the bullet. By this last point I mean that if you replace the bullet formatting with typing, such as using a symbol, the only symbol that is read that makes any sense is the actual bullet character (Alt+0149), and any other character is read as its keyboard equivalent in that font, which might be the number 4, for example. A list of 3 colors would read: "4 red 4 blue 4 green". Numbered lists are more forgiving -- you can type 1. and the screen reader will just read "one" which is helpful.

Thanks, Karin. 

I've shared your thoughts with the team.

Hi Karin,

We just released another update for Articulate 360 and included a few new items you'll see in the release notes.

The items you'll be interested in is:

• New: Let learners with accessibility needs change the visual appearance of text in a published course to make it more readable. Learn more about accessible text.
• New: Text publishes with the proper semantic formatting for headings, links, lists, and other elements so screen reader users can explore content easily.
• New: Use text styles to make content easy to navigate with a screen reader. Accessible text styles allow learners with visual disabilities to identify headings, hyperlinks, blockquotes, and paragraphs on each slide so they understand its layout and context. Learners can also use screen reader shortcuts to jump directly to headings and links.

Just launch the Articulate 360 desktop app on your computer and click the Update button for Storyline 360. Details here.

Please let us know if you have any questions, either here or by reaching out to our Support Engineers directly.

Hello Everyone!

I'm happy to return to this discussion with some great news 🗞

We've fixed the issue where: JAWS Not Announcing Bullets In Lists On Stage.

Be sure to install the latest Storyline 360 update (Build 3.49.24347.0) to take advantage of all the recent features and fixes.

If the problem happens again, please let us know, or you can always work directly with our support engineers here.

Hi Brett,

In looking at Kevin's case, there was alt text assigned to the bullets and headings. Once removed, the screen reader was able to read the text correctly.

If you're running into issues and need some help with testing, feel free to connect with our support team, and they can lend a hand!

@ren ... that did the trick! Remove anything in the text field.