diff --git a/redirects.yaml b/redirects.yaml index 6905f371b..b4e19ee2c 100644 --- a/redirects.yaml +++ b/redirects.yaml @@ -11,6 +11,7 @@ /docs/base/separators: /docs/patterns/rule /docs/base/paper: /docs/base/themes /contribute: /docs/contribute +/accessibility: /docs/accessibility # redirects based on class names /docs/patterns/code-snippet: /docs/base/code diff --git a/side-navigation.yaml b/side-navigation.yaml index ec3d3dd25..dd26c9443 100644 --- a/side-navigation.yaml +++ b/side-navigation.yaml @@ -243,6 +243,8 @@ - heading: Resources ordering: alphabetical subheadings: + - title: Check accessibility + url: /docs/accessibility - title: Component examples url: /docs/examples - title: Release notes for {version} diff --git a/templates/_layouts/docs.html b/templates/_layouts/docs.html index 3103e2922..d476f357e 100644 --- a/templates/_layouts/docs.html +++ b/templates/_layouts/docs.html @@ -135,5 +135,6 @@

On this page:

+ {% endblock %} diff --git a/templates/accessibility.html b/templates/accessibility.html deleted file mode 100644 index 0b14a85f8..000000000 --- a/templates/accessibility.html +++ /dev/null @@ -1,139 +0,0 @@ -{% extends "_layouts/site.html" %} - -{% block title %}Accessibility guidelines{% endblock %} -{% block description %}Vanilla Framework accessibility guidelines{% endblock %} -{% block copydoc %}https://docs.google.com/document/d/1_cCvuHSwS9i0pzD_4WHDFoTenVAfZVr9qGxG-rSHHGY/edit{% endblock %} - -{% block content %} -
-
-
-

Accessibility guidelines

-

Vanilla Framework aims for Level AA conformance with the
Web Content Accessibility Guidelines (WCAG) 2.2

-
-
-
- -
-
-
- -
-
-
-

Ensuring conformance

-

We use the following tools to continually audit the framework:

-
-
-

Accessibility report tool

-

A checklist that can be filtered by A / AA level, with a short description and links to the related "Understanding" and "How to Meet" articles that accompany each criterion.

-

WAI-ARIA Authoring Practices Guide

-

- WAI-ARIA A guide for understanding how to use WAI-ARIA 1.1 to create an accessible Rich Internet Application. It provides guidance on the appropriate application of WAI-ARIA, describes recommended WAI-ARIA usage patterns, and explains concepts behind them.

-

The W3 Markup Validation Service

-
-
-
- -
-
-
- -
-
-
-

Curated criteria checklist

-

The scope of the WCAG spec can be overwhelming. We find the following checklist a good starting point if you're new to accessibility:

-
-
-
-
-
- -
-
- -

*Adapted from Accessibility Guidelines checklist and Web Accessibility Checklist

-
-
- -
-
-
- -
-
-
-

Key WCAG documents

-

The volume of information on the WCAG 2.0 website can be disorienting.
We keep the following links handy for quick reference:

-
-
-
- -
-
- -
-
- -
-
-
- -
-
-
-

Useful tools

-

The web is abundant in tools that help to create and test for accessible sites. We find the following particularly useful:

-
- -
-
- -
-
-
- -
-
-

Noticed an issue?

-

If you spot an accessibility problem in Vanilla, let us know
by filing an issue on GitHub.

