A brief overview of BootstrapVue's features and limitations for the creation of accessible content.
BootstrapVue will automatically add in the appropriate accessibility markup for most interactive components. But the overall accessibility of any project built with Bootstrap and BootstrapVue depends in large part on the author's markup, additional styling, and scripting they've included. However, provided that these have been implemented correctly, it should be perfectly possible to create websites and applications with BootstrapVue that fulfill WCAG 2.0 (A/AA/AAA), Section 508 and similar accessibility standards and requirements.
BootstrapVue's custom components have been optimized for accessible/semantic generated HTML markup out of the box. This documentation aims to provide developers with best practice examples to demonstrate the use of Bootstrap itself and illustrate appropriate semantic markup, including ways in which potential accessibility concerns can be addressed.
Most component documentation pages include an accessibility section (or sections) noting best practices and limitations.
BootstrapVue's interactive components — such as modal dialogs, dropdown menus and custom tooltips — are designed to work for touch, mouse and keyboard users. Through the use of relevant WAI-ARIA roles and attributes, these components should also be understandable and operable using assistive technologies (such as screen readers).
Most colors that currently make up Bootstrap V4's default palette — used throughout the framework for things such as button variations, alert variations, form validation indicators — lead to insufficient color contrast (below the recommended WCAG 2.0 color contrast ratio of 4.5:1) when used against a light background. Authors will need to manually modify/extend these default colors to ensure adequate color contrast ratios.
Refer to the Theming section for customizing Bootstrap's SCSS.
Content which should be visually hidden, but remain accessible to assistive technologies such as screen readers, can be styled using the
.sr-only class. This can be useful in situations where additional visual information or cues (such as meaning denoted through the use of color) need to also be conveyed to non-visual users.
<p class="text-danger"> <span class="sr-only">Danger: </span> This action is not reversible </p>
For visually hidden interactive controls, such as traditional "skip" links, class
.sr-only can be combined with the
.sr-only-focusable class. This will ensure that the control becomes visible once focused (for sighted keyboard users).
<a class="sr-only sr-only-focusable" href="#content">Skip to main content</a>
Bootstrap includes support for the
prefers-reduced-motion media feature. In browsers/environments that allow the user to specify their preference for reduced motion, most CSS transition effects in Bootstrap (for instance, when a modal dialog is opened or closed, or the sliding animation in carousels) will be disabled.
If you are expecting animations and/or transitions to work and they are not, then you may have the reduced motion (no animation) setting enabled in your operating system control panel.
It is highly recommended to test your app for accessibility before deployment. Note that some countries even have laws requiring all websites to be accessible.
There are just two main things to think about when making your web app accessible:
- Defining the right keyboard behavior. BootstrapVue provides keyboard control for most of our components, but you should make sure your custom components are also keyboard accessible.
- Making it possible for screen readers to understand your app. Bootstrap, in most situations, will automatically set the correct
aria-*attributes on our components. You should also make sure that all of your custom components provide the correct roles and attributes (use semantic HTML elements and markup where possible).
Steps you should do for testing:
- Try using the keyboard only to see if all interactive components can be reached and controlled. Ensure that controls have focus styling so that the user knows which interactive element they are on. Remember, keyboard user cannot trigger an element's
- Use a screen reader (combined with keyboard only) to navigate and interact with your app. There are several free screen readers available for various operating systems and browsers. Remember that screen reader users can only "see" what they hear.
- See how your app looks and works when increasing the zoom level (and/or font size) of your browser.