Am I missing something? I updated Articulate this morning and now I cannot tab to anything on the screen except navigation buttons. Also the screen reader does not seem to read out anything except the alt-text on the buttons.
I installed the update to my laptop for testing before installing to my office PC. I did not know there was a rollback option, so there's something I've learned at least.
To the issues reported on the previous page, yeah, I'm experiencing the same. I had posted a long description of the issue but have deleted the thread now that I see William's experience. Mine is the same. Slide titles are read SEVERAL times. Some random URL path is also read. Tabbing content seems completely random now. The word "BLANK" is read between every element on a slide. Usually hearing "blank" indicates an empty return break in PDF documents. Not the case here. Trying to navigate the auto-generated menu tree is chaotic as when I try to navigate to another slide via the tree view menu, the selection skips from lesson 1 title slide to halfway into lesson 3. There appears to be no logic or control over it. The next tab just exits the menu altogether.
I really can't imagine how this could have been tested before release and still approved.
Thanks for posting this. I missed this thread last week somehow! I'm curious if you've made any new progress or discoveries as to how to work in the new update? Did your screen reader user have any insights by chance?
I experienced the same confusing behavior as Noel above when I was previewing and testing a course with the keyboard and JAWS after installing the new update. It was a course that I had created in a prior version of Storyline 360.
Can anyone speak to whether they've experienced a difference in keyboard behavior/what's read out in JAWS between (a) a new course file created from scratch with the latest update installed, and (b) a file created in a prior version and then edited/previewed with this update installed?
Hi Noel, I got very little response on this thread from articulate staff so I logged a support case. They have confirmed some of the issues may be bugs and are further investigating. It seems that you may not get the same results in a course that has been published to an LMS as you would in Review 360 (which is a shame because I would expect Review to act the same as the LMS output). I've been doing the testing myself using a JAWS screen reader that is installed on my computer. I am hoping to get one of our staff (who use a screen reader) to test it as well and tell me what they get. I would imagine that those who use screen readers may have some tips and tricks that I am not aware of.
Hey all! So I too have upgraded to "36" and I'm seeing a ton of issues here as well.
When using Tab to move around the screen, the "focus" surrounds the entire page content, but I cannot tab "into" the page to tab through the actual page content itself.
Screen reader is also reading the alt text of graphics first, despite having the Tab order set while editing / authoring in Storyline
List items (bulleted or numbered) are rendered as graphical elements. Can't use the Tab key to move through list items on the page.
We tested using JAWS. The screen reader doesn't select the main slides at all. What we're seeing is that JAWS will initially "read" a page when you first get onto a slide, but you can't get the screen reader to go through the page content, either by clicking on anything or tabbing into it. Again, the Tab key just moves around the perimeter of the page by focusing on all of the player controls in a clockwise fashion, but no focus is detected for elements on the page. The ONLY exceptions are button objects and question objects (checkboxes, radio buttons)
Looks like a lot of 508 users have rolled back to the previous SL360 build to avoid those very issues. For whatever it's worth regarding your third bullet there, I don't think SL360 recognizes bullets anyway. Or at least not when you export your build. it does not create proper List and List Item HTML tags that your reader is looking for. Instead, it just groups everything within a text frame into a single <tspan> tag. Same effect when using in line hyperlinks. No <L>, <LI>, <link>, <h1>, etc. Just the <tspan> for all contents of your slide text frame.
What you are experiencing is actually pretty much how this new functionality is supposed to work. When you open a page it reads the whole page (including all buttons - which I think is too much especially if you have a lot of buttons on a page). It then only allows you to tab to buttons. This is good for keyboard users but I'm not convinced that it is good for screen reader users. I also found that on layers it read everything on the screen when the layer opens but leaves the important text to last (even if it is first in tab order) and this is not acceptable. I have logged a support case with Articulate outlining my findings and they have been able to replicate them. It seems that it is important enough that they have now passed it on to a technical expert. Not sure that this update has been thought through well.
I too am baffled by the tab order now. I have a table that I made in SL and it is not read at all by the screen reader, I have tried tab, arrow buttons, everything I can think of to get the screen reader to read my tab order. I have many alt texts that are critical for the screen reader to read and it just doesn't work. I am using NVDA and am in preview mode.
Following this thread, thank you all for posting your experiences. I've been having trouble sorting through the changes, didn't realize that viewing in Preview mode is no longer enough.
In my experience, a screen reader's interpretation of a preview is very different than when viewed in a browser. Even then, Chrome is a completely different experience from IE.
Ugh - I want to be able to tab through my order of items on a slide so I know it's being read in the correct order. With this "update" the entire slide is selected. And using the arrow keys is hit or miss.
I hate to say it, but I am experiencing all of these issues as well. Tested in IE and Chrome. The really odd part, is that the experience doesn't seem to adhere to the Tab Order.
So essentially you press the down key instead of tab, but there are some bugs I am experiencing still. For example, some begin reading automatically, some do not.
Also, why is my screen reader reading "blank" between each object I have listed in my tab order?
I understand your concerns and appreciate that you've taken the time to share them with us!
Yes, the entire slide is selected which tells the screen reader what to read off. From there, you'll designate which objects are read off by using the Accessibility feature for each object. Content will be read automatically on a slide which is what most screen reader users experience because that paints a picture of what is on the screen.
In regards to the arrow keys, I'm interested to hear which screen reader you're using. My personal preference is NVDA, but we do support JAWS and VoiceOver. You'll notice this is a slight difference with how arrow keys interact depending on the screen reader. For instance, here's a JAWS Keyboard Shortcut Guide and here's an NVDA Keyboard Shortcut Guide.
Katie,
I haven't heard a screen reader read off "Blank". Is it consistent on every slide, or just one?
For anyone else testing with JAWS (I'm learning as I go), it's worth knowing that:
down arrow = reads a random small amount of content
alt + down arrow = reads a paragraph at a time
insert + down arrow = reads whole slide.
The only problem I'm having with using the arrows to navigate, is that it doesn't deal with buttons correctly. When tabbing it name the button and says, "Press space to activate." With any of the arrow options, it just reads the name.
Is anyone else finding this and/or know any useful JAWS tips?
If you navigate in JAWS using just the down arrow, it reads blank between every object. E.g Title... blank... nice long paragraph... blank... graphic image... blank... menu button...
Hi Lauren - thanks for your help. Yes, the "blank" between objects is consistent on all of my slides. These slides have multiple objects being read (in custom tab order, with some alt-text that I made).
Support told our team there are two options 1 - reinstall older version or 2 - use current version but wait for bug fixes. I am going to reinstall a previous version for the time being. This project is a quick turnaround for our client and we have to be consistent with how we delivered these in the past with the way the screen reader works for our learners. Will continue to follow this thread/fix! Thanks for the help!
Hi Katie, can I ask you to which version will you roll back to avoid these problems? I'm about to start developing a course and I need to be sure that it works fine in both jaws and nvda and would be happy not to try to figure out workarounds to bugs;
The version with the 508 update was in January I believe, so I reinstalled the version from December 19, 2019 (3.35.21017.0) and JAWS is working just fine :)
So I just encountered the same issue in March 2020. A very simple course I had published in November 2019, I needed to republish. I didn't change a thing, just opened it up and republished the course (I had just deleted the zip file 2 weeks ago with the original scorm files). Seemed like a no-brainer. The course is a 1 pager with a title, transcript button, scrolling text and transcript text (hidden until the button is clicked). Outside of the scrolling text, everything is focusable and in the described order. Now on this republish, all of sudden I can only tab focus on the button before it goes to the window about skipping navigation elements. Regardless of what I add or delete, that single button is the only tab focusable item on the page. Using Jeff F's idea of rolling back the updates, I went back to Nov 2019 update. Poof, problems all solved and all 3 elements are focusable. It seems I'll be holding out on the updates until I can confirm this is fixed.
I think for most people we understand the theory of what Storyline 360 is supposed to do in regards to this new accessibility update.
The problem is twofold: one. it doesn't do it exactly as prescribed and two, it reads all tagged objects on the screen which is often way too much information at once for those using screen readers. If it was able just to read the text and then allow the user to tab to the next items (such as buttons and images) and only have them read when they are tabbed to this would be better. Even if you gave us the ability to indicate which things should be read automatically (that is, once the screen opens) and which should only be read when they are tabbed to this would solve the problem.
As it stands this update is causing many in the community a great deal of trouble and many of us have rolled back to previous versions of Articulate.
My biggest concern here is Articluate's silence over all this. Any comments (few as they are) seem to only reinforce that there is nothing wrong and we are just misunderstanding how it all works. No one is taking us seriously or listening to our concerns. Even with the job I logged I keep getting wrong information and a misreading of what I am saying over and over. It is almost like Articulate is trying to avoid this issue and hopes it will go away.
We are all paying for this product and we would like to get what we are paying for and we would also like to be heard...
You're right William! The user needs to have control over when things are read on screen. Tabbing to each item allowed this. Now, like you say, all tagged objects are read.
83 Replies
I installed the update to my laptop for testing before installing to my office PC. I did not know there was a rollback option, so there's something I've learned at least.
To the issues reported on the previous page, yeah, I'm experiencing the same. I had posted a long description of the issue but have deleted the thread now that I see William's experience. Mine is the same. Slide titles are read SEVERAL times. Some random URL path is also read. Tabbing content seems completely random now. The word "BLANK" is read between every element on a slide. Usually hearing "blank" indicates an empty return break in PDF documents. Not the case here. Trying to navigate the auto-generated menu tree is chaotic as when I try to navigate to another slide via the tree view menu, the selection skips from lesson 1 title slide to halfway into lesson 3. There appears to be no logic or control over it. The next tab just exits the menu altogether.
I really can't imagine how this could have been tested before release and still approved.
Thanks for posting this. I missed this thread last week somehow! I'm curious if you've made any new progress or discoveries as to how to work in the new update? Did your screen reader user have any insights by chance?
I experienced the same confusing behavior as Noel above when I was previewing and testing a course with the keyboard and JAWS after installing the new update. It was a course that I had created in a prior version of Storyline 360.
Can anyone speak to whether they've experienced a difference in keyboard behavior/what's read out in JAWS between (a) a new course file created from scratch with the latest update installed, and (b) a file created in a prior version and then edited/previewed with this update installed?
Hi Noel, I got very little response on this thread from articulate staff so I logged a support case. They have confirmed some of the issues may be bugs and are further investigating. It seems that you may not get the same results in a course that has been published to an LMS as you would in Review 360 (which is a shame because I would expect Review to act the same as the LMS output). I've been doing the testing myself using a JAWS screen reader that is installed on my computer. I am hoping to get one of our staff (who use a screen reader) to test it as well and tell me what they get. I would imagine that those who use screen readers may have some tips and tricks that I am not aware of.
Hey all! So I too have upgraded to "36" and I'm seeing a ton of issues here as well.
We tested using JAWS. The screen reader doesn't select the main slides at all. What we're seeing is that JAWS will initially "read" a page when you first get onto a slide, but you can't get the screen reader to go through the page content, either by clicking on anything or tabbing into it. Again, the Tab key just moves around the perimeter of the page by focusing on all of the player controls in a clockwise fashion, but no focus is detected for elements on the page. The ONLY exceptions are button objects and question objects (checkboxes, radio buttons)
Looks like a lot of 508 users have rolled back to the previous SL360 build to avoid those very issues. For whatever it's worth regarding your third bullet there, I don't think SL360 recognizes bullets anyway. Or at least not when you export your build. it does not create proper List and List Item HTML tags that your reader is looking for. Instead, it just groups everything within a text frame into a single <tspan> tag. Same effect when using in line hyperlinks. No <L>, <LI>, <link>, <h1>, etc. Just the <tspan> for all contents of your slide text frame.
Hi Rob,
What you are experiencing is actually pretty much how this new functionality is supposed to work. When you open a page it reads the whole page (including all buttons - which I think is too much especially if you have a lot of buttons on a page). It then only allows you to tab to buttons. This is good for keyboard users but I'm not convinced that it is good for screen reader users. I also found that on layers it read everything on the screen when the layer opens but leaves the important text to last (even if it is first in tab order) and this is not acceptable. I have logged a support case with Articulate outlining my findings and they have been able to replicate them. It seems that it is important enough that they have now passed it on to a technical expert. Not sure that this update has been thought through well.
Kind regards,
William
No Rob, I haven't come across the bullet issue as I often don't use them but it sounds like and extra issue that needs to be seriously considered.
Hi Leslie,
I too am baffled by the tab order now. I have a table that I made in SL and it is not read at all by the screen reader, I have tried tab, arrow buttons, everything I can think of to get the screen reader to read my tab order. I have many alt texts that are critical for the screen reader to read and it just doesn't work. I am using NVDA and am in preview mode.
Following this thread, thank you all for posting your experiences. I've been having trouble sorting through the changes, didn't realize that viewing in Preview mode is no longer enough.
In my experience, a screen reader's interpretation of a preview is very different than when viewed in a browser. Even then, Chrome is a completely different experience from IE.
Ugh - I want to be able to tab through my order of items on a slide so I know it's being read in the correct order. With this "update" the entire slide is selected. And using the arrow keys is hit or miss.
I hate to say it, but I am experiencing all of these issues as well. Tested in IE and Chrome. The really odd part, is that the experience doesn't seem to adhere to the Tab Order.
So essentially you press the down key instead of tab, but there are some bugs I am experiencing still. For example, some begin reading automatically, some do not.
Also, why is my screen reader reading "blank" between each object I have listed in my tab order?
Hi everyone!
I understand your concerns and appreciate that you've taken the time to share them with us!
Yes, the entire slide is selected which tells the screen reader what to read off. From there, you'll designate which objects are read off by using the Accessibility feature for each object. Content will be read automatically on a slide which is what most screen reader users experience because that paints a picture of what is on the screen.
In regards to the arrow keys, I'm interested to hear which screen reader you're using. My personal preference is NVDA, but we do support JAWS and VoiceOver. You'll notice this is a slight difference with how arrow keys interact depending on the screen reader. For instance, here's a JAWS Keyboard Shortcut Guide and here's an NVDA Keyboard Shortcut Guide.
Katie,
I haven't heard a screen reader read off "Blank". Is it consistent on every slide, or just one?
For anyone else testing with JAWS (I'm learning as I go), it's worth knowing that:
The only problem I'm having with using the arrows to navigate, is that it doesn't deal with buttons correctly. When tabbing it name the button and says, "Press space to activate." With any of the arrow options, it just reads the name.
Is anyone else finding this and/or know any useful JAWS tips?
If you navigate in JAWS using just the down arrow, it reads blank between every object. E.g Title... blank... nice long paragraph... blank... graphic image... blank... menu button...
Hi Lauren - thanks for your help. Yes, the "blank" between objects is consistent on all of my slides. These slides have multiple objects being read (in custom tab order, with some alt-text that I made).
Support told our team there are two options 1 - reinstall older version or 2 - use current version but wait for bug fixes. I am going to reinstall a previous version for the time being. This project is a quick turnaround for our client and we have to be consistent with how we delivered these in the past with the way the screen reader works for our learners. Will continue to follow this thread/fix! Thanks for the help!
Hi Katie, can I ask you to which version will you roll back to avoid these problems? I'm about to start developing a course and I need to be sure that it works fine in both jaws and nvda and would be happy not to try to figure out workarounds to bugs;
thanks
The version with the 508 update was in January I believe, so I reinstalled the version from December 19, 2019 (3.35.21017.0) and JAWS is working just fine :)
So I just encountered the same issue in March 2020. A very simple course I had published in November 2019, I needed to republish. I didn't change a thing, just opened it up and republished the course (I had just deleted the zip file 2 weeks ago with the original scorm files). Seemed like a no-brainer. The course is a 1 pager with a title, transcript button, scrolling text and transcript text (hidden until the button is clicked). Outside of the scrolling text, everything is focusable and in the described order. Now on this republish, all of sudden I can only tab focus on the button before it goes to the window about skipping navigation elements. Regardless of what I add or delete, that single button is the only tab focusable item on the page. Using Jeff F's idea of rolling back the updates, I went back to Nov 2019 update. Poof, problems all solved and all 3 elements are focusable. It seems I'll be holding out on the updates until I can confirm this is fixed.
Thanks a lot
Lauren,
I think for most people we understand the theory of what Storyline 360 is supposed to do in regards to this new accessibility update.
The problem is twofold: one. it doesn't do it exactly as prescribed and two, it reads all tagged objects on the screen which is often way too much information at once for those using screen readers. If it was able just to read the text and then allow the user to tab to the next items (such as buttons and images) and only have them read when they are tabbed to this would be better. Even if you gave us the ability to indicate which things should be read automatically (that is, once the screen opens) and which should only be read when they are tabbed to this would solve the problem.
As it stands this update is causing many in the community a great deal of trouble and many of us have rolled back to previous versions of Articulate.
My biggest concern here is Articluate's silence over all this. Any comments (few as they are) seem to only reinforce that there is nothing wrong and we are just misunderstanding how it all works. No one is taking us seriously or listening to our concerns. Even with the job I logged I keep getting wrong information and a misreading of what I am saying over and over. It is almost like Articulate is trying to avoid this issue and hopes it will go away.
We are all paying for this product and we would like to get what we are paying for and we would also like to be heard...
You're right William! The user needs to have control over when things are read on screen. Tabbing to each item allowed this. Now, like you say, all tagged objects are read.