Dashlane has always been dedicated to providing an accessible web experience and ensuring that all of our customers have access to robust and simple tools to protect their online identities. But what exactly does dedication to accessibility (a11y) on the web entail? And how do we ensure that we maintain our high standards for accessibility? While we work to improve accessibility on all our platforms (web, iOS and Android environments), this blog post specifically dives into more detail around how we approach accessibility across Dashlane on the web.
What does web accessibility mean at Dashlane?
We view accessibility as a commitment to provide all customers access to the same user experience, regardless of how they navigate the web. Oftentimes the first thing that comes to mind with accessibility is providing access to those using assistive technologies such as screen-readers, keyboard-only navigation, or voice-based navigation. Although this is a great starting point, there are many use cases that can go unaccounted for. For instance, we strive to keep our language and word choice across Dashlane products easy to understand, we are conscious of the use of animations for those who may be sensitive to visual motion, and ensure that our color systems keep color-blindness and contrast ratios in mind. From a technical perspective, we aim to adhere to Web Content Accessibility Guidelines (WCAG) and have set goals for meeting certain levels of compliance.
How do we ensure an accessible web application?
The three main ways that we maintain accessibility are within our Tools, our Processes, and our Practices.
Tools for accessibility on the web
As detailed in our Engineering at Dashlane blog post, we utilize TypeScript and React to build our web applications and extensions. One of the benefits of this is that we can, to some extent, incorporate accessibility directly into our development and build tools. One example is eslint-plugin-jsx-a11y which is incorporated across our projects using eslint . This plugin analyzes JSX elements to enforce, either as a warning - or an error, the implementation of things such as:
- Alt–text on elements that support them, such as images, to better label & provide fall-back descriptions to screen-readers
- Valid anchor link content to ensure that the visual display of links matches what a screen-reader would identify
- Requiring
aria-*props - Detecting that all mouse events such as
onClick, oronMouseOverhave an accessible handler for a keyboard equivalent (such asonFocus)
With all new features we add, our jest tests are structured to query elements by role. This relatively small change in how we approach testing can result in large improvements in our a11y adherence.
For instance, when creating a new header on a page, you could write a test like this:
Non-Role-Based-Test
| 1 2 3 | it('Should render the Login page heading', async () => { expect(await screen.findByText("Log In Here!")).toBeInTheDocument();}); |
Which would pass the unit test, but not enforce that the element being tested is a heading as we would expect.
Instead, our code conventions & tools expect that our tests are written as:
Role-Based-Test
| 1 2 3 4 5 6 7 | it('Should render the Login page heading', async () => { expect( screen.getByRole('heading', { name: "Log In Here!", }) ).toBeInTheDocument();}); |
Here we can be confident that not only will our unit test pass for rendering the heading of our Log In page, but that a screen-reader will be able to correctly identify the page's heading and announce it to assistive technologies. Tests like these extend to all areas of our apps & components where we can provide additional assurance that our applications are built with accessibility in mind.
As developers, we also have access to a wide range of tools to evaluate the software we're building, such as the WAVE Web Accessibility Evaluation tool which can analyze web pages to generate accessibility reports that are easily actionable to address & improve issues early on in the development process.
How processes shape our approach to accessibility
Aside from our development guidelines, we have identified and implemented several processes that make maintaining & improving our web experience easier and more automated. When building new features, all of the copy we use can be stored as keys we use to keep track & access the translations within our code. In regards to text that may not be visible, but intended to be read by a screen-reader, we mark them with either _a11y_ or _accessibility_. This process ensures that our UX Writing team is aware of any a11y-specific copy, and are able to provide the proper level of descriptiveness needed to act as an an equal alternative to visual content.
As engineers, within our code review process we push to identify & fix a11y issues before they ever reach production. For any new colors used, we ensure that our Design team has approved & signed off on their usage to meet standards on contrast, and for new tests submitted we check for querying the DOM based on role, rather than text that we expect. For any project, we collaborate across multiple teams to deliver against our standards, and expect that at each stage of planning and development we consider what improvements can be made to deliver a great user experience for everyone.
Our internal component library is also continually improved with a11y in mind, from our color choices, to our implementation of each component we are working toward fully passing all accessibility standards. By having accessibility baked in to our fundamental components, it makes it much easier to confidently build new features, as all teams using the component library can rely on the existing work that's been done. Any new components needed are either built out for a specific use case, or created to be more generalized & included in our overall component library for use in other projects. Either way, new components are built to the same standards as our overall library and reviewed by our UX Writing and Design teams for alignment.
Practices, conventions, and commitments to a11y
Unfortunately, accessibility cannot be fully automated or abstracted to libraries & tools, and even external processes can fail to maintain highly accessible applications. That is why we strive to build and improve upon a culture of inclusivity and accessibility. Within Dashlane's Engineering team, we've partnered with accessibility experts to provide training specific to our applications. During these training sessions all engineers at Dashlane are encouraged to ask questions, and to read and understand what a11y changes have been made and why. We then take those lessons into future code reviews and projects to continually improve our products.
Our partnership with eSSENTIAL Accessibility enables us to provide our users with free assistive technology for those with physical disabilities, and through routine audits we can remain confident in delivering a great experience for all of our users.
Never perfect, but always improving
If you encounter any barriers to using our applications, please don't hesitate to reach out by contacting our Customer Support at support@dashlane.com. We welcome your feedback to help make Dashlane a great product for everyone!
Sign up to receive news and updates about Dashlane
