Forum Discussion
Accessibility - Buttons/Icons/Shapes
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.
- Caitlin_B5 days agoCommunity Member
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!