---
title: Accessibility audit of Vanilla framework
description: The team behind the Vanilla Framework has a background in development,
  UX and Visual Design. We all care about accessibility, but none of us is an accessibility
  expert. We were interested in evaluating how well the framework complies with accessibility
  standards. We decided to start with an internal audit, fix any issues we find, then  […]
url: https://canonical.com/blog/accessibility-audit-of-vanilla-framework?format=md
---

1. [Blog](https://canonical.com/blog)
2. Article

---

[Lyubomir Popov](https://canonical.com/blog/author/lyubomir-popov "More about Lyubomir Popov")

3 November 2020

# Accessibility audit of Vanilla framework

[accessibility](https://canonical.com/blog/tag/accessibility)
[Design](https://canonical.com/blog/tag/design)
[Vanilla](https://canonical.com/blog/tag/vanilla)

---

Share the article

The team behind the [Vanilla Framework](https://vanillaframework.io/) has a background in development, UX and Visual Design. We all care about accessibility, but none of us is an accessibility expert.

We were interested in evaluating how well the framework complies with accessibility standards. We decided to start with an internal audit, fix any issues we find, then look for a third-party service to evaluate the framework from the perspective of real-world users with disabilities

## Scope

For the internal audit, we focused on 3 aspects:

* Identifying and fixing issues using the [WCAG-EM Website Accessibility Evaluation Report Generator](https://www.w3.org/WAI/eval/report-tool/#!/evaluation/audit#%2F). A list of the results can be found in our [accessibility report results document.](https://docs.google.com/spreadsheets/d/1xNo8YFnrHwndgqrmvCRpCN3Zvi6SCyQT4FoUKzTsyNA/edit#gid=0)
* Identifying and fixing [validator](https://validator.w3.org/nu/) issues
* Going through a [component level checklist](https://www.w3.org/TR/wai-aria-practices/). Identifying and fixing issues

## Level A and AA fixes

We conducted a site-wide audit using the [WCAG-EM Report Tool](https://www.w3.org/WAI/eval/report-tool/#!/evaluation/audit) filtered by level A and AA. Here are some highlights:

* darker `:link` colour, allowing us to meet the required contrast ratio not only against white but on lightly tinted backgrounds like the ones used in some hover, active and selected states
* `:visited` colour now meeting the 3:1 contrast ratio against `:link` colour
* the contrast between text and link states now satisfies the 3:1 contrast requirement
* borders of interactive elements now satisfy 3:1 contrast ratio requirement
* A few markup omissions, e.g. some missing `aria-labels`, `aria roles`, `for` attributes on some labels, `name` attribute on some submittable button examples

## Compliance with WAI-ARIA Authoring Practices 1.1 spec

All components were compared to the [WAI-ARIA Authoring Practices 1.1 spec](https://www.w3.org/TR/wai-aria-practices/). We implemented all fixes that do not cause a breaking change or require extensive JS for keyboard support.

##### **Some highlights:**

* Implemented region landmarks in docs and application layouts
  + `<header>` tag to wrap main navigation and other heather content
  + `<main>`  tag wrapping main application content
  + `<footer>` tag wrapping any footer content
  + `<aside>` tags wrapping any overlay panels that are not part of `<main>`
* Fixed accordion component roles. Further work required to fix the markup structure, as discussed below.
  + Remove incorrect `role=”tablist”`, `role=”tab”`, `role=”tabpanel”`
* Fixed tree component roles:
  + `role=”tree”` on the root `ul`
  + `role=”treeitem”` on any list item without children
  + `role=”group”`

* Added `role=”alert”` to validation error messages

* Add `role=”status”` to the notification component

* Fixed breadcrumb structure
  + Wrapped the component in a `nav` element
  + Added `aria-label` to distinguish from other nav landmarks on the page
  + Converted the `ul` to `ol` to signify the order of the breadcrumb
* [Added](https://github.com/canonical-web-and-design/vanilla-squad/issues/867) `autocomplete` attributes to all form examples asking users for information
* Added `aria-labels` to all nav elements
  + Often there are more than one `nav` element on a page and they rarely (if ever) have labels. It is important to add `aria-label` attributes to distinguish between them e.g. the main site navigation from a breadcrumb to a footer navigation
* Removed aria roles that make false promises – e.g.:
  + `role=”grid”` which we had on many tables, means we have to implement a lot of [keyboard support](https://www.w3.org/TR/wai-aria-practices/#keyboard-interaction-for-data-grids) to allow moving up/down/left/right, first/last with Ctrl+Home/End with the keyboard, etc.
  + `role=”menu”` doesn’t apply to most site menus (with the potential exception of the hamburger menu). [Source 1](https://www.smashingmagazine.com/2017/11/building-accessible-menu-systems/), [source 2](https://adrianroselli.com/2017/10/dont-use-aria-menu-roles-for-site-nav.html)
  + `role=”menu”` does not apply to most menus on sites with the potential exception of the hamburger menu. This may sound surprising, but for example, true ARIA menus need to support Sh+F10 on Windows as a right-click etc. [discussion and source articles [here](https://github.com/canonical-web-and-design/vanilla-framework/issues/3225)] [Source 1](https://www.smashingmagazine.com/2017/11/building-accessible-menu-systems/), [source 2](https://adrianroselli.com/2017/10/dont-use-aria-menu-roles-for-site-nav.html).

## Fixes to issues identified using the HTML validator

All Vanilla example pages were passed through a validator to identify misuse of ARIA attributes, missing or invalid attribute values, typos and missing closing tags.

* Fixed usage of aria-labels instead of aria-roles e.g. `submenu`
* Added `name` attribute to elements intended for form submission
* Ensured all checkboxes and radios are labelled
* Removed redundant roles from native elements, e.g. `role=”contentinfo”` from `<footer>`
* Removed instances of `action=””` and other empty attributes as they trigger validator errors

## Further work

We have a few things left to fully resolve the issues we found. These have not been done yet as they require javascript, and we try to keep javascript to a minimum within examples.

1. The [inverted link pattern](https://vanillaframework.io/docs/patterns/links#inverted) does not meet a key requirement – a minimum of 3:1 contrast with adjacent text. We need to decide how we want to resolve this, so it has been left out for now.
2. [Looping focus within open modals/popovers](https://github.com/canonical-web-and-design/vanilla-framework/issues/3223)
3. Tabs keyboard support, panel behaviour
4. [Accordion markup structure](https://github.com/canonical-web-and-design/vanilla-framework/issues/3318) – the accordion markup is currently in reverse order, having headings or plain text inside buttons. We need to deprecate this and replace it with buttons inside headings, now list item wrappers. This could be a breaking change so we need to think of the most elegant way to do this without breaking existing accordions in production.

We’ll update the blog post once we resolve the last remaining issues.

Conducting this accessibility audit was a challenging and time-consuming process, particularly because none of us are experts in accessibility. We were able to identify and fix many issues and improve the framework’s accessibility that will positively impact our websites.

We view this cleanup exercise as a preparatory step. Next, we plan to work with a dedicated accessibility consultancy to make sure we haven’t missed anything, to test with users with real disabilities, and to evaluate our sites using assistive technologies.

[Get in touch

Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form)

## Sign up for our newsletter

Get the latest Canonical news and updates in your inbox.

Work email:

\*I agree to receive information about Canonical's
products and services.

By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy).

Sign up

## Share on

---

## Related posts

[### Vanilla 4.0 release](https://canonical.com/blog/vanilla-4-0-release)

Last week we released a new major version of the Vanilla framework. Vanilla 4.0 introduces the elements of the new style used for a current rebranding of Canonical’s brochure...

[Bartek Szopka](https://canonical.com/blog/author/bartoszopka)

18 July 2023

[### Challenges designers face in open source (and how to fix them)](https://canonical.com/blog/challenges-designers-face-in-open-source-and-how-to-fix-them)

Open source powers up to 90% of modern software, yet many projects lack usability. Canonical’s Design team surveyed 115 cross-functional professionals to uncover the 4 core...

[Kola Ojoodide](https://canonical.com/blog/author/kola-ojoodide)

26 June 2026

[### Why web engineering is great](https://canonical.com/blog/why-web-engineering-is-great)

Hi, I’m Johann! I’m an engineering manager in Canonical’s web team. For the larger part of my 15 years of work experience as engineer, I’ve been working in web development....

[Johann Wolf](https://canonical.com/blog/author/johannwolf)

27 April 2026

[### Canonical’s recipe for High Performance Computing](https://canonical.com/blog/canonicals-recipe-for-high-performance-computing)

In essence, High Performance Computing (HPC) is quite simple. Speed and scale. In practice, the concept is quite complex and hard to achieve. It is not dissimilar to what...

[Igor Ljubuncic](https://canonical.com/blog/author/igorljubuncic)

24 January 2024