-
-
-{% endblock %} diff --git a/templates/docs/accessibility.md b/templates/docs/accessibility.md new file mode 100644 index 000000000..3075fd3f5 --- /dev/null +++ b/templates/docs/accessibility.md @@ -0,0 +1,477 @@ +--- +wrapper_template: '_layouts/docs.html' +context: + title: Check your web interface for accessibility +--- + +This guide will help you address common accessibility pitfalls in web applications and content websites. + +We aim to comply with the [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), level AA. WCAG has been adopted as the standard for accessibility legislation around the world. + + +## Why accessibility is important + +Designing and coding for accessibility helps everyone. People with disabilities or age-related challenges that affect seeing, hearing, moving, speaking, or understanding information need accessible design. But disabilities can also be temporary or situational, like having an injury, being in a noisy place, or dealing with glare. + +The Web Content Accessibility Guidelines (WCAG) ensure that interfaces are [perceivable, operable, understandable and robust](https://www.w3.org/WAI/WCAG22/Understanding/intro#understanding-the-four-principles-of-accessibility). + + +## When using Vanilla + +Components, styles and documentation for Vanilla are written with accessibility in mind, but do not guarantee an accessible experience for your website or web application. + +When you use Vanilla, check the Accessibility tab in each component's documentation. We also suggest that you check the code examples, which follow best practices. + +Whether you are using Vanilla or not, make sure to use correct HTML markup and semantics to make the most of browsers' built-in accessibility features. + + +## Automated tools + +Automated tools can identify many issues with markup and styles. However, they are not sufficient for conducting a comprehensive accessibility audit. Use them mindfully, and do rely as well on manual reviews. + +Here are some tools that may help you: + +- **Online validators**: for an initial assessment, you may use tools such as [WAVE](https://wave.webaim.org/) and [PageSpeed Insights](https://pagespeed.web.dev/), or Lighthouse within Google Chrome's developer tools. Note that [a score of 100 doesn't mean your page is accessible](https://savvasstephanides.hashnode.dev/my-lighthouse-accessibility-score-is-100-does-that-mean-my-website-is-100-accessible). +- **Browser extensions**: + * [Axe DevTools browser extension](https://www.deque.com/axe/browser-extensions/) can scan any given page for accessibility issues, providing guidance on how to fix them. Paid version also provides guided tests and testing full flows. + * [WAVE browser extension](https://wave.webaim.org/extension/): flags issues but also lets you visually check the accessibility tree, focus order and labels. +- **Code editor linters**: check [Axe Linter for Visual Studio Code](https://www.deque.com/axe/devtools/linter/) +- **CLI tools**: [Pa11y](https://pa11y.org/) and [Axe](https://www.npmjs.com/package/@axe-core/cli) offer similar functionality by detecting issues. Both can be used for continuous integration (check also [axe Linter GitHub action](https://github.com/marketplace/axe-linter)) + + +## Check visual accessibility + +These checks support people with low vision (cataracts), color vision deficiencies (color blindness), photosensitivity, or reading difficulties by ensuring clear contrast, readable text at any size, no reliance on color alone, and safe, non-distracting visuals. + + +### Enable the visual features + + +
+
+
+ +
+
+ +
+
+ +
+
+ +
+
+
High contrast mode
+
Go to Settings > Accessibility > Seeing, enable High Contrast.
+
You can also enable High Contrast in the Accessibility menu.
+
Dark theme
+
Go to Settings > Appearance > Style, select Dark.
+
Large text
+
Go to Settings > Accessibility > Seeing, enable Large Text.
+
You can also enable Large Text in the Accessibility menu.
+
Reduced motion
+
Go to Settings > Accessibility > Seeing, disable Animation Effects.
+
+
+ + + + +
+ + +### Visual accessibility checklist + +- All elements are visible and all text is legible in all themes + * If your framework supports dark theme or high contrast mode, check all possible combinations. +- All text wraps instead of overflowing/cropping when enabling large text mode +- All text wraps instead of overflowing/cropping when zooming 200% +- All text wraps instead of overflowing/cropping when the window is resized +- Meaning is conveyed through text or icons, not by color alone. + * For example: for errors, an error message is shown in addition to a red border. +- Animations are disabled or reduced when reduced motion is enabled in the system settings + * Large positional shifts, parallax scrolling, sliding panels, carousels, rotating spinners, or auto-playing loops are problematic and should be disabled. + * Subtle opacity fades, color changes, shadows, or small local micro-interactions are OK. + * Use CSS's `prefers-reduced-motion` to honour system settings. +- No flashing (there should not be more than 3 flashes per second) +- All elements have enough contrast with their background + * Read [contrast checks](#contrast-checks) for further guidance. + + +### Contrast checks + +Default styles from Vanilla already provide sufficient contrast out of the box, but you should double check elements have enough color contrast so all content is perceivable: + +- For text: 4.5:1 or higher contrast with background +- For everything else (for instance, icons on background): 3:1 or higher contrast with background + +No minimum contrast is required for inactive components, decorative images or graphics, or logos. + +You should be particularly cautious in the following cases: + +- Check how any local style overrides affect states like hover or focus +- Check light colors, such as light gray for secondary text or yellow +- Check semantic colors for text, such as red for errors or yellow for warnings +- Check how colors change on light and dark theme, and high contrast mode + +For checking color contrast: + +- On most browsers, including [Firefox](https://css-irl.info/testing-colour-accessibility-with-dev-tools/) and [Chrome](https://developer.chrome.com/docs/devtools/accessibility/contrast), you can check contrast ratio by inspecting an element and clicking on the colour swatch next to the CSS value. Remember we are aiming at level AA at least. +- Install a checker, such as [Kontrast](https://snapcraft.io/kontrast) or [Contrast](https://flathub.org/en/apps/org.gnome.design.Contrast) in Ubuntu, and pick the foreground and background colors. + +Be mindful of text on images, and the use of transparency: some automatic tests may evaluate contrast incorrectly in those cases. Common sense may help flag up problems too: if text looks unreadable to you, it's not accessible no matter what the contrast checker says. + + +## Check keyboard navigation + +These checks ensure a good experience for keyboard-only users, including people with motor disabilities that cannot use a mouse or trackpad, blind users who rely on screen readers, and power users who just prefer to use their keyboard. + + +### Try keyboard shortcuts + +For a simple test, select the window you want to test. Then hit the Tab key repeatedly and check how focus moves through all interactive elements. + +For a more thorough test, you need these shortcuts: + +| Action | Shortcut | +|--------|----------| +| Move to next interactive item | Tab | +| Move to previous interactive item | Shift+Tab | +| Interact with an item or group | Enter | +| Exit a group | Esc | + + +### Keyboard navigation checklist + +- All interactive elements (for example, buttons, fields, links) can be focused using the Tab key +- All interactive elements have a visible focus state (ideally a focus ring) +- There are no focus traps: it is possible to escape all loops, for instance by pressing the Esc key +- Focus moves from one element to the next in a logical order + * In most of our apps, that usually means sidebar (if open), then body; and top to bottom, left to right (or right to left for RTL languages such as Arabic or Hebrew). +- A skip link is provided at the beginning of the page to bypass navigation + - Check [skip link](/docs/patterns/links#skip-link) in Vanilla +- When a dialog opens, focus moves to the dialog +- When a dialog closes, focus moves back to the element that triggered the dialog +- Dialogs close by hitting the Escape key +- If an element doesn't have a visible label but does have a tooltip on hover, the tooltip should also be visible on focus + + +## Check screen reading + +All graphical interfaces should be readable with common screen readers. Screen readers benefit blind and visually impaired users who rely on audio feedback to navigate interfaces. To work properly, screen readers require good markup, labelling, and logical content structure. + + +### Use the screen reader + +
+
+
+ +
+
+ +
+
+ +
+
+ +
+

