Forum Discussion
Making a scroll bar keyboard accessible
Hello,
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?
Thanks!
Ana
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,
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, 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:)
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 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.
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
