It's often better to let the user attempt submission and provide explicit feedback in response. There are a number of usability and accessibility issues with disabling form submit buttons until the user has entered valid/expected data. You can make disabled buttons focusable again by adding tabindex='0'. This may cause confusion among some screen reader users and users exploring by Tab at a high zoom level. Beware that adding disabled makes the unfocusable. Standard elements can be disabled using the disabled property/attribute. Note the classes, used for sizing and alignment. Hence, they should take aria-hidden='true' and focusable='false'. Icons should contain text or be otherwise accessible to assistive technologies, nor should they be focusable. Where icons are provided to buttons and calls-to-action, make sure they are taken from the GEL SVG Iconography library. Additionally, they are often suppressed by default in screen reader verbosity settings. These are only revealed on hover, not focus, in most browsers. Unfortunately, aria-label is not picked up by popular translation services. Where an icon-only button is employed (the ubiquitous play/pause button is a good example), provide the text via a visually hidden, not aria-label. Icon-only buttons are especially hard to activate via voice since the (hidden) textual label has to be guessed by the user. In most cases, controls that rely on icons alone are not recommended, even where invisible labels are provided to assistive technologies. Text nodes are interoperable, since they can be seen, heard via screen reader synthetic voices, and used as activation cues with voice activation software.

Most buttons and calls-to-action should simply be labeled via their text node. Calculate taxĪs a rule of thumb: if a clickable control is intended for running JavaScript, it should be a with type='button'.

This is especially important inside a, since some user agents consider any found without an explicit type to be a form's submit button. Any buttons not intended for submitting forms should take type='button'. It is imperative clickable controls not eliciting link-like behaviour are marked up as elements. Standard link markup should be used, including an href (links omitting href attributes are not focusable by keyboard).Ī class is provided to the element as a styling hook, enabling it to be differentiated from generic links visually. In most cases, a call-to-action should be marked up as a link, since the behaviour is typically to transport the user to a new page or section. Recommended markup Basic call-to-action link Where button state changes, this change should be visually represented as well. The visual design of buttons and calls-to-action should also be indicative of their behavior. An element announced as a link that behaves as a button creates a confusing and off-putting experience. This is especially helpful for assistive technology users, such as those running screen reader software. An adjacent 'Register' call-to-action-taking the user to a different form, in a different page or screen-would benefit from semantics. For example, a 'Sign in' control would suit a because its job is to submit the sign in form. That is: links should be used where navigation is elicited, and s where a non-navigational action is being invoked. The most important of these rules is that the and elements are assigned to appropriate respective tasks. Only where these rules are observed will the user experience comfortable interaction. But they should conform to some fundamental rules. BBC buttons and calls-to-action differ widely in form and purpose.

More info buttons