Accessibility

The Framework is built with accessibility in mind and it is regularly checked to ensure that the components offered for use as the best they can be for all our customers. Before any code is released for use it is scanned using AXE to test for compliance with the WCAG guidelines as well as best practices. There are some AXE rules that have been adjusted in order to not flag known false positives on every scan. These are documented below along with reasoning as to why they are required.

Colour contrast

Relevant rule: color-contrast

Selected checkboxes and radios

Due to the styling techniques used to enable animations as the inputs become checked/unchecked, AXE is unable to correctly check the colour contrast between the text colour and the element being used to provide the background colour. The rule has been disabled for selected inputs only.

Disabled form row

Disabled form rows are deliberately faded out, so will not pass colour contrast checks. It is advised that disabled form rows/inputs are avoided and alternative means of playing back non-editable content is used, for example data replay, so that the content is still read out by a screen reader.

Since the content is not read by screen readers, we have accepted having lower contrast on the disabled form row.

Disabled buttons

Since the content is not read by screen readers we have accepted having lower contrast on the disabled buttons.

Visible labels on form row groups

The individual labels used above each input field within a form row group have a lower contrast. These labels are meant to serve as an addition hint as to what each form field should contain, but the fieldset legend and any help text for the form row group should make it clear what is required of the user.

Aria use on inputs

Relevant rule: aria-allowed-attr

Within components such as progressive disclosure, aria attributes such as aria-controls have been used to connect up inputs to associated areas. This is currently prohibited by the W3C spec for use of Aria for these element types, however the conclusion from extensive research has been to allow use of Aria in these use cases as it does not detrementally affect assitive technology users in any way and can help them. This mirrors the conclusion independently reached by gov.uk - see the discussion and conclusion on github for further details.

Radiogroup

Relevant rule: radiogroup

Fieldsets for radio groups should not contain any other inputs that are not part of that group of radios. This includes button elements with type of button.

This rule has been disabled for the following components:

• Single and multicard selects

  If the selection groups are carouselled, the buttons used to paginate the carousel cause validation errors.

• Preferred contact

  Although this component breaks the rule, having the radio selections completely separate from the phone number inputs would make the contact entry much harder to understand.

• Wallet

  When selecting which saved card to use, some cards may require entry of the CVV number; in order to maintain the link between the radio selection and its associated input ie. CCV number input, it is much clearer to have the input directly connected to the radio input.

Heading order

Relevant rule: heading-order

This rule has been temporarily disabled as it apears to flag a number of false positives which are unable to be pinned down to specific scenarios. This rule should be followed at all times, however it will not form part of the automated scanning at this time.

Unique landmarks

Relevant rule: landmark-unique

Ensure each Highchart chart has a unique title by setting it using the language settings when setting up the chart, for example:

Highcharts.chart( chartID, {
	...
	lang : {
		accessibility : {
			chartContainerLabel : '...',
		},
	},
});

Some other elements of Highcharts will not be unique, so this rule has been turned off for Highcharts elements only.