Introducing the new accessibility contributing guide: Accessibility | Django documentation | Django 
Note that this is something that will improve over time. Thank you to all who contributed to this guide 
7 Likes
thank you for sharing this here 
we’re going to make a public announcement of the guide soon – edit: now, it’s live, thank you @mihrab34! And direct any feedback to this thread. Feedback very welcome! In particular we were thinking of:
- Producing more resources for PR reviews
- Recording a video of how we do PR reviews with this guide
1 Like
Do we need to add content related to color contrast testing in this document?
Changing colors is more of an internal UI element change rather than a UI design change, but since this document provides guidelines for accessibility contributions, I feel it is necessary.
I think it is a frequently occurring issue compared to other parts of the WCAG guidelines, and it is an area that contributors can sufficiently test.
Is there a specific reason why the Discord channel and the Accessibility team links were included in the last section?
From my perspective, the appropriate places to find issues when contributing to accessibility are the ticket tracker (with the accessibility keyword), the accessibility project board, and the Accessibility topic on the Django forum.
While the Accessibility team and the Discord channel are indeed helpful for participating in discussions or providing advice on specific comments related to accessibility, I’m not sure if including them in the last section is appropriate.
(Ultimately, their nature seems similar, but I’m not sure if they fit well with the section title and description.)
I think it might be better to separate these two links. 
-
Producing more resources for PR reviews
-
Recording a video of how we do PR reviews with this guide
If these two parts are added, where would they be included?
It reminds me of a great post I saw before on Sarah Abderemane’s blog 
thank you for the feedback! lots of super interesting things to consider here
Do we need to add content related to color contrast testing in this document?
We do! Contrast tests are part of Accessibility Insights, which we recommend. I think it’s enough? The testing methodologies we did document are because they’re largely only doable with manual testing.
Is there a specific reason why the Discord channel and the Accessibility team links were included in the last section?
The reasoning is to encourage people to report issues or get involved without having to go through figuring out everything on your own. The tickets tracker in particular is very daunting to newcomers, while if someone comes to #accessibility on Discord we can guide more!
The “source of truth” for issues and their resolution would be tickets / the forum, but it’s important to have more approachable intermediary resources.
If these two parts are added, where would they be included?
Not sure! What do you think would be the right place? In my mind those resources would be created outside the Django docs first. Then we’d get to decide about the right model for publication.
2 Likes
I don’t have much experience contributing to django, but in my experience, improving accessibility often involves making small UI adjustments.
In the process, I naturally ended up changing colors as well.
For example, there could be PRs like these…
- When using fixed colors that replace the colors provided by the browser.
- When the existing color contrast is insufficient
- When a new UI element is added (existing colors can be used, but there may be cases where new colors are introduced)
I think color contrast is also something contributors can manually check.
What exactly should be added would need some discussion, but as you mentioned, it would be nice to keep it as simple as possible.
The reasoning is to encourage people to report issues or get involved without having to go through figuring out everything on your own. The tickets tracker in particular is very daunting to newcomers, while if someone comes to #accessibility on Discord we can guide more!
The “source of truth” for issues and their resolution would be tickets / the forum, but it’s important to have more approachable intermediary resources.
Sounds good!
Adding the discord channel and Accessibility team links can serve as helpful milestones or reference points.
Additionally, I think we need to manage the django accessibility project board better!
I try my best to share accessibility related PRs in the Discord channel, but there may be parts I could miss.
Not sure! What do you think would be the right place? In my mind those resources would be created outside the Django docs first. Then we’d get to decide about the right model for publication.
I feel the same way.
Rather than the official django documentation, I think it would be great to have very detailed contribution guidelines categorized by type (ORM, Documentation, Admin, etc.) that can help new django contributors.
Going beyond simple details, adding visual images or examples could be a huge help for people trying to contribute for the first time.
These kinds of resources should probably be created and maintained outside of the official django docs.
I have a desire and plans to create a better process related to contributing to django admin.
I will probably need more experience to actually carry this out, but if I do, the process would likely include detailed guidelines for contributors.
And since it’s about Admin, it would also include accessibility related content as well as information related to code reviews.
However, I don’t know if this will come to fruition because it’s my personal plan!
Anyway, if I do add something like that, I also think an external document would be better.
And the location of that external document will also need to be discussed.