Skip to main content
live This is a new website – your feedback will help us to improve it.

Standards and Accessibility

Overview

As a public body, BAS has a responsibility to make its content available to as many people as possible.

Browser support

In general, the BAS Style Kit aims to support all browsers supported by Bootstrap. This means the latest, stable, releases of all major browsers, subject to any caveats below.

To reduce compatibility errors with Internet Explorer, the X-UA-Compatible header should be used to select the latest standards mode.

<meta http-equiv="x-ua-compatible" content="IE=edge">

Heads up! The Style Kit currently supports Internet Explorer 11. In the future it will only support Microsoft Edge.

HTML5

The BAS Style Kit uses the HTML5 document type. This is supported by all major browsers and includes elements, attributes and technologies to provide better accessibility and progressive web applications.

CSS3

The Style Kit uses CSS3 CSS standard with browser prefixing where needed.

Responsiveness and Mobile First

The Style Kit uses a mobile first design, which assumes pages will be viewed on small devices (i.e. mobile phones) and then scales up to larger sizes. This is also known as responsive design.

Responsiveness is enabled in the Style Kit using the viewport meta tag, as shown below:

<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">

Examples of how content can change between sizes include:

  • increasing the size of fonts and images
  • organising content into grid columns to make better use of space
  • minimising or hiding navigation menus at smaller sizes

See the responsive breakpoints section for more information.

Colour contrast

The colour contrast for text and any interactive elements should be at least 4:5:1, as recommended by the Government Digital Service and W3C.

Providing context

Conveying context without colours or icons

Colours or icons should not be used alone to indicate the meaning or context of an action or notice. This information is inaccessible to, amongst others, some colour-blind users or those using assistive technologies – such as screen readers.

Instead, context should be either obvious from the content itself, or included in an additional content using the .bsk-sr-only class.

Ideally contextual colours and icons should only be needed for reinforcing meaning that is already present in text or other markup.

Where a link (<a>) element is used as a button to trigger in-page functionality, such as to collapse content, make sure to add role="button" to provide suitable context to assistive technologies.

Where a button (whether an actual button or a link element styled as such) uses the .bsk-active state, add aria-pressed="true" as well to convey this context to assistive technologies.

Contextual help text

Where text is used to explain something on screen, for example a form field or the result of a calculation, an explicit link should be made between this text and the element.

Sighted readers will be able to infer such a link using visual cues (such as placement next to the relevant element), however this will be invisible to those using assistive technologies, such as screen readers.

For context applicable to all users, adding a aria-describedby attribute is usually enough. For context intended specifically for assistive technologies, such as to explain how items are arranged on screen, use the .bsk-sr-only.

See the form help text section for an example.

Validation stages

When displaying validation information, usually in the context of a user filling out a form, care should be taken not to rely on colours or icons only to provide context.

Clearly stating the reason for a validation failure or warning, with contextual colours and icons, will work best for all users.

Where possible, validation feedback should include how the user can correct their mistake, for example by enumerating valid options if there are a limited number. For forms, the aria-invalid attribute should be equal to true if a field is invalid.

See the form validation section for an example.

Skip navigation context and roles

Pages with large numbers of navigation links, such as a navbar, should include a link to skip to the page content. This link can be hidden to non-screen readers using the .bsk-sr-only class, and requires a page structure such as this:

<body>
  <a href="#site-content" class="sr-only sr-only-focusable">Skip to main content</a>
  ...
  <div class="container" id="site-content" tabindex="-1">
    <!-- main content -->
  </div>
</body>

For more information, see this article from the A11Y Project.

Due to browser bugs, the target of the skip navigation link must set the tabindex attribute to -1 to work correctly.

As a side effect of using the tabindex workaround recommended above, it is necessary to disable the outline that shows on interactive elements due to the browser inferring anything with a tab index is also interactive, which is not the case for elements such as <body>. The Style Kit disables this outline automatically on the <body> element, this just explains why we do so.

Useful resources

These resources provide additional general, or specific, guidance: