A11y Need Is Love (But Accessible Docs Help Too)

Speaker 1 [00:08]

Okay, hi, I'm Smeera. I'm a UX and accessibility designer at Quonsight Labs, and I work on data science-related open-source tools. I'll be honest, I'm quite nervous. Public speaking terrifies me. This is my first time giving a talk in a room this big. All my previous talks were smaller, and also the audience was mostly filled with my friends who were there for moral support rather than my talk. So if it's okay with all of you for the next 45 minutes, I'm going to pretend that you're all my friends and that you're here for moral support. You're not here to actually listen to my talk, but only for the next 45 minutes. I don't want anyone coming up to me to ask for money after this. Okay. Quick pulse check. How many of you have ever used documentation? Okay. That should be pretty much everyone, unless you have somehow managed to understand every library through pure intuition, in which case I would need to talk to you after this. So I think we can all agree that documentation is an important part of every project and is used by a lot of people. But today, let's talk about what it means to design documentation for everyone. Let's start by talking about needs. What do human beings actually need? So Maslow, an American psychologist, tried to answer that question and he came up with this pyramid that starts with basic stuff that human beings need like food and safety and goes all the way up to uh self-actualization love belonging all of those things i started thinking okay what would other such pyramids look like this clearly this is not super current this doesn't even have wi-fi in there so because we are in germany i thought it would be fun to think about the german model of needs this is based on me being in germany for the past three years and a lot talking to a lot of german people with. It would probably look something like this. So you have currywurst, you have sparkling water, and you have luftin, okay? That's very important. You cannot forget. Fifteen minutes twice a day, your landlord will thank you. Trust me. And since we are talking about documentation today, here's what that model would look like. So you start from features like accurate content, And you go all the way up to more wanted features like theming and dark mode. And perched on the very top right there is accessibility. It's the cherry we sprinkle on once everything else feels done. It's nice to have, but something we'll get to later, right, when we have the time, the budget, or the motivation. But for many people, accessibility isn't a bonus. what allows them to use documentation sites at all. So we think of it as the cherry, but I think that it should actually be in the foundation. So let's start with the basics. What does accessibility even mean? Before I move on, I want to do a quick poll. How many of you consider yourselves beginners in accessibility? Okay. Intermediate? Okay. Experts? Okay, good. I would have to ask you to leave because I don't want experts fact-checking this. It's fine, friends. Don't fact-check, friends. So at its core, accessibility means removing barriers. It's about making sure that people can actually use what you build, no matter how they interact with it. So that includes folks using screen readers, keyboards, voice commands, and even someone who's scrolling on their phone with one hand while standing in a crowded train. In tech, we often think of users in a very specific model way, but accessibility asks, oh, I think it's something. Oh yeah, it's my glasses. Oh, should have thought about that. They should make like headsets for people with glasses because that's almost exclusively 100% of their audience.

Speaker 2 [04:19]

Can you handle it or should you...

Speaker 1 [04:21]

or should you use the handheld microphone? I think, oh yeah.

Speaker 2 [04:24]

I will bring it in front with you, okay?

Speaker 1 [04:26]

