Aria Automation: Winning at accessibility in VMware

Introduction

As we navigate the digital world, accessibility has become a crucial aspect of web design and development. It is not just a buzzword, but a fundamental principle that ensures inclusivity and equal access for everyone. In this blog post, we will look at the importance of accessibility.

What is Accessibility?

Accessibility is the practice of designing and developing websites, applications, products, and services that individuals with disabilities can use, including visual, auditory, cognitive, and motor impairments. Accessibility aims to remove barriers and provide equal opportunities for everyone to access information, navigate interfaces, and interact with digital content.

Why is Accessibility Important?

The significance of accessibility becomes apparent when viewed through multiple lenses, highlighting its importance from various standpoints, for example:

Legal compliance - Accessibility is a legal requirement in many countries and regions. By ensuring that your enterprise product is accessible, you can comply with these laws and avoid potential legal issues.
Inclusivity - Accessibility promotes inclusivity in the workplace. It ensures that everyone can access and use enterprise products, regardless of their abilities. This, in turn, fosters a more diverse and inclusive workplace culture.
Improved productivity - When enterprise products are accessible, employees with disabilities can use them efficiently, which can improve their productivity. This can lead to a more productive workforce overall.
Expanded customer base - By creating accessible enterprise products, you can reach a broader customer base. This includes people with disabilities who may have been excluded from using your products previously.
Improved brand reputation - Accessibility is an essential aspect of corporate social responsibility. By creating accessible enterprise products, you can enhance your brand reputation and demonstrate your commitment to inclusivity.
Innovation - Creating accessible enterprise products can inspire innovation. By designing for accessibility, enterprises can develop new products and features that benefit everyone.

Why “Winning at accessibility in VMware”?

We chose a bold and ambitious title for this article, and you may be wondering why. Well, let us tell you about this year’s VMware Accessibility Awards Show that celebrated outstanding accessibility achievements in eight categories. Among the winners, VMware Aria Automation stood out, receiving two well-deserved awards: "Most progress made" for more than 70% improvement in its accessibility score, and "Most bugs closed" for successfully addressing over 450 bugs within just a 12-month period.

This awards show is a testament to VMware's solid commitment to acknowledging and honoring accessibility excellence. In this blog post, we want to share our experience and insights and, hopefully, empower others on their journey towards accessibility greatness. Join us as we dive into the keys to "winning at accessibility" and discover how VMware has become a true industry leader in this crucial domain.

Overview of VMware Aria Automation

In today's rapidly evolving digital landscape, organizations are seeking efficient ways to manage and automate their cloud infrastructure. VMware Aria Automation is a robust cloud management platform designed to streamline and simplify the deployment and provisioning of virtual machines and applications in multi-cloud environments.

VMware Aria Automation is pivotal for organizations as it enables them to be agile, responsive, and efficient in managing their cloud resources. By simplifying multi-cloud management, enforcing governance controls, ensuring consistency, and integrating with existing tools, VMware Aria Automation empowers organizations to optimize their operations, reduce costs, and meet compliance requirements, ultimately driving success in their cloud adoption journey.

In terms of the user interface (UI), VMware Aria Automation utilizes Angular and Clarity technologies. Angular, an open-source JavaScript framework, provides a solid foundation for dynamic and responsive UI components. Alongside Clarity, VMware's design system, the product delivers a seamless and intuitive user experience. These technologies combine to create a visually appealing and user-friendly interface, enhancing the platform's overall accessibility and usability.

The Process and Key Features of Adding Accessibility

In the initial stages of our product's development, accessibility was not a central focus, and many of our engineers lacked experience in creating accessible user interfaces. This posed a significant challenge when we decided to integrate accessibility into our mature, heavily used service.

When we first conducted accessibility testing, it revealed 321 accessibility issues. Rather than panic, we methodically went through each one. Some were a bit intricate to decipher, but thanks to the attached screenshots and WCAG 2.0 and 2.1 (Web Content Accessibility Guidelines) Success Criteria codes, we were able to navigate through them. The more we learned about and implemented the codes, the better we could understand the issues at hand. As we reviewed the 321 issues, patterns started to emerge, giving us a sense of their severity. It was clear that we needed to categorize them for better management.

Organizing so many issues was a considerable challenge, but the benefits significantly outweighed the effort. The main groups formed were as follows:

