Accessibility Checklist
In Figma, this page is a component for designers to insert into their document to review their designs before passing over to development.
Colour
Ensure that colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
Use a tool to check contrast ratio for text and UI elements (including icons, buttons, inputs, etc.). All components and graphics must have the correct contrast ratio, unless they are purely decorative.Please note: Only Accessible Gradients can be used in typography, and only with the font style Display-5 or larger.
For links within paragraphs of text, it is preferred to use an underline along with Primary Blue, to visually identify the element as a link. See Text Links for more details how these are typically styled.
Use a colour vision deficiency simulator (for example, the Stark Figma Plugin) to check whether your design could cause issues to users with varying types of colour blindness. Another way to check this is using the luminosity blend mode in Figma, where everything is shown in grey scale. The aim is for interactive elements to stand out even without the colour.
Typography
Ensure the page/screen has a unique heading (H1) that describes the purpose of the page and appears before all other content (may be hidden if necessary).
All copy should use the Typography styles set out by Sky UI. Ensure all heading levels, paragraphs and block quotes use a defined typography style. This includes labelling any hidden headings.
Headings must describe the topic or purpose of the section below. Provide strong hierarchy and content structure. This helps assistive technologies users navigate to relevant sections of content like a folder structure. Page titles can also be used for H1s.
Essential text must not be presented as part of an image, which cannot be read by a screen reader or resized when magnified. If this cannot be avoided, provide written alt text that properly describes the content.
Layout and navigation
Ensure reading and navigation order are logical and intuitive. In Western cultures, people typically read left-to-right and top-to-bottom. Contextual content should precede any related CTAs or actions. This order will be maintained for those accessing the page with CSS styling disabled or listening to it with a screen reader.
Complex tables should be simplified to minimise or eliminate the need for merged columns or merged row headers. If the page contains a data table, the table needs a caption (name/title). For more information on accessible tables, see the Accessibility & Handover page on the Comparison Table component.
If navigation is repeated across multiple pages, it must be presented in a consistent manner. Consistency will make easy to learn how to navigate, and use screen reader shortcuts.
All navigational elements need a unique state for default, hover, active, and focus. See interactive Sky UI components for how focus states are typically handled.
All notifications and messages should be easily discoverable by all users (e.g. close to triggering element and also conveyed to screenreader users).
Text links & Buttons
Text Links and Buttons typically have different purposes, and whist a developer can change this in the code, in general (with possible exceptions) it’s better if you still follow the expected behaviours of both:
- A link will trigger a URL change or move the focus to a different element. For example, “Skip to main content” links
- A button will trigger an action (exception for highlighted CTAs)
Link texts and buttons must clearly describe the purpose or destination of the link.Read more about Button copy guidelines if you’re unsure.
Ensure every link or button has sufficient contrast from the background.If you’re using Sky UI’s Text Links and Buttons then you only have to make sure the background has suitable contrast when using the Text Link.
Make sure you keep to the minimum target sizes for clickable elements (24x24px on desktop), and tappable elements (44x44px on iOS and 48x48px on Android).There are exceptions when interactive elements can be smaller -
- There is another target on the same page that is at least the minimum size and provides the same function.
- The target is part of a sentence or block of text.
Forms
All form labels must be adequately descriptive and instructive.All controls must be in close proximity to the content they impact. E.g., Edit and Delete buttons should be next to the content they modify.Read more about Form Fields if you’re unsure.
Make sure you are communicating to all users on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors.Error messages provide enough information for users to correct the error.Read more about Validation if you’re unsure.
Instead of disabling form submit Buttons until the user has entered valid/expected data, it is recommended to let the user attempt submission and provide explicit feedback in response. This mitigates any potential accessibility issues that come with disabled Buttons, and allows the user to see the issues they need to amend before proceeding.
Make sure the purpose of each interactive element is clear e.g. no nested interactive elements, such as a button inside an input field, or checkbox within another button or within a clickable card.
Development Handover
Allow text size to increase by up to 400% (the zoom property must be enabled in browsers). Check that the copy and functionality flows at a larger size and is not constrained by a fixed-width or fixed-height layout without requiring scrolling in two dimensions.
Make sure you’re not creating a page only suitable for one view port size. Test your layout across a few different sizes and orientation of view ports, especially if you’re creating new components.
- Define alt text for all functional (aka non-decorative) images. See Sky UI’s guide to writing Alt Text for more info.
- Mark all decorative images and elements as requiring null alternative text.
- Define alt text for actionable elements that describes the purpose of the element (e.g. ‘Close modal’ an Icon Button)
Document the focus order for dynamic interactions (e.g. opening a modal/error messaging).
Document heading levels in correct hierarchical order, with one H1, and no heading levels skipped to represent content structure.
Use common landmarks such as <main>, <header>, <footer>, and <nav> to define the essential semantic structure of a page. All page components must be contained in landmarks. For development handoff, you can use the Stark Figma Plugin to indicate landmarks or mark them manually.
Ensure it is clear how custom styled text should be communicated to screen reader users.Custom styled text might need additional aria notes, e.g. a strikethrough price should be read out as "was xx£, now xx£".
Additional resources
Stark Figma Plugin - To run further checks on your designs.
Accessibility personas - For specific accessibility use cases to consider.