and really important for open source communities to be able to thrive. And to that end, today we'll be speaking about Talks for All and how we can improve open source accessibility. My name is Zain Abdaldu. I'm a technical writer.

I'm also the founder of Write Tech Hope, formerly known as Z codes. And an organization that is focused on technical content creation services. I'm also an open source programs manager. I create programs to help encourage more diversity and inclusion in open source community. And from that to that end, I'm also a diversity advocate

and hence the reason why I'm having this session today. I'm going to hand over to my co-speaker Omotola to introduce herself. Hi everyone. Thanks for joining us. I'm Omotola Eunice Omotayo. I use she, her pronouns. I'm a community builder and also a women in take and do year advocate.

I work with the Outreachy Internship Program as one of the organizers. And I work there as the community manager. I also founded Elegance Media, which is focused on helping organizations and individuals to make the best use, effective use of online platforms.

Thank you. Thank you so much Omotola. So for this session today, we are going to be looking at what accessible documentation is, why it matters to open source community, what are the benefits of accessible documentation, and also the intersection between inclusion

and technical documentation. How did this intertwine? Actionable approaches to enhance accessibility. How can you boost accessibility in your open source communities and fostering a universal community? So this session is going to be beneficial to all open source communities, community builders,

open source project maintainers, and all contributors and everyone in the community at large because we believe that it is everybody's responsibility within the community to ensure that the open source community is accessible for all.

So, and we'll go right in. For us to be able to understand everything that we've talked about, how to improve accessibility within your open source community, we need to understand what it means. And to put it in the simplest way, accessible documentation is any documents,

guide, instructions, whatever document that you have within your open source community that is designed and formatted in a way that is easy for everyone within your community to understand and everyone that is looking to come within your community,

including people with disabilities, persons with disabilities. So it's, and for us to be able to achieve accessible documentation, there are intentional steps that the open source, we as the open source community need to take for us to be able to achieve this accessible documentation.

And that's why we're having this session to discuss all this today. So I'm going to hand over to my course with that to take it off from here. If you go on to the question, why accessibility, why does it matter

in open source documentation? And who are the people, just like Zeenab mentioned, that are going to benefit from accessible documentation? The answer would be everyone. I'm going to tell you everyone. Well, today less on this part, less focus on persons that have more disabilities or the other, right? And when we talk about persons that have disabilities,

we are talking about people who have a family, community impairment, motor impairment, who have difficulty in seeing or reading and rely heavily on the same screen reader to assess your documentation.

For these sets of persons, documentation needs to include things like alternative text, clear structure, which we are going to be going in depth into very soon. And for persons who have hearing impairment, right, this is also very important because these persons will rely heavily on,

they will be able to rely on the audio parts of your content, of your documentation. Why I mentioned everyone,

not just people with disabilities, because we have people who are non-native language speakers, people who primary language is not the one which your documentation has been written in, people who needs another form of aid, right, to understand and use your documentation. And we also have individuals who are not,

who may be impacted by concentration and focus, I mean, neurodivergence individuals, right? Their center of concentration is very limited. So these kind of folks who we should put in mind

when we're talking about accessibility, especially when it comes to documentation. So I'm going to be talking, so I'm going to be talking about the intercession

of the, to follow your voice and about inclusion. I don't know if you can hear me. Hi, I can hear you. Is it better now? Yes. Okay, awesome. So let's talk about inclusion, right? Think about your community or your target audience

are sets of diverse people, people who have different backgrounds, who have different abilities, just like we mentioned, people who have different understanding, who have different experiences, different cultures, these different sets of people makes a diverse target audience, right?

And when it comes to your documentation, your documentation, or you as a technical writer or a community leader, having the mindset of diversity, having the mindset to include the various diverse sets of target audience that you have out there.

So when you're writing your documentation, you thinking about who are the persons that are going to benefit right now from this documentation, and later, who are the other persons that are going to benefit from this documentation, or even come across this documentation. So as a technical communicator,

yeah, a technical communicator who wants to explain and ensure that everybody understand and make everybody understand and have access to the documentation, it is very important to come into center when it comes to inclusion and technical documentation.

