At a glance
Salsa built our new website using , the Victorian Design System, as our base and customised the code to fit our needs. We realised that we needed to perform an independent assessment to ensure that we’re building sites and platforms with accessibility at the forefront and to live up to our core values of rigour, accountability and personal growth.
Using Ripple (which is WCAG 2.0 AA compliant) as the base for the new Salsa Digital site, uplifting the codebase to WCAG 2.1 compliance, and contributing the code back for others to use.
Determined how compliant our site is against international accessibility standards
Provided opportunity to contribute more compliant code to the Victorian government
Illustrated opportunities for Salsa to learn more about accessibility best practices
Challenge — auditing the accessibility of the new Salsa website
The new Salsa website launched in September 2020. The goal was to update our branding and our market position. The site was built on , which is a digital platform for unified digital services across the Victorian Government. in 2018 to create SDP, which includes Tide (a Drupal content management system) and Ripple (the frontend presentation layer).
The Salsa website is built on SDP because it:
Is open source
Is heavily validated and researched
Is part of the Salsa culture
Gives us an opportunity to give back to the Drupal and government communities
Although Ripple, the design system for SDP, already passes most of WCAG 2.0 AA standards, we needed to ensure that our configuration didn’t violate any standards and wanted to ensure that all WCAG 2.0 AA standards are still being met in Ripple. We also wanted to commit to a higher standard of accessibility (WCAG 2.1 AA) — one that would allow us to make our site accessible for low- and no-vision disabilities, low- and no-auditory disabilities, and motor, dexterity and cognitive disabilities.
Transformation — the accessibility audit process and next steps
We evaluated the website against the 38 WCAG 2.0 AA standards and the 50 WCAG 2.1 AA standards. Other Salsarians provided guidance on which pages to test based on unique components and unique content, such as tables. It wasn’t necessary to test every page of the site, as this is both time-consuming and redundant, but we did want to test all of the reusable components and different types of content, such as tables.
During the audit, we wanted to cover all forms of testing — manual and automated. Although there are many automated testing tools on the market, they only uncover roughly 15-25% of the issues on a site, and we wanted to do more than the bare minimum. We want to practice what we preach and follow best practices for accessibility testing and provide an inclusive environment for our users.
During our testing, we used the Accessible Name & Description Inspector () tool, which is an open source tool created by the Accessible Solutions Branch of the Social Security Administration in the United States. We also used The Paciello Group’s to further test colour contrast. While this additional testing does not guarantee that we found all issues on the site, we were able to find many more issues than automated tests only. We also performed manual testing via keyboard, via visual inspection and via , Apple’s screen reader.
We then documented all of the results in an extensive accessibility report that the team can reference. The Salsa website development team reviewed the report together and the team has started placing the violations into our defect tracking system and prioritising the tickets. We have had several meetings with DPC about the violations that were not related to Salsa website-specific customisations and the associated remediation steps, and we’ll be contributing our findings back to Ripple.
Once we have fixed each of the violations, we’ll conduct another quick accessibility audit of the site to verify that the errors identified during the first round of testing are fixed and to verify that no new errors were introduced. It’s not uncommon to have to regularly review a site or platform for accessibility, as code changes can easily affect multiple components. Making a site or platform accessible is always evolving and is never truly 100% complete.
To present Salsa’s accessibility expertise and commitment to accessibility, the team will be releasing Insights on accessibility principles and how we plan to become more integrated into the accessibility community.
Outcomes of the WCAG 2.1 AA accessibility audit
The (WCAG) are a series of web accessibility standards published by the Web Accessibility Initiative (WAI) of the (W3C), the main international standards organisation for the internet. There are three levels in the WCAG:
Level A: This involves the smallest amount of implementation effort and has the lowest impact on the presentation and business logic on your site.
Level AA: This has a high impact for users and makes a higher impact on the system’s presentation and business logic. Most businesses choose to focus on Level AA.
Level AAA: These changes are usually for specific user populations and can be very difficult to adhere to.
WCAG 2.0 AA - 38 standards
- 10 standards passed
- 13 standards failed
- 14 standards do not apply
- 1 standard partially tested
WCAG 2.1 AA - 50 Standards
- 17 standards passed
- 16 standards failed
- 16 standards do not apply
- 1 standard partially tested
Pass: The site is fully compliant with all tests associated with this standard.
Fail: One or more components or pages on the site failed to comply with one or more tests associated with this standard.
Does not apply: Content or functionality, such as audio, video, and sensory characteristics, do not exist on any pages of the site, so tests cannot be run.
Partially tested: Automated tools do not completely cover the testing criteria for this standard.
These results show that while SDP is mostly compliant, there is some functionality in the platform, as well as in Salsa’s implementation, that needs to be fixed to be compliant. It’s often difficult to be 100% compliant due to differences in how browsers render code and screen readers handle different elements, so our goal is to fix all of the issues we discovered so there is no disruption to the user.
WCAG 2.0 Level AA and WCAG 2.1 Level AA findings
Testing details around testing dates, tools used, and reviewed pages
A summary of findings, which included the number of violation and major violations
Full testing results with the standard, status (pass, fail, does not apply, or partially tested), violation and remediation steps, and user impact
Several usability recommendations
Recommended next steps
We inherited Ripple as our base for the new Salsa website and built on top of it. We wanted to do an individual assessment of our updated code to ensure that we were meeting accessibility guidelines and keeping all users’ experiences front of mind.
We were transparent about the issues we found and are currently working with DPC to contribute code back and we’re working on making updates to what we built on top of Ripple.
After our assessment, and using the approach above, we have renewed our focus on guiding clients and the open-source community in understanding more about accessibility guidelines and principles, and on how to share this knowledge with others.