HTML Semantics vs ARIA (Accessible Rich Internet Applications) attributes - HTML Semantics provides robust accessibility support, meeting the needs of screen reader and keyboard-only users. But when the capabilities of standard HTML are not enough, ARIA attributes, that can be added to HTML, fill the gap. We encountered challenges such as all our Clarity signposts were sharing the same aria-label. Our solution was to set each signpost's aria-label to its title, thereby distinguishing them.
Visible Keyboard Focus - While standard HTML components offer focus visibility, this was not the case for our custom components and even certain Clarity components. To address this, we implemented the tabindex attribute in our custom components.
Keyboard Focus Navigation - When a user selects a navigation menu item within the same application page, JavaScript must shift the focus to the first or most logical element of the new content (usually the H1). The challenge with this rule was to ensure that whenever a modal opens, the focus moves to its first element, and upon closure, the focus returns to the element that triggered the modal. Given the multitude of modals we had, we devised a custom directive that successfully redirected the focus back to the initiating element after a modal's closure. Now, this functionality is provided out of the box by Clarity.
Additionally, we faced a challenge with the use of expandable rows in our datagrids provided by Clarity. The issue arose because the button to expand or collapse a row did not expand the content immediately after it in the DOM, but rather further down, which disrupted the logical flow. As per Clarity's guidance, they were moving away from supporting expandable rows in favor of their new Detail Pane component.
Skip Links (required for nav menus and other repetitive blocks of content) - Skip links, also known as "skip to content" links or "skip navigation" links, are navigation that allows users to skip over repetitive web content. They are especially useful for people who use screen readers or navigate websites using a keyboard. This was straightforward to implement, we created a custom component that provided the skip to content functionality and made it focus H1 titles by default, while providing a way to add exceptions.
Hover Content Accessibility (requirements for mouse and keyboard users) - Primary challenges with hover content involve the dropdown menu's lack of keyboard navigation, its disappearance when the mouse pointer moves away, and the absence of an 'Esc' key dismissal function. For instance, pressing 'Esc' did not close some of our modals. This occurred because we had the property [clrModalClosable] set to "false", blocking the typical dismissal function.
Headings Structure - Guidelines for headings are clearly defined: There should be a single <h1> as the main heading, heading levels should not be skipped, and styled headings should be marked up with HTML or ARIA. Exceptions exist for non-primary content and pages without visual headings. Applying these rules in our product was challenging, necessitating a thorough review and adjustment of all headings to assign the correct <h1, h2, ...> levels, styles, and roles. This was especially tricky for components used in multiple places, requiring different heading sizes. To streamline the process, we marked all modal headings as <h1>.
Page Titles (Browser Tab Title) - We made sure our titles were meaningful, appropriately placed, and followed the structure <title>(Purpose) | (subdomain) | (site name) </title>. We streamlined this process by devising an attribute directive for each page title. Fortunately, we had an existing component for displaying titles, which only required the application of our new directive. The use of iframes introduced an additional challenge to our process of ensuring consistent and meaningful titles across all our pages. This issue added a layer of complexity to our task, but we were able to successfully address it.
All form elements such as <input>, <select>, and <textarea> must be accompanied by labels. If you are utilizing containers like <clr-input-container>, <clr-textarea-container>, or <clr-select-container> with label and input, the label and the input are linked automatically. We reviewed all custom forms and inputs to connect a label to every form control.
Form Errors - Form errors, depending on their nature, come with a set of rules and requirements. If you are utilizing Clarity's error handling, accessibility rules are inherently satisfied, but custom components demand tailored solutions. A challenge we faced was that our product, being mature, previously used Clarity's initial design approach for displaying errors on input fields. A signpost was used to contain all error information, and not all our fields had error messages. So, we switched to using a standard error message for all our input fields. The message we used was: "You must enter a {fieldName}."
Notifications/Status messages - Important notifications, when not focused, must still be announced to screen reader users. Our primary system for notifications and status updates uses Clarity alerts wrapped in a service. To meet the accessibility standard, we introduced a 'span' to each alert, structured as follows: <span class="clr-sr-only" role="status">.
Buttons vs Links - In terms of semantic function, links should be used for navigation to a new location, while buttons are designated for UI updates or form submissions. This distinction is crucial for screen reader users. We identified and corrected several instances where links and buttons were incorrectly used.
Alternative Text - Alternative text (also known as image labels or text equivalents) is text that describes what is in an image. Screen readers read alt text aloud for users with visual impairments. We added an alt="" attribute to several of our custom images to provide this necessary context.

Testing and prevention

Automated tests

Extensive product audits are truly time-consuming and do not happen very often. As every software organization tries to optimize costs by catching the bugs as early as possible, the development team had to think how to find weaknesses before the testing team finds them. Luckily, we live in a world where everything can be as-a-service, so we ended up having accessibility as a service. Accessibility as a Service is a collaboration between the VMware Test as a Service (vTaaS) team and the Accessibility team. It is a containerized inspired approach bundling:

vTaaS - A comprehensive testing harness proven to run test automation, script management, record/replay capabilities, etc., which is designed, developed, and maintained by the VMware in-house team. Accessibility testing is one of the key modules in vTaas.
WAVE - A commercial web evaluation engine highly regarded as one of the best-automated evaluation tools for accessibility and developed by WEBAIM, a Utah State University accessibility nonprofit. We rely on the WAVE API (Application Programming Interface) for automated accessibility tests.
Crest - An open-source ML-based accessibility evaluation tool developed by VMware to extend automated testing beyond what is currently available. Crest tests are in addition to the WAVE API tests mentioned above.