front with you, okay? That's fine. Okay, where were we? Accessibility, removing barriers, yes. Okay, we were talking about users. So we tend to think of users in a very specific and a very model way, but accessibility asks us to take a step back to consider different abilities, different devices, different environments, different contexts. So, a lot of people hear accessibility and immediately think it's just about people who have a permanent physical disability. And that's definitely accurate, but it can be a very limiting view. Accessibility isn't just about disability, it's about ability in context. So what do we actually mean by that? We tend to think of disability as a fixed, permanent thing, but in reality it's often fluid. It can be permanent, like someone born with one arm. It can be temporary, someone who broke an arm, or situational, like holding a baby. These people have the same contextual ability, and all of them benefit from accessible design. So when you solve for one, you're actually solving for many. So now that we know who benefits from accessibility work, let's talk about the real battleground, documentation. Specifically, why documentation can be surprisingly tricky when it comes to accessibility. Documentation sites are kind of weird. They're not flashy. They're not super interactive, and yet they're one of the most essential parts of any project. I think we can agree on that. They're where people go when they're stuck, confused, or learning something for the very first time. And because of that, how we design documentation really matters. These sites tend to be really text-heavy, often dense. People are scanning, searching, they're copying code, they're switching between sections, sometimes on a laptop, sometimes in a mobile, sometimes they're hoping that a page loads in a hotel lobby right before they're about to give a talk in a conference. You know, everyday experiences. So in short, talks are dense, functional, and often accessed under pressure, which means that if they're not accessible, then they break at the exact moment someone needs them the most. So despite how crucial docs are, accessibility issues in documentations are very common and often unnoticed. So it's easy to assume that because these sites are simple, they're fine by default. But simplicity doesn't guarantee accessibility. In fact, I can tell you from experience, it's usually the opposite. You'll find low contrast text, missing focus indicators, headings might look structured, but they aren't navigable for screen readers. buttons with no labels, links that just say click here, and search overlays that trap keyboard focus. So the thing is, these aren't malicious decisions. They're just defaults or oversights, assumptions like it's just docs. How bad can it really be? Those assumptions do come at a cost because for someone who needs the documentation to work reliably, every one of those little oversights adds friction and may actually make the whole site unusable. So at this point, I hope we're all on the same page about what accessibility means, who benefits from it, and that accessible docs are important. So if I've managed to make you even a tiny bit excited about accessibility work, and I hope I did, you might be thinking, where do we start? Well, as Julie Andrews says, let's start at the very beginning, a very good place to start. Accessibility audits are a really common and flexible practice. They help you figure out what's not working before you actually start fixing things, and they help you see how users with disabilities might be experiencing your website. So the great thing is audits can be as big or as small as you need them to be. If you've only got a little time, you can do a quick check, or if you've got more resources, more people, more money, you can do something much more in-depth. That's up to you. There are three broad ways to run an audit. It can be manual, automated, or a hybrid mode. You can use automated tools to catch common issues, or you can do both manual and automated, which is usually what most teams end up doing. The best part is that there are a lot of really solid free tools for our auditing accessibility. You don't really need a budget, you just need a browser and a little time. The one that we're going to use today for the live audit in a bit is the Microsoft Accessibility Insights for WebTools. But there are other tools that you can use like AxtEvTools, Lighthouse, and of course, manual testing, which is essential, but it's a little bit more involved. I didn't do anything. You're back. So, if you're just starting out with accessibility, I usually recommend starting with automated tools. They not only help you catch common issues, but they also help you learn about accessibility guidelines as you go. So they'll point out problems, tell you why it's important to fix them, and then guide you through fixing them as well. Manual testing, on the other hand, is a little bit more involved. It requires more familiarity with web content accessibility guidelines or the WCAG standards. Some issues are technical and more nuanced. So if you're not already comfortable with accessibility, it might be easy to miss things. That said, most tools today actually blend both approaches. They guide you through manual checks and they ask you to test specific interactions and then mark them as pass or fail. So even if you're not an expert, the tool teaches you as you go. And if you can, nothing replaces testing with real users with disabilities. Even a technically perfect audit doesn't guarantee a usable experience. One second. Okay. There's a great example of this. A team had worked really hard on accessibility for an open source Linux distro. Okay. everything, contrast, keyboard navigation, screen reader accessibility. But when a blind user tried to install their OS, they couldn't do it because the option to start the screen reader was missing from the installation process. So even though that distro was technically accessible, they actually couldn't use it because they couldn't install it. That's why it's important to test with real users whenever possible and that's why audits are just the beginning. So far, we've been talking principles, but let's be practical about it. I'm going to walk you through a project that we did at QuantSight Labs, and I'm guessing that many of you have used the outcome of it without even realizing because it's a theme that may be familiar to a lot of you, the PyData Sphinx theme. So it's a clean, readable documentation theme that is built on top of Sphinx. It's used by a lot of big-name projects like Pandas, Jupyter, Bokeh, and it's designed to be clean and minimal, focusing on technical readability. And because it's widely adopted, it forms the foundation for documentation across the scientific Python ecosystem. So when we talk about accessibility and documentation, the team is a really impactful place to start. So we focus on improving defaults in the PyData Sphinx theme, so that projects could start from a place that already considers users with low vision, color blindness, or screen readers. The goal was to make these improvements reusable and so that other maintainers don't need to reinvent the wheel. They can build on top of what's already been made more accessible. So the first step was understanding how accessible the theme was in the current state. So we started with an audit using Accessibility Insights. Accessibility Insights actually organizes issues into really helpful categories like headings, landmarks, keyboard focus, and that gives us a roadmap of what needed to be fixed. And from there, we translated these into GitHub issues, a lot of GitHub issues. And as someone who opened these issues, I have some tips about opening accessibility-related GitHub issues. First, be specific. Mention the exact page, the element, and what's failing. So try to avoid saying vague things like contrast issues on homepage. It's better if you actually spell it out. Next, try to reference the tools or standards. Say that it fails WCAG 1.4.1, 4.3 or the contrast ratio is below 4.5 to 1 and include the link if possible. I know a lot of people might not be familiar with standards, but if you are or if you can find the source, it's really helpful to help educate more people about why a certain thing is failing and how they can fix it. And also screenshots that save everyone time. even better if you can add a screen recording to show how the issue affects people who are using keyboard navigation or screen readers. And if you know what the fix is, suggest it. But if you're not sure, that's totally fine. You can just flag it and say, I don't know the fix, but this needs to be fixed. And finally, obviously, use labels. Those are standard GitHub etiquettes. Makes your repo more welcoming to contributors, especially people who are starting out in accessibility and might be looking for repos, but they can contribute to accessibility. So now that we had identified issues and converted them into GitHub tickets, it was time for the actual work. There were obviously a lot of changes across both design and development, but today I want to focus on two things that we fixed in particular, because they're common, and we probably encountered them in your documentation sites as well, color and interactive states. So when we started working on accessibility in this project, we looked at a number of different areas. Keyboard navigation, screen reader support, semantic HTML. But two things that came up again and again were color contrast and interactive states. UI elements weren't always readable or clear, and feedback cues like hover or focus were missing or too subtle. That meant users couldn't always tell what was clickable or where they were on the page. Our first fix was around color. We ran contrast checks and found a lot of violations. We used our color system to fix this at scale, aligning with the WCAG thresholds, which is 4.5 to 1 contrast for normal text and 3 to 1 contrast for large text and UI components like buttons. Having a color system helped us fix this at scale, so I want to pause here and talk about that for a minute. We worked with four main colors, teal, violet, pink, and gray. In your project, you might be working with brand colors too, and often that's where the problem begins, because brand colors aren't always accessible by default. So how do you stay on brand and meet the color contrast requirements? So what we did and what we recommend is using a color system. So that means extending each brand color into a full color palette of shades from lightest, number 50, to darkest, number 900. So with this system, instead of guessing or tweaking colors ad hoc, you already have a lot of predefined options to work with, And this makes it easier to meet contrast requirements and also creates a visual cohesion. So it's a win-win. Because if you're using different tints of the same base color, the interface feels unified and on brand. If you were to ask me how to create this color system, I would ask you to give me a three-hour workshop slot and then some. This definitely takes a lot of time and effort, but it pays off every time you need to make any stylistic changes or roll out completely new changes as well. so we just spent a good few minutes talking about color but here's the thing you cannot rely on color alone i know after everything that you did you set up your color system but i'm saying okay you need to throw it out because even if your contrast is perfect color alone doesn't help people with color blindness low vision or anyone who's using a screen reader so for people to actually use your interface they need feedback that goes beyond color and especially when we talk about interactive states. What do I mean when I say interactive states? Anytime there's a component that a user can interact with, like a button, it has different states. There's a default state, there's a hover state when you mouse over it, there's an active or a press state when you click on it, and there's a disabled state and a focus state. That is when you navigate to it using your keyboard focus or that is usually the tab key. These states might seem minor, but they're how users understand what something does and whether it's doing anything at all. A common pattern that we saw was that hover states relied entirely on color to indicate state change, so that a button would go from a teal color to a slightly darker teal color on hover. That's a problem for users with color vision deficiencies because they may not see any difference. It would look something like this. If you have red color blindness, that's what it looks like and that's not a big color shift. Also, it's a VACAG issue. There's a guideline that asks you to have a minimum of 3-to-1 contrast when you're talking about hover color changes. Now, that 3-to-1 contrast is actually very hard to hit. So if you were to do that for this button, that is what it would look like. And that completely changes the way the button looks. It can be disorienting for someone to hover on a button. It just turns completely dark. So the best approach is to add another visual indicator, like an underline. So we use that approach a lot, especially for buttons. That way, users don't need to rely on color alone to understand that something is interactive or that they're triggering an interaction. Focus states were another big area. In a lot of places, they were missing or too faint. So we focused on making sure that we had visible and consistent focus indicators across buttons, links, navs, inputs, et cetera. So there are specific rules here. There are a lot of rules here, actually. outline should be at least two pixels in stroke width they should have a minimum of three to one contrast that doesn't work and if the outline touches the element it also needs to contrast with the element so there's a lot to remember about this but we build these styles once and reuse them consistently across the team so that actually saved everyone sanity we got a lot of feedback some Some were positive, some weren't, but we were glad for all of them. The positive feedback further validated our work, that what we are doing is important. And critical feedback gave us a chance to improve. I believe accessibility is a continuous process. So this feedback helps us figure out what's working, what's not, and how we can improve it. So if you're using a theme, any theme, not just the PyData Sphinx theme, I would urge you to give feedback to the maintainers to help them and so that you also have access to an improved theme. So the real challenge wasn't actually making the changes, it was making sure that the changes stick and so that they don't actually disappear when someone updates the CSS. So we focused on making the fixes visible and reusable. We wanted to ensure that the contributors working on this theme would have access to good defaults. And for anyone building their team, we wanted to offer examples and resources so that they could also pick that up. And so we created a public design system on Figma. It includes color tokens, typography components, everything that we used in the PyData Sphinx theme, and accessibility is built into every layer by default. So this isn't a perfect or final document. It evolves alongside the theme. When we fix a contrast issue, we rethink focus styles, or we update the design system to reflect those changes. We also have public documentation for the design system itself. It tries to explain how to use the design system and some of the thought process behind our design decisions. The goal of this is to help contributors, especially those who aren't accessibility experts, make good decisions confidently, and to give other team authors a place to start if they're working on their own team design or components. So obviously this was a massive team effort. I want to give a shout out to all the people who contributed to this project in various ways, through design, through code, and most importantly, through money. Here comes the part where I live dangerously. I didn't script this at all. I have no idea what we'll find, but let's do a live audit together. We're going to use Microsoft Accessibility Insights. To make this more fun, we can take suggestion from the room. If there's a documentation site that you would like me to check, we can do that. Or, as a backup, I have the PyCon DE website because I'm pretty sure everyone in this room has accessed it at least once. So it would be fun to take a look at it, but I do not want to make the organizers angry. So does anyone have any documentation website or should we just go with PyCon DE? Okay. Okay. Sure. You have to help me if they come after me, though. Okay. I will make a quick exit after this. Okay. Let me, actually, I already had this open because I thought everyone would like it actually. So this is the PyCon DE website, and right here I have the Microsoft Accessibility Insights browser tool. So this is going to sound like I'm trying to make a sales pitch for this, but it's not true. It's just that I really like using this tool. It's open source. But whatever we talk about today can be applied to other similar tools as well. So Accessibility Insights offers different kinds of assessments depending on how much time you have. So you have FastPass, which is like finding the most common accessibility issues within five minutes. You have QuickSS, so that's like slightly longer but not super detailed, and then you have Assessment, which takes a really long time but obviously gives you a lot more details about issues with accessibility in your website. And then you also have ad hoc tools. So individually, if you want to check color contrast and landmark things, that's where that goes. So we can start with FastPass, I think. I'm going to also duplicate my screen so that I can see what I'm actually doing. Okay, that disappeared. okay so fast pass okay how many of you think that this website is accessible or at least like okay let's let's start with the percentage 100 accessible okay 80 okay 70 50 30, 40, 30, 20, zero. Okay. Okay. So this obviously works much better if you have, like, two screens. I'm going to do a split screen. Yeah. So we have 33 failed instances, 32 of which are color contrast. I would count this as one failure issue that this issue with colors is most likely the same colors being used again and again. Also, the PyCon DE website actually has a lot of colors, which is very hard when you have to make sure that you are maintaining color contrast across all the different elements. So the way this works is you have visual helpers. It kind of looks funky because it's sort of split screen, but I can turn this off. so this actually helps you understand where the issues are occurring and so for example the heading um has insufficient color contrast of 1.91 to the background and which should be three to one uh which is again like it does not look like it has a low contrast but it actually does um the good part about my accessibility insight is also suggests fixes so you can use this color as the new background color to make sure that you have a higher contrast and if you go through this you will see other issues as well wait i'm gonna most likely it's going to be yeah so most of these issues are with this color against the background and the background keeps changing so it's hard to maintain consistent color contrast in this case you could actually add a highlight right behind this so that even though the background color keeps changing your text has a consistent background so you could have like a black or a dark colored text box with white text. So you have the colorful background, but you also have minimum color contrast. There's another failure, which is every form element has a label. So there is an input label somewhere. Okay, this is not perfect, but there is a label somewhere, an input form somewhere. Maybe it's hidden, but Accessibility Insights is picking it up. That's okay. So then there are tab stops. Okay, this is an example of a manual test. So this test actually requires us to use a keyboard and then it helps you guide through this. This is a lot of text to go through, but when you go through it, it actually tells you what to do and how to interpret your results. And then you can mark them as pass or fail. There is some failed instances, or it might just be because when I was trying to run this audit in my room. So the way tab stops work is, it should be right here. Okay, you can actually click on this, which is really cool, and it tells you why it matters, what you should ideally do, and what not to do. I think this is so great to learn about accessibility, different standards, and all of this, they actually link you back to the standards and guidelines, which is pretty cool. All right, so we don't have a lot of time left to do this whole thing. I'm gonna show you quickly the other assessments. So this is more, again, you start with automated checks and then you have keyboard, link purpose, image function, UI components, And all of these help you mark a component as pass or fail. And this is the 30-minute one. This is the really in-depth one. This is quite big. This is what we did for PyData Sphinx theme. Every heading has multiple tests to go through. But a lot of them are actually very easy to go through. For example, Sensory, if you don't have a lot of multimedia elements on your website, then you can actually very quickly go through this and mark this as pass. All right. I also wanted to show you the ad hoc tools because I think they're pretty great. So if you just want to run automated checks, that takes like two minutes. That's what it does. if you want to test headings it actually marks all the headings here um for example you can only have one heading one h1 heading on a page which is fine here because we don't have an h1 and yeah so you have different uh accessibility tests here and you can go through them at your own pace at their own um resources depending on what you how much time you have how much budget you have but I think it's very great to even just start with the automated checks to see how we can improve for PyCon DE 2026. I will go back to my slides. Okay, so we have covered a lot. Let's recap the good stuff before we end. Documentation is where people go to learn, debug, and explore. If it's inaccessible, the entire experience suffers, even if your code is perfect. Accessibility isn't just a feature, it's a baseline. It needs to be considered from the very start and not added in later. When we build reusable systems like design tokens or shared components, we make it easier for everyone to get accessibility right. And most importantly, we grow through community feedback. That's what helped us improve, and it's what will keep making these themes better. What you can do next. So accessibility work can feel overwhelming, but you don't have to do everything at once. Start with a very small audit of your docs or website. just 10 minutes, five minutes, even just run the automated checks. If you're not maintaining the site, you can open an issue. You can mention this in the Discord channel and ask the volunteers to make sure that we meet the color contrast for next year's website. If you're a maintainer, review your heading structure and focus tiles. They are high impact and low effort. You can also check out and reuse the PyData design system because we spent a lot of time working on it, and I think it's pretty good. And also, I would love to get feedback on it. And finally, just talk about accessibility. Bring it into your contributor conversations, PR reviews, planning meetings, go to conferences, force people to listen to you, talk about accessibility for 45 minutes. That alone makes a lot of difference. Okay, thank you so much for being here and for caring about accessibility. I would love to take any questions, only the easy ones though.

