Designing for Accessibility
Apr 23, 2022
I am interested in the best way to get designers/authors of eLearning to understand what should and should not be included in the design of a course meant to be accessible to those individuals who use keyboard navigation and or screen readers. As a developer I am often tasked with making courses accessible when the designer has given no thought to what that means or what it entails on the development side of the project.
I applaud Articulate for the advances that they have made in recent years in trying to make their tools produce more accessible content. However I still find that there are many instances where I cannot build what a designer asks for without making incredibly complicated slides (or duplicate slides). Even simple things like changing the state of an object to reveal content or displaying a layer with additional content can become a terrible user experience. Solutions that may work for a keyboard navigator may not work well for someone who also has vision impairments. It is very easy for the user to get "lost" among multiple layers.
I have given the designers links to various Articulate articles regarding its capabilities but I find that that isn't enough to convey the challenges of developing accessible content.
In addition I would like some concrete examples of how developers deal with real world problems like those I have mentioned. One thought I had for the "click to reveal" problem is to add Alt text to the button describing the content that would be shown in a different state. But how would I handle content that needs to be displayed on its own layer? For example if clicking a button starts an animation displayed on a new layer how can I prevent the user Tabbing into the hidden layer before it is active?
1 Reply
An object on the focus order for a screen reader is only active when the layer is shown.
For your example when a user tabs the the button and presses enter/space then the layer will show and what is on that layer becomes active. However, if the object is nit directly after the button in the focus order (i.e. it is before the button or a few items after the button) then that object will not be read immediately once the button is pressed.
There is a couple of times when this is not the case, if you have the layer properties set to prevent user clicking on the base layer, then the layer becomes modal and immediately takes focus, then it is dependent on how you have the focus organised for that layer. In a future update when Storyline add Dialogue layers these will behave the same way that they take immediate focus.
It is often difficult to retrofit solutions on to a build that had no thought for accessibility, for me I always work with the idea that the experience does not have to be identical it just has to be a good experience. You do not want the user to get lost and it may mean building in additional accessibility functions.