Thank you so much, Omotola. So Omotola has said a lot about the intersection between technical inclusion and technical documentation. As open source communities, we are always striving to have more inclusive communities, more diverse community members to be able to gain

from the benefits of having an inclusive community. And as I mentioned earlier, it is what everyone's responsibility within the community and some of the principles that community builders, open source projects maintainers, you know, technical writers can employ

in ensuring equity and inclusion in technical documentation within the community is awareness. So one of the major challenges of having accessible documentation is that people don't even know or realize that they need to be really thinking

about things like this. Yes, some people have an idea, but when it comes to implementing documentation, do people understand, you know, what people, what audience with disabilities, what are their needs in terms of, you know, accessing your documentation, using your documentation. So the first step is awareness, ensuring that everyone within the community,

contributors, maintainers, everybody are aware of, you know, the goal of having an accessible documentation. Then establishing clear guidelines that community members can follow in creating this documentation. Then you have to conduct accessibility audits.

After establishing your guidelines, you have your documentation. You need to conduct regular audits, regular checks on your documentation to ensure that the documentation is following the guidelines that have been set out for accessibility. Testing your documentation with diverse audience,

not just within the maintainers or within, test it with everyone, put it out to the community, put it outside the community for people to test it, you know, and give feedback on all these accessibility measures that have been put in place. Optimize the documentation for different devices.

Remember some of the people we talked about with disabilities, it might even be due to, you know, situations or scenarios you find yourself, you are not able to access your documentation on the laptop. Can I easily access it on my mobile, easily without any issues?

And then you have feedback loop. So as having accessible documentation is something that is continuous and for us to keep improving, we need to implement great feedback, circle with the community, with the testers to ensure that we keep upgrading the documentation as needed.

And then as a technical writer, we also like have a major role to play in creating documentation that is accessible. As technical writers, the goal is to create good documentation

for a target audience. So, and in creating accessible documentation, there are questions that technical writers need to ask themselves to be able to do this. And the first is, who are the people, who are the persons that are part of your audience

based on all the analysis that you have done, you know, in creating that document? Who are the audience? Who are the people that are going to be part of those audience? Are you trying to capture everybody? Are you trying to capture persons with certain disabilities? Then you begin to think about what are the things I need to put in place

to be able to reach these people? And then you think about who might be excluded. So this could be intentional or unintentional in terms of, am I creating content in only video formats that only people that can hear can access?

Or am I creating document, putting important information in images where screen readers are going to miss those information? So when you think about who might be excluded, who might we be excluding and how are we excluding these people?

And then which brings me to the third question, which is, is any important information being withheld? So this could also be intentional or unintentional. Are you withholding any information through maybe the way you are organizing your document? Are you hiding important information

in a way that it's not easily accessible? So when you ask yourself these three questions before you start creating your documents and are able to give answers to the questions as a technical writer, it helps you to be able to create accessible documentation. And then which now takes also the actionable ways

or the practical approaches to now ensuring that this document is accessible when you start writing. So the first step is to use clear structure and headings in your document. So as a technical writer, when you've gathered all your information, you know who your target audience is,

you've gone through other phase, you want to start creating your document. Most times you start with a rough outline. You want your outline and your structure to be as clear as possible. We've seen documents where the headings, you have like H1, H2, H3 headings scattered

across the document without properly organizing each topic or each heading on that way it's supposed to be, you know, mixing things, putting information on that the wrong headings. We understand that as open source communities, it's not always the case of you create your outline.

Sometimes you have to make updates to the documentation. Most times it's not even sometimes you have to update your documentation as you bring in new features. It's important that as you carry out this update, you ensure that throughout the whole process, the outline, you still maintain a clear structure and outline for your document so that when people or everyone

is trying to access your document, it's easy for them to understand, to follow the structure and understand what's in the document. The next is to provide alternative texts for images. Yes, we know that it is good to use images while creating your technical document,