Speaker 2 [32:14]

Thank you so much. Thank you so much, Meera. I was so scared to share our website because I thought you're going to rip it off, but you're very polite with Python, PyCon.

Speaker 1 [32:26]

I want to be invited next year.

Speaker 2 [32:28]

Definitely and also wasn't really sure that there are so many accessibility tests when it comes to documentation So it was really a good session and also one of the energetic and the interactive sessions I've seen so far in the conference. So I've got like 12 questions. So which means Yeah, making so much attention. So I'll quickly get it to that. We've got 10 more minutes. So it's fine The first question is dark mode good or bad?

Speaker 1 [32:55]

bad dark mode is actually very good it's also one of the most uh i would say mainstream forms of accessibility a lot of people don't do well with bright text and you could actually consider dark mode as another form of accessibility what i don't like is not having an option so just dark mode websites are just like light mode websites it's important to give the your user the chance to choose that um so yeah if you have the resources to work on it it's pretty great Thank you.

Speaker 2 [33:25]

And the next one, have you experienced maintainers refusing to adapt usability standards?

Speaker 1 [33:33]

not outright refusal. I mean, a lot of them do say that they don't have the time or resources. They're happy to merge the PR as long as someone else does the work. Because obviously, like for a lot of people, if they're not familiar with accessibility, this can seem like a very big process. Like first, I have to learn what is wrong, then actually learn how to fix it, then fix it. So for maintainers, they have a lot to do. And I understand that. But no, not outright refusal. some of them do have preferences they say okay i for example if there's a color that that is not accessible and you mention that and it's like you know what but i really like this yellow and i want to use that then when you link to the vocabulary guidelines they can't really rely on color preferences because you have a solid argument against that so that would what i say is like if they are refusing you can actually go and lawyer up a little bit if you want to Yeah.

