Keyboard functionality
Keyboard functionality is vital to an accessible digital experience. Customers with motor and visual disabilities rely on a keyboard to navigate to actionable and important pieces of the TELUS website and app. Some customers might use modified keyboards or other hardware that mimics the functionality of a keyboard on desktop and on mobile devices.
Learn more about keyboard accessibilityActionable elements
Actionable elements
Actionable elements help a user navigate, enter information, or submit forms. e.g. Links, Buttons, Form Fields, and Custom Components
- The visual design of interactive content must be different from static information. Use chevrons, underlines or other indicators to show how they are different. For colours, distinct is classified as a 3:1 ratio between the surrounding paragraph text and actionable element
- The text of the element must describe the action so use clear language to let the user know
- The code must tell assistive technologies that leverage keyboard accessibility, whether an element is an actionable HTML or Native App element. Use native HTML or native elements. Where they do not exist you will need to explore options like WAI-ARIA
- All clickable or tappable elements need to work with a keyboard, speech recognition software, or single switch, as well as screen readers and braille keyboards
- To support keyboard functionality, code elements as semantic HTML and native code whenever possible. Otherwise it's required to manually code with extra javascript or WAI-ARIA to make the component work for accessibility
Actionable elements help a user navigate, enter information, or submit forms. e.g. Links, Buttons, Form Fields, and Custom Components
- The visual design of interactive content must be different from static information. Use chevrons, underlines or other indicators to show how they are different. For colours, distinct is classified as a 3:1 ratio between the surrounding paragraph text and actionable element
- The text of the element must describe the action so use clear language to let the user know
- The code must tell assistive technologies that leverage keyboard accessibility, whether an element is an actionable HTML or Native App element. Use native HTML or native elements. Where they do not exist you will need to explore options like WAI-ARIA
- All clickable or tappable elements need to work with a keyboard, speech recognition software, or single switch, as well as screen readers and braille keyboards
- To support keyboard functionality, code elements as semantic HTML and native code whenever possible. Otherwise it's required to manually code with extra javascript or WAI-ARIA to make the component work for accessibility
Keyboard functionality at all sizes
Keyboard functionality at all sizes
Keyboard functionality needs to work at all major viewports, orientation, text size to 200%, and, within reason, browser zoom sizes to 200%.
Keyboard functionality needs to work at all major viewports, orientation, text size to 200%, and, within reason, browser zoom sizes to 200%.
Further reading
Further reading
Read the Visible focus Guide to make a keyboard customer’s location easily identifiable.
Examples of experiences
Read the Visible focus Guide to make a keyboard customer’s location easily identifiable.