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”
  • 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 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 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 2
    • 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] 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.

  1. 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.
  2. Looping focus within open modals/popovers
  3. Tabs keyboard support, panel behaviour
  4. 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.

Similar Posts