Speaker 2 [34:32]

I think that's the easiest way right so next one what does a contrast of one ratio three mean how do you measure this

Speaker 1 [34:39]

share this so a contrast oh that's a very good question i should have uh explained this so contrast ratio of three to one for example means contrast between two colors usually the foreground color and the background color so for example if you have like this text right here this is white and the background is purple uh the contrast of this these two colors should be three to one for it to to pass accessibility standards and that's what it means how do i get these contrasts there lot of great tools a lot of free tools and our browser extensions as well you can actually I'm gonna try and see if you can do that quickly so the web in contrast checker and all you need to do is plug in your foreground value your background value and it gives you the contrast ratio and if you have something that does not have the correct ratio tells you where it fails why it fails and then you can then it also gives you a very nice explanation there are some tools that also automatically correct the colors but I would avoid using them because they don't actually they might correct it to something that is not a part of a design system so that would mean making a lot of ad hoc corrections so a lot of different shades of blue or teal in your project

Speaker 2 [36:03]

Yeah quite visual explanation The next one isn't figma update product. How would you suggest that other open source projects create a design system?

Speaker 1 [36:14]

I was anticipating this a little bit. Figma is a paid product. Unfortunately, not a lot. There are obviously some tools in open source. For example, PenPod exists. It is not quite there yet to use it on a commercial level, but you can use it for personal projects. If you want to use something that is completely open source, you have a great suite of design tools. Unfortunately, because this was a professional project and because we had to collaborate with a lot of people who may not be using all open source tools, we did use Figma and also because it is more mainstream. But if you want to use open source, then you have Penpot and you have Inkscape, you have GIMP, and you have a great design suite there. So if you want to maintain your design system on that, and I know a lot of projects too. I know the Fedora project maintains their design system on Penpot. So that's actually something that you can do.

