Accessibility guidelines

[agriyakhetarpal]

We have meetups at several places across the city with a diverse audience, with a variety of formats and screens. I'd like to propose formalising some guidelines that we can ask talk authors to follow when they open issues as a part of #337.

In general, it would be nice to audit venues for physical accessibility guidelines, even if we aren't a part of or associated with the regulatory bodies, as a matter of due diligence.

We've discussed this internally a few times before but we didn't work on it much further after this. I shall be writing a document that's separate from the Code of Conduct and the current guidelines and opening it up for community review (for the current volunteers who review the proposals and the audience on Telegram/WhatsApp). We can start with something small and add a few basic points, and keep expanding them as we see fit.

What I'd like to include some notes on, at the time of writing:

• accessibility for slides and digital assets
• accommodation or special arrangements we need to make for speakers
• what speakers can do to ensure that their material will be accessible
• our commitment as organisers towards these rubrics

[Schefflera-Arboricola]

Thanks for opening this issue!

I think this will serve as a comprehensive accessibility guidelines for organisers, venue owners and speakers, right? It might also be helpful to include a form or instructions for attendees to share any accessibility requirements in advance(I think meetup used to ask that-- but we should consider adding an email or contact to communicate such requirements -- if in case they are not able to RSVP).

Additionally, I recently attended a Python Bangalore meetup where they collected feedback through a gform at the end and shared the aggregated responses. That’s something we could consider implementing as well.

Also, I think we can also take some inspiration from the discover cookbook for general guidelines: https://discover-cookbook.numfocus.org/intro.html .

I shall be writing a document that's separate from the Code of Conduct ...

I think creating a PR might be better instead of a shared document—PRs allow for structured review, discussions, suggestions, and version control, while documents can be edited or deleted without traceability-- but feel free to choose whatever option feel comfortable to the majority!

And something related to CoC-- I think we should emphasize it more during the opening of each PyDelhi meetup. This includes clearly stating what can be reported, and how to report, and making it easy to identify the CoC contacts—perhaps with badges or some visible marker. There are a lot of useful practices we could adopt from here : https://numfocus.org/code-of-conduct-archive/response-and-enforcement-events-meetups . Thanks!

[github-actions]

Hi there! This proposal has been automatically marked as "inactive" due to it
not receiving any activity for the last sixty days.

To you as a contributor to the PyDelhi community, thank you for your proposal
and apologies if this issue fell through the cracks! This ping was created to
help bring this proposal a fresh pair of eyes. If you need any help, you can
always reach out here on this issue, or email us at
pydelhi.org@gmail.com.

If you think that this talk is no longer relevant, or that you are no longer
available to deliver this talk at one of our meetups in the coming time, you
may either close this issue, or the currently active volunteers shall do it
at some point in the future. If you are still interested in delivering this
talk, please comment on this issue to indicate your interest, and the
"inactive" label will be dropped automatically.

If you are a volunteer for the PyDelhi community, and if you no longer have
the bandwidth to dedicate to reviewing this proposal, please consider
reaching out to your fellow volunteers to help you with this proposal on the
appropriate communication channels.

If this issue is not a talk proposal, please ignore this message, remove the
"inactive" label, and either continue with your work here as planned or
close this issue if it is no longer relevant.

[agriyakhetarpal]

Thanks for sharing your thoughts, @Schefflera-Arboricola!

I think this will serve as a comprehensive accessibility guidelines for organisers, venue owners and speakers, right? It might also be helpful to include a form or instructions for attendees to share any accessibility requirements in advance(I think meetup used to ask that-- but we should consider adding an email or contact to communicate such requirements -- if in case they are not able to RSVP).

Yes, this is good to have. @Animesh-Ghosh and @Daksh777 have access to the Commudle page, so they might be able to comment if there is such an option (or if a set of few custom questions can be added).

Currently, these accessibility guidelines involve multiple parts and stakeholders, and I believe the first part would be directed to the organisers/venue owners by potential speakers. Of course, we'll do what it takes and what is within our capacity to be accessible to speakers and volunteers, but it's essential to limit the audience for each part of the guidelines and proceed sequentially; otherwise, this is too large a task to undertake. Although it is expected of all attendees at offline meetups that they will need to accommodate light exercise for commuting to the venue.

Additionally, I recently attended a Python Bangalore meetup where they collected feedback through a gform at the end and shared the aggregated responses. That’s something we could consider implementing as well.

Yes, we did this (courtesy of @Daksh777!) for the May edition by showcasing a large QR code pointing to the form, and quite a few people did end up filling it out, I think. That's a win! The next step would be to iterate on the feedback received, continually improve the form, and make the results publicly accessible after they have been anonymised.

I think creating a PR might be better instead of a shared document—PRs allow for structured review, discussions, suggestions, and version control, while documents can be edited or deleted without traceability-- but feel free to choose whatever option feel comfortable to the majority!

Yes, a PR is what I've intended to do here indeed – words are ambiguous 😄 I actually did end up writing something short here as a first draft (for the first part here: from the organisers to the speakers) but unfortunately didn't put it up any sooner; I'll put it up as a PR later today, and it would be nice if we could get it added as a first pass, after review.

Thanks for the reference to the NumFOCUS Discover Cookbook and I agree with comment about the CoC! That's something we should handle in a .github/ repository that I've created just now: https://github.com/pydelhi/.github.