<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=451851) </details> <!--IssueSummary end--> We must ensure Rapid Diffs follow accessibility guidelines mentioned in the blueprint document. The accessibility testing should be automated as much as possible. ## Automated tests We can utilise axe-core gem based tests in feature tests. [See documentation on how to add automated accessibility tests](https://docs.gitlab.com/ee/development/fe_guide/accessibility/automated_testing.html). The same gem could be used for unit tests for haml component. It's important to note that these tests only check the component/page at a given moment in a current state. This means any triggered or rendered later elements need to have a designated test block. In the context of Rapid Diffs, this could be: * additional check when another portion of diff **is being streamed** * additional check when another portion of diff **has been streamed** * additional checks for parallel view * additional checks for whitespace changes visibility ## Manual tests Manual testing should make sure we [adhere to the guidelines highlighted in the blueprint](https://docs.gitlab.com/ee/architecture/blueprints/rapid_diffs/#accessibility). Make sure it is possible to perform all possible tasks with the following modalities: * keyboard * screenreader (at least NVDA + Firefox)