Accessibility audit of Vanilla framework
Lyubomir Popov
on 3 November 2020
Tags: accessibility , Design , Vanilla
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 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. A list of the results can be found in our accessibility report results document.
- Identifying and fixing validator issues
- Going through a component level checklist. Identifying and fixing issues
Level A and AA fixes
We conducted a site-wide audit using the WCAG-EM Report Tool 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. 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”
- Remove incorrect
- Fixed tree component roles:
role=”tree”
on the rootul
role=”treeitem”
on any list item without childrenrole=”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
tool
to signify the order of the breadcrumb
- Wrapped the component in a
- Added
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 addaria-label
attributes to distinguish between them e.g. the main site navigation from a breadcrumb to a footer navigation
- Often there are more than one
- 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 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, source 2role=”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] Source 1, source 2.
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.
- The inverted link pattern 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.
- Looping focus within open modals/popovers
- Tabs keyboard support, panel behaviour
- Accordion markup structure – 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.
Talk to us today
Interested in running Ubuntu in your organisation?
Newsletter signup
Related posts
Designing Canonical’s Figma libraries for performance and structure
How Canonical’s Design team rebuilt their Figma libraries, with practical guidelines on structure, performance, and maintenance processes.
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...
How we implemented an interactive Live Demo Box
The Vanilla squad recently spent a two week sprint prototyping an interactive live demo box. We were tasked with coming up with a proof of concept, to enable...