Forum Discussion
Accessibility - Buttons/Icons/Shapes
Hello, all!
Just curious what some of you do to create accessible "buttons" in Storyline.
If you use icons as buttons, how do you make sure they are keyboard and screen reader-friendly? For example, do you use a shape or a button and embed an icon? Do you just use an icon but use alt text to describe the "button's" purpose?
Do you ever group items and use the group as a "button"? For example, making the individual elements not visible to accessibility tools but making the group visible and creating alt text that matches any text in the group to make the entire area selectable?
Or if you were visually grouping elements, would you avoid using an actual group and only make the clickable shape with a trigger visible to accessibility tools while leaving any other elements, such as text, not visible to accessibility tools? Then creating alt text for the shape to replace any "invisible" (to accessibility tools) text?
Or maybe you use a shape as an overlay and create appropriate alternative text?
Or do you stick with actual buttons for all selectable elements?
When exploring and auditing some courses, especially for keyboard and screen reader use, I'm seeing a variety of accessibility issues in this area, and I'm curious what you all tend to do to make "button" elements, or any selectable elements, more accessible. I definitely have my own thoughts, and it can be situational, but I would love to hear from the group about your practices with accessibility and "buttons." Feel free to share any examples you have as well!
Not here to judge any answers, just really to gather information and understand why people may use different techniques for this. And if there are any native screen reader users in the group, please feel free to tell us what you've found is best!
If you don't have experience with this and have any questions about why this is so important, please feel free to reach out - I am happy to help explain!
7 Replies
This is all assuming Focus Order is set correctly as well, of course!
Caitlin_B what a great best practices question! I bet SamHill elizabeth annykaymelendez PoojaDwivedi-4d or TomAllpress have some insight to share.
If you're going to use icons as buttons, I would recommend creating a shape (like a rectangle or square), then editing the state of that shape, and putting the icons inside of the normal state of that shape. The most difficult thing about icons is that the clickable parts may have holes in them. By putting the icon inside the normal state of a shape, you've made that shape the clickable object. You can even make the shape transparent, but it still remains a clickable object.
Inside the shape, I'd hide the icon from accessibility tools, and name the shape appropriately for focus order.
Thank you for your insight! I often see complex groupings of icons and shapes and text with inconsistent labeling, or the parts that are "visible" don't have the triggers. I also find that using a shape as the clickable object helps.
In the case of an icon in a shape like this, can you give an example of what you might use for the shape name and the alt text? I know without alt text provided a screen reader will usually read the object name, but I tend to also enter it as alt text.
For clickable objects, for the alt text I would give it whatever you would put if you had to put text on the button. For example, if a shape with a piece of paper icon in it is a clickable object that is going to show a layer about a company policy, I would give it the alt text Company Policy. You're right that screen reader will already identify it as a clickable object, so you should just call it what it is that it does!
Hi Caitlin_B I'm a fan of using shapes for buttons, due to them being more flexible in shape (corner radius, and various shapes) than the standard buttons. They also support all states that buttons do (Hover, Disabled, Visited etc) and correctly communicate those states to screen readers.
Whenever possible, I will use the shapes text field to label the button. I find this best for re-use, if using similar style buttons for multiple function (Continue, Reset, Submit) as it means I don't really have to be too concerned about ALT text, as the text within the shape is read by the screen reader, and once a "click" trigger is added, the element is interpreted as a button.
If adding any other design elements such as icons, I would hide these from the screen reader and just leave it to the shape text to communicate the buttons function. I avoid having multiple elements with ALT text within a button/shape. I want to be able to select the shape, and check the ALT text without needing to drill down into the states as this is where things can get messy and missed.
If it is just a graphical button and does not contain a text label, I would choose the BASE element to add the ALT text to, and not an element that is nested in the state of the BASE element. For example, a Print button may be made up of an elipse. This would be my BASE element, and I would add the ALT text "Print" to it. I would then add a printer icon to the Normal state of the ellipse and ensure that the printer icon is not accessible to screen reader. You can then add your Hover, Down, Disabled states.
I try and stick to the known (default) states as much as possible, for example using visited states to indicate something has been interacted with as I know the states are programmatically communicated to assistive technology without any special consideration from the develop, but there may be instances where I need to indicate other states. I would then use custom states, and communicate those states to screen readers using a variable in the ALT text.
For example, if I have a button, that when selected indicated a correct/incorrect state to the user by showing a tick or cross, I would communicate this to screen readers through a variable, for example:
Option 1%option1status%
The variable may be initialised as an empty string "", and so the alt text would just read "Option 1".
If the user then selected the option, and it is a correct selection, I might then update option1status variable to ", correct", and so the full ALT text would then be read as "Option 1, correct".
It is worth noting that custom states do behave differently in terms of inheritance of elements from states such as Normal, Selected and Visited. i.e a printer icon added to the normal state of a button will automatically be inherited by non-custom states of the button (Hover, Selected, Disabled etc), but a custom defined state will only inherit the BASE element.
Thank you for the helpful response and all of the detail!
I personally use buttons or shapes with text as you described, but I’m seeing more icons and “buttons” with multiple elements lately and I’ve been trying to help troubleshoot some issues. There are so many different ways to approach it.
I’ve never used a variable that way for correct/incorrect answers. I haven’t had that situation yet but I’m saving this to experiment with later!