Speaker 2 [37:14]

Thank you. It looks like Petpot also has a pricing strategy.

Speaker 1 [37:18]

So that they can continue to distribute it open source. So that's like I think their enterprise model.

Speaker 2 [37:25]

And the next question, I think I also had the similar one. So the question is, accessibility is also about content. Yeah. So in this respect, do you recommend splitting developer and user documentations or having a combined documentation?

Speaker 1 [37:38]

I think it's a very good question. I think you should split it because a lot of content actually focuses on developers and not consumers. When you have consumer or user-focused content, that makes it more accessible for people who might not be familiar with a lot of things. For example, my colleague Pavitra Srimuti, who's right there, she works on the Bokeh project and I work with her on that. And that is something that we talk about a lot because a lot of Bokeh documentation focuses on developers who are creating those data, visualizations, but not enough documentation on people who are actually consuming or using those visualizations. Even I was confused when I was using some bokeh plots and I was like, okay, what does this button do? How do I get to do this? There were not enough docs. Content absolutely is a part of accessibility, and if you can separate it, that's great. If you have the time, please do it.

Speaker 2 [38:31]

Thank you. The next one, is it possible to run a tool that checks accessibility as part of pull request to help with making changes?

Speaker 1 [38:38]

if there is please tell me um i do think there are a lot of developer tools that aid in that i do think that there's a some amount of manual effort to set it up unfortunately i'm not a developer so i can't speak to that um but i do know that the developer i worked with had set up some automations to help with these pr checks so not i don't think there's a full suite of it ideally there should be something on github native that does it for you that's that's the dream um but yeah i think there's something but not quite there yet