The team developed a browser extension, called ACE. This extension combines the power of vTaaS, WAVE, and Crest, providing us with a wealth of valuable information effortlessly. The biggest convenience is that it requires minimum effort on our side to incorporate it in our testing pipelines and in return it gives us a lot of useful information. We wanted to have the testing results frequently, but without getting overloaded by them, this is why we chose one of our Jenkins jobs, which runs a very extensive set of E2E tests against the latest state of the code.

The E2E tests that we have are Protractor based, which means that they are run in the browser, so every time this job runs, it launches a browser, we added the above-mentioned extension to it and that is all. With only this simple step now we have testing reports generated for each run of the tests. These reports have information for every single page that was visited by the tests, including information about what types of issues were identified, where they occurred, how to fix them, and why they are problematic. The reports also show the exact places in the code that need modification.

An essential aspect of our accessibility testing process is the close collaboration with the team maintaining the testing tool. By working together, we can adapt the ACE extension to our specific needs and ensure ongoing improvements. This collaborative approach has enabled us to identify and rectify numerous accessibility problems between the two official audits, conducted by the Accessibility team. As a result, we save considerable time for both teams and positively impact our standards compliance.

ESLint rules

In addition to highlighting the importance and value of automated tests, it is crucial to prevent issues from arising in the first place. Thankfully, Angular offers a comprehensive range of ESLint rules that specifically address common accessibility concerns. Often overlooked by developers, these rules validate important HTML attributes related to accessibility. They ensure the presence of alt text for images, accessible content for buttons, links and headings, and correct associations between form labels and table headers. By incorporating these rules into the code, the developers gain immediate guidance on accessibility best practices, leading to the creation of more inclusive and user-friendly Angular applications. The list of rules consists of:

Alt Text (@angular-eslint/template/accessibility-alt-text) - This rule enforces the presence of alt text for images, ensuring that users with visual impairments can understand the content.
Elements Have Content (@angular-eslint/template/accessibility-elements-content) - This rule checks for accessible content within buttons, links, and headings, guaranteeing that users relying on assistive technologies can interact with these elements.
Label Has Associated Control (@angular-eslint/template/accessibility-label-has-associated-control) - This rule verifies the correct association between form labels and form controls, enhancing the accessibility of forms.
Table Scope (@angular-eslint/template/accessibility-table-scope) - This rule validates the appropriate use of the "scope" attribute in table headers, ensuring that screen readers interpret table data correctly.
No Distracting Elements (@angular-eslint/template/no-distracting-elements) - This rule discourages the use of distracting or unnecessary elements, promoting a more focused and accessible user interface.
Button Has Type (@angular-eslint/template/button-has-type) - This rule enforces the presence of the "type" attribute for buttons, preventing potential inconsistencies across different browsers and assistive technologies.

One of the great advantages of these Angular ESLint accessibility rules is their configurability. You can adjust them according to the specific needs of your product, providing flexibility while still maintaining compliance with accessibility standards.

However, during our implementation of these rules, we encountered some challenges. Most notably, the @angular-eslint/template/accessibility-label-has-associated-control rule often reported false positives. Upon investigation, we discovered that many of these false positives occurred when using Clarity's container components (<clr-input-container>, <clr-textarea-container>, <clr-select-container>, etc.). These components dynamically associate labels with form controls, eliminating the need for explicit associations in the code. While this approach does not cause actual accessibility issues in the product during runtime, it still triggers ESLint warnings. To address this, we decided to extend the rule ourselves and exclude these specific cases

At VMware, we believe in sharing knowledge and collaborating across teams. Recognizing that accessibility compliance is a common concern across our product family, we actively engage in knowledge sharing. As a result, members of another team have developed additional accessibility ESLint rules that address specific issues such as empty <div> tags, descriptive error messages, headings order, and semantic usage of buttons. We are excited to adopt these rules, as they will further enhance the accessibility and quality of our product.

Conclusion

We strongly believe that accessibility is a critical pillar of web design and development. It is not just a buzzword; it is a fundamental principle that drives our commitment to removing barriers and providing equal opportunities for everyone.

Embracing accessibility has numerous benefits for any organization. It enables us to comply with legal requirements, foster a more diverse and inclusive workplace culture, improve employee productivity, expand our customer base, enhance our brand reputation, drive innovation, and promote knowledge sharing. By actively incorporating accessibility into our products and services, we create a more inclusive, diverse, and user-friendly digital environment that positively impacts our stakeholders and society.

As designers, developers, product managers and content creators, we have a responsibility to prioritize accessibility and ensure that our digital products are inclusive for everyone.

Call to Action

Are you ready to take your enterprise products to the next level? Embracing accessibility is not only a moral imperative but also a strategic move for any business. Accessible products give you a wider customer base. Join us on this journey to make a positive impact and create enterprise products that are truly inclusive.

This blogpost is authored by : Petya Aleksandrova and Grigor Ganekov