Orca is the default screen reader in Ubuntu Desktop and other Linux distributions. It can be enabled in Settings > Accessibility > Seeing. You can also enable Screen Reader in the Accessibility menu.

+ +

Note that some Orca features don't work with certain combinations of Ubuntu releases and application toolkits. Read Improve screen reader usability.

+ +

You need to become familiar with keyboard shortcuts to use the screen reader. Modifier keys are used in the shortcuts:

+ +
+
Super
+
Generally mapped to the Windows key on Windows computers, and the Command key on Macs.
+
Orca
+
By default, the Orca key is CapsLock for the Laptop layout, and the Insert key for the Desktop layout. You can set the layout in the Orca settings by typing orca -s in the terminal.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ActionLaptop layoutDesktop layout
Enable screen readerSuper+Alt+SSuper+Alt+S
Quit screen readerSuper+Alt+SSuper+Alt+S
Learn modeOrca+H (exit with Esc)Insert+H (exit with Esc)
Orca preferencesCapsLock+SpaceInsert+Space
Toggle [flat review](https://documentation.ubuntu.com/desktop/en/latest/how-to/accessibility/orca/navigate-the-screen-using-the-screen-reader/#examine-a-window)CapsLock+PInsert+- on the numeric keypad
Say all (in flat review)CapsLock and double-press ;Double-press + on the numeric keypad
Read current lineCapsLock+I8 on the numeric keypad
Read next lineCapsLock+O9 on the numeric keypad
Read previous lineCapsLock+U7 on the numeric keypad
+ +

You can find further guidance in the screen reader documentation.

+
+ + + + + + +### Screen reading checklist + +- All interactive elements (buttons, fields, links…) have a label and a role that is read out loud by the screen reader + * Use the right HTML elements so screen readers can rely on their implied roles. Check [W3C documentation on roles](https://www.w3.org/WAI/ARIA/apg/practices/structural-roles/). + * You may use the [off-screen Vanilla utility](/docs/utilities/off-screen) (`.u-off-screen`) to make a label readable only for screen reader. +- The HTML document has an appropriate `lang` attribute on the root element (e.g., ``) +- HTML5 semantic elements (`
`, `