Speaker 2 [39:14]

The next one. Thanks for raising this important issue. You talked a lot about visual impairment So what other disabilities should we keep in mind when designing dogs?

Speaker 1 [39:25]

that's a very good question so i would say because we talked about content it's good to have okay this is might cross a little bit into localization but if you can translate your docs that's also making sure that you're including a lot of other people who might not have english as their first language there is cognitive accessibility which is something quite far down the line when it comes to working with accessibility but equally important a lot of people who are consuming docs may not have the same level of cognition as you would expect a regular user to and so if you can for example design documentation websites that don't have a lot of flashing elements a lot of animations and actually make it very direct and clear and easy for you to just find what you're looking for use it and get to it which documentation sites usually do that would be great Thank you.

Speaker 2 [40:17]

Yeah, thank you. So we've got only two more minutes, but I see there are seven more questions Not really sure if we'll be able to make

Speaker 1 [40:25]

All of them? It's like rapid fire.

Speaker 2 [40:27]

okay so okay let's make the rapid fire then so how do you come up with a who palette

Speaker 1 [40:27]

Okay. Who valid? Who asked this? Hugh. Hugh valid. I told you, I cannot answer this. If you give me three hours, I cannot answer this. I'm still working on it. It takes so much time, but there are a lot of tools. But this is a rapid fire, so if you want, you can e-mail me, or we can talk about this because this is something that I'm still working on.

