このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
Beyond being a compliance requirement in many cases, accessibility testing is the right thing to do for your users. Accessibility testing is similar to UAT or Usability (which we track here), but we see accessibility as a primary concern on its own. Our vision for this category is to provide actionable data that can improve the accessibility and readability of your web application within GitLab.
Interested in joining the conversation for this category? Please join us in the issues where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
This page is maintained by the Product Manager for Testing, James Heimbuck (E-mail)
Up next for Accessibility Testing will be a full view of the Accessibility report for a project. This is important for our Developer and Product Designer personas who want to understand outside of the context of the Merge Request what accessibility issues exist in a project.
We are also working on expanding use of Accessibility Testing and can acheive that goal by adding Accessibility Testing to AutoDevOps.
This category is currently at the "Viable" maturity level, and our next maturity target is "Complete" (see our definitions of maturity levels). Key deliverables to achieve this are:
We may find in research that only some of these issues are needed to move the vision for this category forward. The work to move the vision is captured and being tracked in this epic.
CI Competitors in this space are not providing first-party accessibility testing platforms, but do integrate with pa11y, lighthouse or other tools to generate results via the CI/CD pipeline.
Lighthouse CI can provide a very rich report about accessibility and performance issues found in a scan of a website. It is straightforward to store the reports to be made accessible publicly for review outside of a development team. The data provided on the report offers a great actionable view of data and can be setup to fail a build if certain thresholds are not met. Where we think we can outperform this tool is by providing comparison between a change in progress and a previous report OR a threshold. This would allow a team to make progress even as they are still below a lofty target without failing a build. Another advantage we believe we provide is removing the need to run another server to store and view reports.
There are no top CS/Sales issues for this category yet.
With the release of GitLab 12.8 the top customer item (gitlab#25566) was addressed. We look forward to feedback on the issues being tracked in the current epic for the category and beyond from customers.
The Design team has an open accessibility epic that contains items about making GitLab itself more accessible: gitlab-org#567. The long term vision for this category is for that team to be able to use GitLab to detect all of those issues in an automated way and see that they are addressed when fixed.
Another interesting issue is one to add a scan for a readability which can be used to ensure heavy text sites, like the GitLab handbook and Documentation, are easily readable. Text that is easy to understand is also easier to translate and results in a more easily understood translated version.
To meet our long term vision we will need to solve problems that will expand our out-of-the-box accessibility testing like helping customers track how accessibility is changing over time and providing additional scanners so users can be confident their web app is accessible by everyone.