I am working to make an online training developed in Articulate Storyline keyboard-accessible. I can't seem to figure out how to make a layer with a scroll bar keyboard accessible, so that users can read all the text. Is there a way to do this or do I have to set up a work-around?
Currently it's a known issue with our QA team that the scroll panels are not accessible with keyboard actions. You can tab to it, but you can't scroll.
Oh hi Ashley, would you know if the scroll panel could be called with a javascript? or are the Articulate team working on making the scroll panel accessible. these scroll panels play an important roll in our templates and complete keyboard accessibility is becoming an important matter with the compliance standards.
I'm not equipped to support and personally don't know enough about Javascript to be able to answer that with certainty - but I guess it's worth a try?
In regards to the accessibility features, I don't have updates to share on where they stand or what our team plans to include. But you'll want to share your thoughts in the form of a feature request so that our product development team is aware of specific features or elements you'd like to see in future versions of Storyline.
Did you end up finding a javascript solution to keyboard accessibility of scrollbar in layers? We are stuck with getting a course approved due to accessibility compliance standards.
Thanks for any info you can provide on solutions to scrolling and keyboard accessibility that have worked for you!
I'm not certain Byron is still subscribed to this thread, so you may want to use the 'contact me' feature on his profile to reach out and see if he's able to share additional information with you.
HI Ana, our current work-around (or work towards) is placing all essential screen text in the alt-tag of one selectable 'dummy' element on the page under the scrollbar and turn all the other elements' alt tags off, except for the essential navigational items off course.
The slide is then not necessarily inclusive(as per UDL principles) but is accessible, as assistive technology will be able to read what is on the page, as it is copied in the alt tag of the 'dummy' element. My idea is that those with no or bad vision will still be able to have the textual content read out to them, those with contrast issues can use the scroll as normal, those with bad hearing can read the scroll as normal, I believe that those with assistive technology for navigation can scroll using the keyboard as log as you leave the alt tag for the scroll entry field in existence.
Not the nicest solution but it should pass, depending on how stringent they are, I believe that most accessibility is governed by guidelines not rules and there is or should be flexibility based on reason and show willingness to find solution in design. Alternatively you could turn all the alt tags off and use notes as a transcript layer, but I believe the user would have to activate it via a button, the effect is more or less the same. Using transcript is more common when using video with audio.
It's definitely not ideal and we consider steps like these, steps towards full accessibility limited by the application. The last alternative is to re-design the slide, place the text in layers or mimic a 'static' scroll bar through the use of layers.
Can't wait for Articulate to fix this painful problem, we just need to be able to alt-tag items in the scroll and the scroll to move when you tab through these items:)
I don't see the scrolling panel accessibility as a fixed bug in the release of update 5, and you can see all the fixes listed here - but if it's working for you that's good to hear!
I should clarify that this has fixed the scroll bar of the scroll entry field, being able to control the scroll bar with the arrow keys, Elements within the scroll bar can be selected and alt-tags can be read as before.
I just tested a 2 month old publish and I don't think it was working before, Perhaps it was fixed because they worked on fixing the keyboard access to the sliders(if there is a relation), perhaps they did it one update earlier, although I think I would have picked it up during testing, anyhow I'm ecstatic with the latest changes around accessibility:)
All we have to do now is open the old files in the latest update, check those alt-tags, republish and 'Bob's your uncle:)', all files are then ready for screen readers and assistive technology, pretty much up to our accessibility standards. We can comfortably continue using scroll-entry fields again.
Most our accessibility focus is on making reasonable adjustments around inclusive design, logic, contrast, transcripting presentations and alt-tagging elements or removing element's visibility from accessibility tools.
Thanks Byron for the clarification and update. I don't know how it may or may not be connected in the program code, but it sounds like an accurate assessment. ;-)
Thanks for sharing Byron. I use a text box within a scroll panel. Does this now mean with the version 5 update that the learners using assistive devices can now use the keyboard functions to navigate the scroll panel to allow their device to read the text box content? So does that mean I can just make the scroll panel an object visible to accessibility tools and the user will be able to scroll with their keyboard to read the text box content? Can you please confirm.
I don't see that this particular issue with scrolling panels and screen readers is resolved, in the sense that if you enabled the scrolling panel for the screen reader or add alt text to it - than it experiences difficulty within the screen reader. If you don't add those items/elements - than it seems to be able to read the text, although the user can't use arrow keys to scroll. I'm not sure what Byron set up to get this working so hopefully he'll be able to share a sample project or additional information with you here.
Sandy, I know it doesn't mention anywhere that it is, but it is fixed as far as I can see, unless we are talking about a different thing, from what I see it is working
To create a test file
1. Make sure you have the latest update 2. start a new file, insert scroll entry field, 3. insert one or multiple blocks of text 4. Publish - et voila, 5 test by using tab and the arrow keys on the scroll field
- you can now select the scroll entry field with the tab key, which you can then control with the arrow keys, you can give the scroll entry field an alt tag(e.g. use arrow keys or skip this field). the screen reader will read all the text in an element (and?) or the alt tag. Again you can test this, with Jaws screen reader(as an example).
Inside the scroll entry field you keep the elements visible, if it is an image you can turn of the visibility for assistive tech, else you need to insert text for the alt tags, the screen reader should read out all elements.
I've attached a simple test, just tab through the elements, select the scroll and use, the up and down keys to scroll, you will still have to continue to tab through each elements to read each individual element,
if you really want the screen reader to read the text as one, when the user hits the scroll field (for visually impaired people perhaps?) you will have to place all the text in the scroll entry's alt tag, and disable the alt tags from the elements inside the scroll field, I would probably choose against this, and just ad an instructional alt tag to the scroll field.
It's up to you, have fun, try it out, if we are talking about the same thing(arrow control on the scroll) it is fixed, maybe because they fixed the sliders, and didn't mention the scroll (similar?)
I am working on a project and came across a similar type of issue. I am using Articulate Storyline 2.
There is a text entry field where user has to fill in his/her name and a list a country(in a scrolling panel). There are 2 issues which i am facing right now.
I want user to write his/her name and then jump to country field after pressing the tab key. Currently I have to press the tab button twice to jump to the country field.
I want user to navigate to his/her country from the keyboard up and down arrow button and then the use of Enter key to select his/her country.
I am attaching the file here for your reference for the better understanding. You will find 2 slides where i tried to work with different mindset. In the first slide i tried to work around everything on the base layer and in the second slide i tried to make use of slide layer as well.
Please check the published version before making sure its working.
I saw the same as you described, and I found that the issues mentioned here with the scrolling panel and accessibility are still open issues for our team to investigate in Storyline 2.
I did notice that the tab order was correct (in terms of pressing tab twice on your first slide to navigate to the drop down) as there is the additional box of your "white rectangle" that users are technically tabbing to first, even though it's not visible.
We'll let you know here if there are any updates on this issue, so you're in the right place to stay updated on this bug's progress.
I've published full HTML5 from 360 and still am not able to keyboard into my scrolling panels to access links within. Has this been resolved yet? My search on this site is not pulling up relevant discussions or articles to the affirmative. Please advise. Thanks.
Thanks for including that link, and I do see the problem you described. Have you tried adding a hotspot on top of the link, with a trigger to open the link when the learner clicks the hotspot?
33 Replies
Hi Ana,
Currently it's a known issue with our QA team that the scroll panels are not accessible with keyboard actions. You can tab to it, but you can't scroll.
Oh hi Ashley, would you know if the scroll panel could be called with a javascript? or are the Articulate team working on making the scroll panel accessible. these scroll panels play an important roll in our templates and complete keyboard accessibility is becoming an important matter with the compliance standards.
Thanks
Byron
Hi Byron,
I'm not equipped to support and personally don't know enough about Javascript to be able to answer that with certainty - but I guess it's worth a try?
In regards to the accessibility features, I don't have updates to share on where they stand or what our team plans to include. But you'll want to share your thoughts in the form of a feature request so that our product development team is aware of specific features or elements you'd like to see in future versions of Storyline.
Hi Byron,
Did you end up finding a javascript solution to keyboard accessibility of scrollbar in layers? We are stuck with getting a course approved due to accessibility compliance standards.
Thanks for any info you can provide on solutions to scrolling and keyboard accessibility that have worked for you!
Ana
Hi Ana,
I'm not certain Byron is still subscribed to this thread, so you may want to use the 'contact me' feature on his profile to reach out and see if he's able to share additional information with you.
HI Ana, our current work-around (or work towards) is placing all essential screen text in the alt-tag of one selectable 'dummy' element on the page under the scrollbar and turn all the other elements' alt tags off, except for the essential navigational items off course.
The slide is then not necessarily inclusive(as per UDL principles) but is accessible, as assistive technology will be able to read what is on the page, as it is copied in the alt tag of the 'dummy' element. My idea is that those with no or bad vision will still be able to have the textual content read out to them, those with contrast issues can use the scroll as normal, those with bad hearing can read the scroll as normal, I believe that those with assistive technology for navigation can scroll using the keyboard as log as you leave the alt tag for the scroll entry field in existence.
Not the nicest solution but it should pass, depending on how stringent they are, I believe that most accessibility is governed by guidelines not rules and there is or should be flexibility based on reason and show willingness to find solution in design. Alternatively you could turn all the alt tags off and use notes as a transcript layer, but I believe the user would have to activate it via a button, the effect is more or less the same. Using transcript is more common when using video with audio.
It's definitely not ideal and we consider steps like these, steps towards full accessibility limited by the application. The last alternative is to re-design the slide, place the text in layers or mimic a 'static' scroll bar through the use of layers.
Can't wait for Articulate to fix this painful problem, we just need to be able to alt-tag items in the scroll and the scroll to move when you tab through these items:)
Thanks Byron for sharing the update here and information on what you've done with Ana.
Yay:) all of it is solved now with the latest update v.5 so good guys!!!!!!!!!
Hi Byron,
I don't see the scrolling panel accessibility as a fixed bug in the release of update 5, and you can see all the fixes listed here - but if it's working for you that's good to hear!
Hi Ashley
I should clarify that this has fixed the scroll bar of the scroll entry field, being able to control the scroll bar with the arrow keys, Elements within the scroll bar can be selected and alt-tags can be read as before.
I just tested a 2 month old publish and I don't think it was working before, Perhaps it was fixed because they worked on fixing the keyboard access to the sliders(if there is a relation), perhaps they did it one update earlier, although I think I would have picked it up during testing, anyhow I'm ecstatic with the latest changes around accessibility:)
All we have to do now is open the old files in the latest update, check those alt-tags, republish and 'Bob's your uncle:)', all files are then ready for screen readers and assistive technology, pretty much up to our accessibility standards. We can comfortably continue using scroll-entry fields again.
Most our accessibility focus is on making reasonable adjustments around inclusive design, logic, contrast, transcripting presentations and alt-tagging elements or removing element's visibility from accessibility tools.
Thanks
Thanks Byron for the clarification and update. I don't know how it may or may not be connected in the program code, but it sounds like an accurate assessment. ;-)
Thanks for sharing Byron. I use a text box within a scroll panel. Does this now mean with the version 5 update that the learners using assistive devices can now use the keyboard functions to navigate the scroll panel to allow their device to read the text box content? So does that mean I can just make the scroll panel an object visible to accessibility tools and the user will be able to scroll with their keyboard to read the text box content? Can you please confirm.
THanks in advance.
Sandy
Hi Sandy,
I don't see that this particular issue with scrolling panels and screen readers is resolved, in the sense that if you enabled the scrolling panel for the screen reader or add alt text to it - than it experiences difficulty within the screen reader. If you don't add those items/elements - than it seems to be able to read the text, although the user can't use arrow keys to scroll. I'm not sure what Byron set up to get this working so hopefully he'll be able to share a sample project or additional information with you here.
Sandy, I know it doesn't mention anywhere that it is, but it is fixed as far as I can see, unless we are talking about a different thing, from what I see it is working
To create a test file
1. Make sure you have the latest update
2. start a new file, insert scroll entry field,
3. insert one or multiple blocks of text
4. Publish - et voila,
5 test by using tab and the arrow keys on the scroll field
- you can now select the scroll entry field with the tab key, which you can then control with the arrow keys, you can give the scroll entry field an alt tag(e.g. use arrow keys or skip this field). the screen reader will read all the text in an element (and?) or the alt tag. Again you can test this, with Jaws screen reader(as an example).
Inside the scroll entry field you keep the elements visible, if it is an image you can turn of the visibility for assistive tech, else you need to insert text for the alt tags, the screen reader should read out all elements.
I've attached a simple test, just tab through the elements, select the scroll and use, the up and down keys to scroll, you will still have to continue to tab through each elements to read each individual element,
if you really want the screen reader to read the text as one, when the user hits the scroll field (for visually impaired people perhaps?) you will have to place all the text in the scroll entry's alt tag, and disable the alt tags from the elements inside the scroll field, I would probably choose against this, and just ad an instructional alt tag to the scroll field.
It's up to you, have fun, try it out, if we are talking about the same thing(arrow control on the scroll) it is fixed, maybe because they fixed the sliders, and didn't mention the scroll (similar?)
thanks, bye
any update on adding accessibility to scroll panels?
Hello Marie,
Sorry that you've run into an issue with this as well.
It looks like the issue with JAWS not reading the object or alt text for scrolling panels is still open with our team.
The contents of the scrolling panel should be read and it looks like Byron has a bit of a workaround above regarding the alt text as well.
If you need our team to take a look at anything, feel free to share here.
Hello Everyone,
I am working on a project and came across a similar type of issue. I am using Articulate Storyline 2.
There is a text entry field where user has to fill in his/her name and a list a country(in a scrolling panel). There are 2 issues which i am facing right now.
I am attaching the file here for your reference for the better understanding. You will find 2 slides where i tried to work with different mindset. In the first slide i tried to work around everything on the base layer and in the second slide i tried to make use of slide layer as well.
Please check the published version before making sure its working.
Thanks
Himanshu Sharma
Hi Himanshu,
Thanks for sharing your file here with us.
I saw the same as you described, and I found that the issues mentioned here with the scrolling panel and accessibility are still open issues for our team to investigate in Storyline 2.
I did notice that the tab order was correct (in terms of pressing tab twice on your first slide to navigate to the drop down) as there is the additional box of your "white rectangle" that users are technically tabbing to first, even though it's not visible.
We'll let you know here if there are any updates on this issue, so you're in the right place to stay updated on this bug's progress.
I've published full HTML5 from 360 and still am not able to keyboard into my scrolling panels to access links within. Has this been resolved yet? My search on this site is not pulling up relevant discussions or articles to the affirmative. Please advise. Thanks.
Hi Tonya!
Thanks for including that link, and I do see the problem you described. Have you tried adding a hotspot on top of the link, with a trigger to open the link when the learner clicks the hotspot?
This post was removed by the author
This post was removed by the author
Hi,
I just reading this thread that was started 5 years ago. Are scrolling panels with text now keyboard accessible?
From my testing, it looks like it isn't. Can you please clarify.
Thanks,
Mark
I have the same question as Mark.
Same question here: are scrolling panels with text now keyboard accessible?