Tracking Issue for a Chapter on Accessibility in Rustdoc

This is a tracking issue for writing a chapter about accessibility in rustdoc. The chapter is meant to describe the accessibility of rustdoc, that is, the accessibility guidelines it follows, and its compliance with recognised norms like the WCAG 2.1 Guidelines. It was discussed in #t-rustdoc > A Proposal to Make Rustdoc More Accessible.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Finalise all the accessibility guidelines and features implemented by rustdoc
• Create a first draft for the chapter.
• Improve the first draft and create a final draft
• Final review and deployment

Unresolved Questions

N/A (if you have any please send them down below or in the zulip thread)

Implementation Details:

An excerpt from the thread about the documentation:

Documentation about existing compliances and accessibility features.

1. Within rustdoc's documentation, we should clearly and expansively document all supported (and unsupported) accessibility features. (Sites of documentation include the rustdoc book, for example).
2. Note: We should document and strive to implement the WCAG 2.1 guidelines for accessibility, as they are the industry standard for building accessible applications. See the Useful Links below for details.
   This is a very high-level conceptual plan that I'm presenting to you guys. I am eager to get feedback, suggestions and implementation feasibility details from you guys, who know much more about rustdoc than I do.