[READY FOR REVIEW] Adding accessibility policy draft (accessibility.md) and practices

ACCESSIBILITY.md

@@ -0,0 +1,97 @@
+# Accessibility Policy of The Turing Way Community
+
+Within _The Turing Way_ community, we define accessibility practices as a set of community-wide, behavioral, social, and technical decisions that can be taken to ensure that all are welcome and are able to enter and participate in research, data-driven processes, communities and events despite any barriers for access.
+
+While accessibility is commonly understood with respect to disability, we – meaning _The Turing Way_ community – define accessibility as giving access to everyone, with specific attention given to ensuring proper access for groups of people that encounter different barriers for participation. Barriers may be anything related to, including, and extending beyond the following: 
+- Age
+- Disability
+- Ethnicity and race
+- Family
+- Language (written and/or spoken)
+- Geography
+- Nationality
+- Religion, faith and belief
+- Sex and gender
+- Sexual orientation
+- Socioeconomic status
+- Technical or disciplinary background
+
+We recognise the complex and interlinking ways in which intersectionality affects identity, and thereby, access or inclusion within any community project like _The Turing Way_. So in this sense, our accessibility practices may overlap with practices that enable inclusion more broadly within any community.
+
+In developing this policy, we aim to draw from the [access-centered framework](https://accesscenteredmovement.com/what-access-centered-means/) in describing access as a constant process that changes in each space with each individual. Therefore, while this policy outlines our commitment to access-centered practices within our community in a broad sense, we also document the specific practices we use within _The Turing Way_ our Community Handbook, as well as share broader recommendations that go beyond our current practices in the Guide for Accessibility. Each resource (our Accessibility Policy - this document, Community Handbook Accessibility Guidelines, and our Accessibility Guide) play a different yet overlapping role in enabling, documenting, and sharing our evolving language around accessible and inclusive collaboration.
+
+This policy is a work in progress, as are the practices that we employ as a community. Much like how _The Turing Way_ itself is always being written and rewritten, our accessibility policies and practices are constantly being updated as broader awareness grows and changes in technology are made.
+
+## 1.1 Core Principles
+
+These core principles are at the heart of our accessibility policy, and they extend beyond the web accessibility of our open access guides (see 2.1) to the broader practices that that we use as a community on collective platforms (see 2.2) and while hosting events (see 2.3).
+
+This means that questions of access are tied to how people read the guides as well as their ability to participate in the project and the community. Participation in _The Turing Way_ itself can be defined broadly, but doing so often requires navigating a number of different platforms. In all contexts, we aim to facilitate access in a broad sense through:
+
+1. **Removing barriers**: We actively advocate for and employ tactics that seek to remove barriers for any current or future participants in our community. This may include people who historically have been limited or structurely excluded from participating in through educational, geographical, linguistic, or technical barriers.
+2. **Sharing openly and with openness**: We aim to draft, write, review, and edit our open access guides using open source practices, and we do this in order to enable people from a broad range of backgrounds to get involved in the project.
+3. **Supporting inclusive participation**: We acknowledge that openness alone does not make a project accessible in a broad sense, and we are committed to maintaing a socio-technical infrastructure that enables inclusive participation more broadly. This includes hosting spaces for contribution, documenting our practices, and actively gathering feedback.
+
+The practices and policies listed here relate to these three operating principles, which shape how we work within the community to enable access on the web, on our community platforms, and while planning events.
+
+### 2.1 Web Accessibility
+
+_The Turing Way_ is committed to ensuring the web accessibility of our guides.
+
+As an open source community that relies on  projects and platforms for our underlying infrastructure, we acknowledge that we are limited in what standalone access-centered support we can offer. Our project is built with JupyterBook and using the Github platform. Both of these platforms have policies that address how they address the [W3C WAI's Web Content Accessibility Guidelines 2.0](https://www.w3.org/TR/WCAG/). You can read more about the the experience of a researcher at Accessible Notebooks Hackathon in ["Notebooks For All: Making Jupyter Notebooks More Accessible"](https://astrobites.org/2023/06/10/notebooks-for-all/) and about Github's work in the [Github Accessibility Report](https://accessibility.github.com/).
+
+As a community however, we are committed to ensuring broader accessibility of our resources through using this infrastructure through:
+- Choosing sufficient color contrast in our hand-drawn images that make our images accessible in the context of color-blindness
+- Using and employing appropriate and relevant alt text (also known as 'alternative text') for all of our images, charts, and data visualisations (an ongoing project with in the community)
+- Navigation without the need for a mouse or track pad during either the reading process on JupyterBook and/or contributing process on Github
+
+### 2.2 Community Platform Accessibility
+
+_The Turing Way_ is committed to ensuring our accessibility as a community on all the platforms we use.
+
+In our Community Handbook, we describe these practices more specifically and in more detail. But as a baseline, our community is dedicated to enabling access across the various platforms we use through:
+- Providing diverse opportunities and platforms for people to contribute to _The Turing Way_ despite barriers or difficulties associated with one platform or another
+- Setting and embodying standards for writing and contribution that understand the way in which language may exclude as well as include people in data science, research, and other collaborative projects
+
+### 2.3 Community Event Accessibility
+
+As a community, we frequently organise events for a variety of purposes: for coworking, trainings, workshops, panels, conference talks, and more.
+
+In our Community Handbook, we describe these practices more specifically and in more detail. As a baseline however, we are committed to enabling accessibility through:
+- Supplying and recording transcripts for audio and closed captioning of video content
+- Enabling wide access to our program context across a variety of platforms
+- Uploading slides and/or presentation materials on Zenodo or other platforms to enable referencing
+
+### 3.1 How we work with Access-related Feedback
+
+Gathering access-related feedback is integral for ensuring that we can remain accessible as a community. We would like to offer a a few ways of sharing feedback with us, and are currently working to develop the following initiatives:
+
+1. **Feedback form**: Please submit access related through [this form](https://forms.gle/Ngr2eUtQmf7aEeao6). All of the information in this form is processed anonymously, with the option of submitting contact information by choice. 
+2. **Drop-in sessions**: Throughout the calendar year, we would like to facilitate drop-in session to receive feedback about access related different parts of project. These may take place at our [Collaboration Cafe](https://the-turing-way.netlify.app/community-handbook/coworking/coworking-collabcafe.html) or may be hosted separately. 
+3. **Email the Research Community Manager or project team directly directly**: You can always email the Research Community Manager directly at asteele@turing.ac.uk with direct feedback. Alternatively, you can also 
+4. **Attend the Accessibility Working Group meeting**: The Accessibility Working Group meetings may be a place where you can deliver feedback in a small group environment. Please join the #Accessibility channel on slack for more information.
+
+We recognise that many feedback forms and other forms for gathering feedback can often operate as "blackboxes" that receieve information without taking actionable steps to address them.
+
+Knowing this, we are working to develop processes that enable us to action and report transparently on feedback given through these channels. This may include:
+- Reporting within the Accessibility Working Group in order to discuss possible actions that can be taken to address feedback
+- Liasoning with appropriate groups within The Turing Way project (i.e. the Infrastructure Working Group) in order to create or resource technical changes that may be needed
+- Escalating feedback to the project co-leads, funders, and others at the constitutional level of the project as needed
+
+## Confidentiality
+
+By default, all reports will be kept confidential. If submitted through a non-anonymised option, when the team discusses incidents and feedback, we will anonymize details as much as we can to protect reporter privacy. In some cases we may determine that a public statement will need to be made. If that’s the case, the identities of all victims and reporters will remain confidential unless those individuals instruct us otherwise.
+
+## Acknowleding Third-Party Platforms
+
+We recognise that our project relies on a number of third party platforms, and that all of these platforms may not be accessible by default. In future iterations of this policy and guidelines, we aim to employ community audits to understand and review the use of these platforms and their commitment and process for accessibility. 
+
+## Acknowledgements
+
+This Accessibility Policy was created by The Turing Way.
+
+In developing this policy, we have referred to numerous resources who have developed similar materials. 
+
+Contributors to the initial document are Alexandra Araujo Alvarez, Andrea Sanchez-Tapia, Anne Lee Steele, Chi Zhang, Esther Plomp, Laurel Ascenzi, Jesica Formoso, Liz Hare, Malvika Sharan, Patricia Loto, Sophia Batchelor, and Tania Allard. Initial drafts of this policy have been made and were documented from 2022 to 2024.
+
+We also refer to the resources and process of Silvia Canelon's ["Accessibility Commitment"](https://silviacanelon.com/accessibility), and have reviewed a number of Accessibility and Access-related policies in the drafting of this document. This includes the [Open Accessibility Policy project](https://github.com/ascott1/accessibility-policy), the [Wigan Accessibility Statement](https://www.wigan.gov.uk/SitePages/Accessibility-statement.aspx), and the [gov.uk guidance](https://www.gov.uk/government/publications/sample-accessibility-statement). 

book/website/_toc.yml

@@ -780,9 +780,11 @@ parts:
             file: community-handbook/accessibility
             sections:
               - title: Event Organising
-                file: community-handbook/accessibility/event-organising
+                file: community-handbook/accessibility/accessibility-event-organising
               - title: Alt text
-                file: community-handbook/accessibility/alt-text
+                file: community-handbook/accessibility/accessibility-alt-text
+              - title: Communication Platforms
+                file: community-handbook/accessibility/accessibility-comms-platforms
           - title: Communication Platforms
             file: community-handbook/communication-channels
             sections:

book/website/community-handbook/accessibility/accessibility-comms-platforms.md

@@ -0,0 +1,21 @@
+(ch-accessibility-comms-platforms)=
+# Access-centered support on Communication Platforms
+
+_The Turing Way_ uses a variety of platforms for communication (i.e. Slack, social media platforms like X/Twitter, Linkedin, Mastodon) and collaboration (i.e. Github, HackMD, Etherpad). 
+
+This chapter describes the access and inclusion-related support we provide on our communication platforms, as we as support we hope to provide in the future.
+
+In general, we encourage an approach to communication platforms that is as accessible as possible, for as many people as possible. We encourage our community to practice kindness when you communicate with others, and be mindful of cultural, linguistic, disability, and individual differences that may affect how people communicate online. 
+
+On every platform our community uses to communicate or collaborate, we aim to enable access in a broader sense as defined by our Accessibility Policy.
+
+## Access and inclusion-related support we provide on communication platforms
+
+We aim to provide the following support and normalise the following practices within our community by doing the following places:
+
+- **Adding alt text to images**: We use alt text or "alternative text" to describe images, diagrams, or other visuals within _The Turing Way_. To learn more about how to write and use alt text for your work, please use this {ref}`guidence<accessibility-alt-text>`. 
+- **Limit embedded links and provide alternatives for accessing information**: On many platforms, embedded links may not be accessible by screen readers, or may increase cognitive overload. If you are inserting a link into a message, limit the number of embedded links within a message. On Slac, avoid embedding links within replies to messages when possible, as links posted within threads are not readable for screen readers.
+- **Limit use of emojis that disrupt narrative flow**: Do not replace words with emoljis or use too many emojis to communicate important information. Screen readers usually read one emoji at a time using the alternative text and while sometimes the purpose may be clear (i.e. ```:thumbsup:``` represents an icon of a thumbs up sign), at other times it may not be (i.e. ```:partyblobcat``` represents a multicolored cat that is rotating in a circle, and is generally used in the context of a celebration or celebratory news). More broadly, strings of emojis can produce a clunky, repetitive user experience for people trying to understand the core message.  Remember that not all people are able to access the emoji reactions option within Slack, and normalise using written affirmations as well.
+- **Cross-post information to ensure openness**: People interact with _The Turing Way_ community on many different platforms. Not everyone in the *The Turing Way* community is in the Slack workspace, or on Github, in every community call, or on every social media channel. Where possible, we aim to normalise creating issues and discussions on the Github repository or post across social media channels in order to ensure the widest reach and participation possible across the community.
+- **Be sensitive to bandwidth needs**: As a digital and remote-first project, we are committed to making sure that our resources, communication platforms, and community are accessible to the widest possible audience, despite any bandwidth needs or barriers. In order to make sure that our communication platforms are accessible in low-bandwidth environments for the community, we avoid posting data-intensive content like videos directly into the channels. Instead, we prioritise hosting the content on other platforms (i.e. YouTube) where viewers have the option to adjust the data-intensiveness of the streaming platform. We also frequently turn off video streaming in team meetings in order to adjust for participants or community members that find it difficult to tune in.
+- **Be descriptive and clear in communication**: Aside from these concreate recommendations that we adhere to within the community, more broadly we aim to prioritise clear communication within _The Turing Way_ in order to ensure that our messages are accessible and readible for the community.