but then images should only be used as a supplementary to the text. They should not be used to replace information that should be in the document. If you're using images in your document, the images should only carry information that should not carry important information.

For instance, you shouldn't have images with tables or maybe I've seen images where you have like difference between this and that, and then you have that kind of information in an image. Yes, it looked nice, but if someone is accessing that document with a screen reader,

they are going to miss that information. And then whenever you have to use image, use all texts so that they can easily pick up what that image is while going through the document. The next is to use readable fonts and colors. So if you're using colors, if you're using colors in your document,

the fonts and the color should be something that is easily readable. The color contrast of the document should be right, so it's easy for everybody to easily use the document. There are color contrast checkers.

There are tools that you can use to check out this functionality on your documents online. So ensure that the font is clear, the sizing is not too small. You're using a clear colored text on a clear background. For instance, don't use light text on light background,

dark text, there are basic rules behind the usage of text and colors. So as open source communities, we need to ensure that we take note of these things when we are creating our documents. Use plain language, simple language.

You know, you ask some people questions about what technical writing is, and they think, oh, technical writing is about writing big, big grammar. But we all know that that's not the case because text is already complex as it is, and it is important for us to be able to break down these complex terms

in a way that everyone can easily understand. And we can only achieve these by doing things like using simple language, using simple sentences. Your sentences should not be hard to read, be direct, provide examples, you know, illustrations to help people understand what you're trying to talk about. Have use cases, use bullet points,

use things that people can relate to to explain what you're trying to explain. Just make it as clear and as simple and as concise as possible. And then use interactive elements, table of contents. Use this also limited, in a limited way.

Don't, because these elements are good, but then there has to be guidelines in how you use things like collapsible sections. Also ensure that you don't hide important information, but then when you have a document that's really long, you have a lot of things, and then you want people to be able to skim through

the important content without all the other information disturbing them. You can put this in collapsible sections. You can have code samples and things like that probably to explain your documents more and make it more accessible.

And then consistent format. This is also really important. Use of fonts. I know that nowadays a lot of open source communities use things like markdown, which is really good, but for cases where those are no use, ensure that your font styles, your sizes, and even when you're using markdown,

you still have your styling, your CSS, and all that to style your text. Ensure that you're using consistent font styles and sizes across your document, accessible color contrast, consistent accessible color contrast that people can relate to. So in some cases you're not using good contrast

while in others the contrast is not so great. Consistent list. Just make your document consistent. And this is easily achievable when you have a style guide that the community can follow. That's the best way because as open source communities, you have a lot of community members

coming to contribute to your documentation, coming to improve it. So you want to ensure that you have consistent formatting across by using a style guide. And then we have a few open source communities that are currently prioritizing accessibility. And they've posted out reports to show

that this has improved their open source communities in so many ways. We have LibreOffice prioritizing features like screen reader support, keyboard navigation. And this makes it a preferred choice for users with disabilities because of all these things that has been put in place.

And then it also has positive impact on the project in itself because it has an expanded user base and its repetition is also reinforced within the community as an inclusive community. We also have TensorFlow extended documentation

that is also working towards providing, making its community more accessible. So it has ensured that all machine learning practitioners can access its documentation and be able to build and use this platform, which has also helped it to extend its user base,

have a broader community of users that effectively understand how to use this product or this platform and are happy about using it. So I'm going to hand over to Omotola here to...

Thank you Zainab. I think Zainab has already explained like most of it. Talking about fostering a universal community, it is essential that universal community, diverse communities, that's what I mean, right?

Is focused on ensuring that documentation is accessible by everyone, regardless of their background or their ability in order for them to actively participate and even use the open source projects. So what we're talking about is not just in the advantage,

but it's not just going to remove the obstacle for individuals that have disability, but it's going to like make the projects, the community even more open and welcoming to a larger audience. We mentioned different benefits,

which include collaboration, it's going to reduce the barrier of participation. So people who probably use tornado will not have to complain about it, can use it. And that way you are empowering contributors and all together, everybody's going to have a positive and effective user experience. And that way people are going to stay back