Speaker 2 [40:55]

Yeah, if we already use PyData spinx theme with the default CSS, is there anything else that we should keep an eye on to improve accessibility?

Speaker 1 [40:55]

Yeah. accessibility if you're changing if you're if you're using the default css it should be fine but obviously if you're using some components which might not be in our kitchen sink things can break so if you just run like the regular quick assessments that should be fine if you're changing the css you have to run it again obviously so try not to do it which

Speaker 2 [41:20]

Which companies apart from Quincyte Labs are working on accessibility?

Speaker 1 [41:24]

Okay, apart from Quinsight Labs.

Speaker 2 [41:28]

We've got a little promotion there.

Speaker 1 [41:31]

I think there are a lot of companies. I can't think of anything off the top of my head, but there are companies who are funding this. For example, the Chan Zuckerberg Institute funded this project. We're also working on another accessibility project that is funded by them. So, yeah, but there are other companies. I know there's DQ, which is D-E-Q-U-E-U-E. I feel like I'm in a spelling bee now. Okay. Okay.

Speaker 2 [41:53]

The next one, thanks for doing all the work on the theme. In which version of the PyData Spinix theme is your work included?

Speaker 1 [41:59]

included oh I think that's actually come it's across a lot of different versions but if you go past like third version 13 that's where you really start to see the difference but there were a lot of like these changes weren't merged in at once so this is the current one if you go to like 13.3 you can see that there's a very big difference but I think from here onwards you can start to see the color difference yeah you see the difference um so i think from this onwards uh but obviously the best one is the more stable one yeah you can see the underline changed yeah

Speaker 2 [42:38]

Yeah, I think they would like to audit your work, I guess. Okay, oh no. How can I convince managers that accessibility is not just cost, but an investment, especially for internal apps with only few users?

Speaker 1 [42:48]

Threaten them with legal action. It's actually, yeah, for a lot of government websites, it's actually you have to comply. There's a legal law to make sure that your website is accessible. So there's that. And also, when you make it accessible, you just get more users. So that's like simple economics, I think. More users, more money.

Speaker 2 [43:13]

Okay, so I think we are over one minute.

Speaker 1 [43:13]

Bye.

Speaker 2 [43:15]

So thank you so much for all the answers. And please, a round of applause to Smita. Thank you.