Skip to content

a11y Merge Request Widget

Problem to solve

The full a11y report being downloadable is great but a developer like Sasha needs context within the Merge Request about the impact on accessibility from the current change. This is not easily deciphered from the report today. We need to solve that gap for Sasha so they can quickly resolve new accessibility issues their change has introduced as early in the development cycle as possible.

Intended users

Further details

The goal of this feature is to solve the problem of too much information that isn't actionable that may come from a full accessibility report. Sasha and Presley only want to make sure the change in the Merge Request is not degrading the accessibility of the project. If the change does degrade the accessibility then they want actionable information on how to fix it. This may happen as part of initial development OR in a design review prior to Merge of the code.

This is part of the work that moves the ~"Category:Accessibility Testing" to maturityviable.

Goals

This iterates on the a11y MVC by bringing the difference of the latest scan vs. the last scan of /master into the context of the MR. The Outcome(s) for this are as follows:

  • When I build code, I want to see the changes to a11y in the context of the MR, so that features I release can be used by everyone.

Proposal

Building on the MVC that made a .json file available and the previous pattern of code quality that compares the report of the new branch to the base branch display the changes between the two in a widget on the Merge Request page.

A link to the full report (or downloadable artifact) from the widget should be provided.

The widget should be minimized on page load but with an indicator that improvements/degradations have been found.

Permissions and Security

Documentation

  • Update existing documentation for setup for MR widget and any caveats for comparison (artifact expiration, need for two, etc.) to appear.

Testing

@zeffmorgan - can you take a look at your convenience?

What does success look like, and how can we measure that?

Acceptance Criteria

  • MR Widget is displayed when a11y job is included.
    • Improvements and degradations have their own visual indicators
    • If the diff cannot be generated display a tooltip similar to the code quality pattern.
    • Provide a link to the information from the pa11y report about the issue found.
  • Track usage of the feature
    • Provide a count of how many times the MR widget is displayed to be queried in Periscope
    • Provide a count of how many times the MR Widget is expanded to be queried in Periscope

What is the type of buyer?

Individual Contributor.

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by 🤖 GitLab Bot 🤖