in your community, stay back in your projects, continue building, continue enhancing your projects and the community. And in some way, it's going to like be a very good way to improve diversity in the open source ecosystem, to improve inclusion and to improve global accessibility.

Next slide, please. I'm going to use Outreachy. I mentioned earlier that I'm one of the Outreachy organizers. Outreachy is a remote internship opportunity

where folks are subjected to systemic bias and impacted by underrepresented children in the technology country they are living in, contribute to open source and open science projects. And so far over the years, Outreachy organizers have been able to like work with community projects to improve their documentation, their open source practices,

to make them eligible for the Outreachy internship, because we are focused, our target audience, the program target audience is to bring in diverse population, diverse person, right? So we want to like imagine our intended participants who needs to use like a screen reader, who needs to see like an out text or an image,

who needs to like be able to like read their documentation very well. And so far we have received positive responses, feedback from our surveys that communities find it like easier to participate in Outreachy because it's not only help them to improve their practices, it's also help them to onboard more persons

to contribute to their projects and to use their projects in a very awesome way. This is the time Outreachy is one of the, then I've mentioned initiatives that have been practicing accessible documentation so far.

And Outreachy is one of the initiatives that has been successful in that aspect and not just us doing it alone, but also doing it with other open source and open science projects. Thank you. I think we have come to the end of the slides. Okay, so thank you so much everyone

for coming to our show on. Now we are going to be taking questions and then if you have any questions for us, we are going to need more contribution. Thank you Omohola and Zainab for your presentation, actually very important presentation.

Thank you so much. For audience, online audience, please put your questions in the chat. I can bring them out for the speakers. In the meantime, anyone in the room have a question? If there's a question, you can, there's no microphone just. So my question is like, maintaining documentation and getting it updated regularly

is always a challenge. And I would think even more so in the accessible area because it becomes very confusing for people when the documentation doesn't match their actual experience. Do you have any recommendations on how you approach keeping documentation up to date?

So I'm going to answer that question. So yes, I think one of the best ways to achieve that is by creating a good back route or loop with your community. So when you have your documentation,

it's also important for you to have things like support, you know, help decks, places that people can easily like ask questions and, you know, suggest improvements to the documentation also. And then when you are creating your processes

for your products or feature updates, it's very important that you attach documentation to that process and not make it a different process entirely on its own. So that when things are going out, your documentation is also updated.

And then as process for your documentation, you can now have your style guides, your checks, your accessibility guidelines that technical writers or contributors can use when they are contributing to your documentation and working on your documentation. And through the process of creating that document, cause you know, for creating technical document,

a technical writer creates, somebody has to review, someone has to approve those PRs. So the people that are responsible for approving the PRs, merging the documentation should also be aware of these guidelines and use them to ensure that these guidelines are adhered to when creating the document.

And then you have your feedback from your users if there's any feedback from them, you have your support channels. I know within open source communities, most people are responsible to achieve this. I'm also going to add to that, one of the ways to like,

to add to what Zainab has mentioned is to involve the target audience. So if you are looking at persons who have visual impairments, you might want, when you're creating that kind of documentation, people who understand, who probably are using screen reader as well, make them part of the people documented that

so that they can understand. So one thing that's what she does is, we have on our team, persons who use screen reader. And when we review projects, that those are the things we push it to the person and say, how do you feel using this project? How do you feel contributing to this project? So that you'll be able to like, get feedback directly from the persons involved.

Thank you so much. And any other questions? Did it answer your question? Yes. I don't have a question, but I would just like to echo the sentiment that you mentioned about Outreachy and how it helps improve documentation in projects.

Even if it's not a direct project, I have been working with Fedora as an Outreachy intern, a mentor and now a community coordinator. And in the past four years I've seen that every round we participate in Outreachy and we realize that we need to upgrade our documentation or we need to improve it

because we always find some sort of barriers or some gaps that we discovered during the contribution period. So I think that's clear that that definitely helps improve our documentation. Thank you so much for adding this. Thank you. We're out of time.

So again, Motorola and Zainab, thanks a lot for doing the presentation. Thank you. Thank you.