Leia Ruffini, Juan Ruitiña – Real accessibility: an imperfect, honest journey #FOSSBack

This talk explores the journey of improving accessibility practices at Canonical, focusing on their work with the Ubuntu desktop operating system. The speakers, Juan and Leia, both UX designers, emphasize the importance of considering various disabilities—sensory, physical, cognitive—as well as social constraints in product design. They share insights gained from creating an accessibility guild to foster knowledge sharing among team members, conducting audits to assess the current state of accessibility, and developing guidelines tailored to their specific tools and applications. The session also discusses the role of diverse teams in enhancing accessibility and highlights the need for continuous improvement and integration of accessibility into all stages of product development. They encourage the audience to start small and progressively enhance accessibility efforts, stressing it as a measure of excellence in design rather than a mere compliance requirement.

So yeah, today we're here to share our journey with accessibility. Uh but before we start, I wanted to ask a couple questions to see, you know, what kind of room we have. So raise your hand if you have some concept about Okay, that's good. Couple hands. Um, and how many of you are taking accessibility practices into account when you're coding or designing? Okay, about the same number.

That's great. Half of the room. That's good. And then how many of you work in a team that has accessibility processes and checks inside the way you're doing work? Yeah, that's usually how it goes. Um because yeah, we made some assumptions about what kind of people would want to learn more about this. And we found that a lot of people know about accessibility and care about it,

but don't know how to start concretely on how to integrate it with their day-to-day work and how to get more people excited about it because on your own there is only so much you can do. Um so yeah we are going to talk about just that today and how we improved the accessibility practice at canonical uh because this is where we work. Um so this is Juan.

He's a UX designer for the Ubuntu desktop operating system and I'm Leia and I'm also a UX designer and I work on our open source application stores like the snap store. Uh so yeah we have quite a bit to cover today. uh we'll go over a bit of context about accessibility, what we have done so far, what we have learned and then we share some insights um

and some resources at the end. So let's start with a bit of context. Accessibility is a very broad term and it's the idea of making sure that anybody can use tools as best as possible. So it include taking into account constraints like uh sensory disabilities like blindness like physical disabilities like motor issues but also cognitive disabilities like ADHD or memory loss as well as social constraints like

economic prospects tech access literacy these kind of things and so these constraints can be permanent temporary or situational which creates very complex web of interactions because often time we tend to think about these things in isolation, but that's not how it works in real life. Some of these conditions have coorbidities that makes multiple aspect come together. And there's also cases where people find themselves in environments that

are adding or detracting to their experience. So, for example, a blind person might rely on voice assistant to use a tool, but if they're in a noisy environment, they might not be able to use it as effectly as effectively. Or someone who's usually wearing glasses might forget them at home and then not be able to see anything what's going on on their phone. So that's why compliance,

legal compliance cannot be the only criteria for accessibility because you can check all the boxes of an audit uh or an industry standard, but it might not be sufficient to actually provide an experience that makes sense for real people in real situations. It's great to have regulations because it raises the minimum for everyone, but it's not the end of the road. It's just the beginning. Um, when

we talk about accessibility, there are some concepts that are more well-known usually because there are some regulations that are based on them. So things like the web content accessibility guidelines or the way to choose color palettes, so contrast issues are not a problem. Um, but there is a lot more and as I said, cognitive disabilities are often not taken into account. There's also not always a way

to interact with non-web tools that are not just like you know keyboard navigation uh or voice assistance. Um, and the ways to implement these things into these tools are not often super well documented beyond four web platforms because yeah, working on our different projects, we realized that there is not a whole lot of guidance on digital accessibility beyond what you can find for people building websites or

web- based application. So things like the um WIKAG are really good guidelines as a baseline and you have companies like Microsoft that publish more information about how they approach the their accessibility practice but yeah there isn't a lot of information on best practices for things like native applications or operating >> and it was precisely when we're looking to assess the state of accessibility in Ubuntu desktop that

we needed to deal with these uncertainties about how to do it best. So well we work for Canonical. Canonical is a rather big open source company. Um but at the same time we think that most of the learnings uh that we are presenting today to you can be useful for any project or company big or small. So our accessibility journey started like some five years ago and

it happened uh with colleagues coming together to share their knowledge in a community of interest around accessibility. We call that the accessibility guild. So um this put together people across disciplines across all teams and this is actually the first suggestion that we make to you which is identify in your team who is interested interested in accessibility and create a space for you to share knowledge and and

feedback and and resources. uh it's a loweffort way to to start to kick off this process this journey and it also helps you raise awareness in your company about all these issues. Um there's in our case there's no pressure to the liver we just have a a monthly meeting where we get together and again share all these no commitments but it's a way to to make sure

that there's someone that can help us out. Actually guild members have also even doing some public speaking which can be good precisely for awareness in the company. uh we have lightning talks similar to what happened here yesterday um every six months in canonical. So even if not everyone is joining the guild uh we can still share our our knowledge and and all these resources even for those

that maybe they are not that familiar with it they know they exist and they know we exist so we can help them out. Um so Argill had been going going on for a while again some 5 years uh or so but then last year well Europe happened right and uh so the European accessibility act uh came into force in LA past June and by then we we

needed obviously to before that we needed to assess what was the state of Ubuntu desktop in terms of accessibility. So in order to do that um uh we we needed to conduct an audit. This uh this reminds me so much of the of my times dealing with the GDPR. So I guess that the European accessibility act was to to accessibility what GDPR was for privacy. Uh and

there was there was the need to do all these all these because you know in the end we have even it's not even about legal compliance. We are we're a company we have enterprise customers that demand this compliance and not only compliance but proof of it. So when we jumped into doing this this audit uh so the way audits work uh is that you identify certain critical

flows not necessarily critical but important flows in your product user flows. So you can think of features you can think of sometimes of apps and uh and you assess how whether or not they are compliant and how easy it is to to to use them based on by using assistive technologies or maybe in terms of of contrast and things like that. And so if you have a

budget and we did have a budget uh we you can do this uh this audit externally with an external agency um they have obviously experts that are uh that know perfectly how to check for uh we got criteria uh to check if if the stuff is accessible um it is true that then implementing the fixes for those issues that they have identified is on your team. So

even if you do this externally, I think it's always good to have that community of interest that can support you and can support every engineer in these teams to to to address these issues that have been identified. Um you can also do these audits internally. Um so there's great resources online um to to to do this yourself. It's also a great learning experience. Actually when we conducted

the audit for desktop we use a combination of both external and internal. So the the biggest scope was given to the external agency. Then we looked into it and incorporated it. But then um perhaps smaller features that we were identified as we went, we took care of them themselves. And they were great because they help us learn a lot also about how to conduct these audits. And

indeed uh this led us to think okay we learned so much during this. What can we do to build this into a accessibility alternative into an accessibility practice right? how can we make sure that this is not a one-off effort but rather uh the norm right so we took all those learnings and we created uh a couple of guides the first one was precisely for Ubuntu desktop

and this is important because again as Leia said uh most of the resources online are more targeted to web interfaces right so when we were reviewing uh the the UI in in Ubuntu desktop for instance we needed to learn how to use the assisted the assistive technology is that we ship with Ubuntu, right? So instead of u maybe screen readers that are more used like MVDA that

are Windows only, uh in the case of Ubuntu desktop, we rely on the Orca uh screen reader which is present in in many Linux distributions and we needed to teach ourselves how to use them, right? And our guides actually have that guidance. So um in a way we moved uh from from checking access our goal was to move from checking accessibility uh after the fact and rather

embedded into our processes and getting that familiarity with the tools uh was important. Uh we wanted to make it easy to uh to our engineers and designers to do the right thing right and and that's what the guides the purpose of the guides. So um again this Ubuntu guide we we published it. It's available um publicly. We will be sharing that in a minute. Uh so is

our web interface guide. That's perhaps more generic but it's true that most of our portfolio is I mean at least most of our interfaces have web- based. Uh so so we also incorporate it into into our design system. Um, we suggest that for those of you that feel comfortable maybe sharing your knowledge with your team, you can create your own guides tailored to your needs, to your

project, product. Um, or else you can just use other guidelines avail other guides available online. You can share them maybe with your with your community or in your maybe in your team's knowledge tools. So, Leia talked before about how compliance goes beyond compliant, right? And so if you want to be a bit more proactive about accessibility um one way to cover any gaps from from those strict

guidelines which are very good but but it's it's hard to leverage them uh as you should and cover any any case uh one way to to to to improve that uncover those gaps are tapping into the diversity of the people around you. So you can simulate constraints yourself in your testing to catch some of of those issues, but that cannot replace real life user testing and user

feedback. So you probably have family or friends that maybe uh they have they are color blind, maybe they are they are have low vision, maybe they have ADHD. And if you have if you work in a project or or company large enough, that's probably your colleagues. So our suggestion to you is that you talk to them, that you ask them, that you run your designs by them,

that you test your your prototypes or perhaps the the end product with them and uh and also that you invite them to share any issues that they face in your your repositors, right? Where most of us were working in the open. So we we think that's that's that's an advantage that we have that we should definitely leverage. And uh and of course and this is more for

companies perhaps although the community also has a responsibility to to to a big responsibility to welcome uh a diverse crowd. Companies have uh they they need to to hire diverse right um I think in design we're very well aware that a team that design team that is not diverse is inherently flawed and we could think that any team that is not diverse is flawed. Um so so

this is super important to to make this all happen. Uh but having a diverse team doesn't just happen overnight, right? You need to to provide accommodations. And so you should ask your candidates throughout the process what they need to be on an equal footing. But then it's also important that once you hire them that you also ask them what they need to make sure that they can,

you know, be effective in their daily work with all the right tools. So as we progress in our journey, we have identified some areas that we want to get at. We we get better at we we said it very honestly that is an imperfect journey. Um so we know for audits you know they tend to to focus on the surface right they they they identify certain certain

instances of an issue um without necessarily going to the root at least in the audit process. So sometimes you just need to fix that small thing maybe because it was an ad hoc implementation maybe it was an override that you did to some component uh but some other cases you need to look into your into your toolkits. So for instance UI toolkits um your design system and

making sure you apply the same controls to those tools is important to and and the most efficient way to address these issues. Um it's important not only because it's efficient, it's also because in that way you are willing to provide a more consistent accessible experience. So for instance in canonical uh web based products we use as as I mentioned a design system it's called vanilla and uh

vanilla has accessible styles built in like for instance buttons have enough contrast or they have the right states they have a focus ring. Um, beyond that, uh, we provide in the documentation code examples that already have, I mean, they're good examples, right, that incorporate, uh, good labeling, um, and stuff like that. Uh, and we even have in the documentation a specific tab covering how to implement that

component in an accessible manner. Um however our toolkit uh for apps in Ubuntu desktop um it is uh we use the this thing called Jaru and there's a GDK version of that and a flatter version of that. It's not as mature in this sense and we want to get better on that because we know that you know when you do this right is the best way to

cover at least to some extent to get compliant to be compliant out of the box. Actually there is an extra angle for to that for us which is you know these components are comes from from upstream right so uh that means that we need to work with community uh to negotiate sometimes um I'm pretty sure that that could be the case for many of you here that

work with I mean all our projects have plenty of dependencies and uh and this is a great opportunity to to not only fix things for yourself but obviously giving back and making sure that that other projects benefit from it. We have canonical engineers uh fixing issues that have been upstream to to Genome projects and obviously they are they will become in due time available uh in other

genome based distributions and obviously we have benefited from many many contributions in accessibility than upstream. Um so perhaps the biggest challenge yet for us is to incorporate all these more formally into our processes. uh we should ensure that accessibility is present in every phase of the process from design, engineering, implement um QA um and that it doesn't fall through the cracks, right? Again, that is not something

that happens after the fact and that doesn't rely on goodwill from the from the specific engineer or designer. So, uh we're looking for instance into integrated tests, but it is automated tools in accessibility are very controversial. uh they have a very uh limited range of things that they can cover um effectively and although we can get our hopes up with AI, we are pretty sure that that

manual reviews will still be needed. Um and that's what we want to embed into our processes. We are figuring this out. So if you if you have any experiences in your own teams uh dealing with all of these, please come to us, come talk to us after this and we'll be super happy to discuss this because we are we are learning. Um and finally uh we want

to engage more closely with our community uh by identifying any pending any pending issues. Same as we were talking about diversity, right? In the end it is when you put the product out in the world that that you see the cracks in there, right? And and and our community holds us accountable for that. So we obviously encourage everyone as we do to look into the repositories, monitor

into or in the forums, identify any accessibility issues that that may be may have been flagged by by users or community members and address them. Um and of course you could even be more proactive about that and do user research yourself, right? Uh you can arrange maybe you have in your team some researcher or you you're comfortable enough to do it. We have engineers doing user research

in Canonical. Uh that's that's that's remarkable. very very good to see uh and that in the end results in an actually uh accessible product that that serves real life people right and finally this this process this feedback also applies to the resources themselves right so as I said we're going to be sharing our guides in a minute and and if you have any feedback please share with

us um the Ubuntu guide is published in the Ubuntu uh project documentation so it's intended to be used by anyone one in the community and that's our intent right it's not that it's something for us but for everyone that contributes because there's thousands of people contributing uh in one way or another to to Ubuntu and I want them to be aware of this resource and to improve

it that's probably the most important part because we're just getting started uh so once again we welcome your help um feedback on any gaps that you find >> so yeah we have come a long way um and we still have a lot more to improve on. But if there is one thing that we really really want to highlight today is that yes, accessibility is a very wide

field and it can be intimidating. Um especially because it's so important for people to get it right. Um but it doesn't mean that you have to be perfect to start. Uh you can start small and then progressively improve your scope as we did at Canonicle. Guidelines are not perfect. Standards are not perfect either. a lot of the rules will apply or won't depending on what kind of

users you're dealing with. Um, but we can improve on them every day. And it's also important to keep in mind that um, even though you don't have to wait to build more accessible tools, it is not just a nice to have. It is really important to start considering accessibility as a measure of excellence um for product design or engineering at the same level as people really enjoying

beautiful visually striking interfaces and efficient secure code. So yeah, the best way to get more people involved is to help them understand that they don't need to know everything to participate. Every little step is a victory. One more person understanding how to work on focus states or understand what area labels do is progress and we need more of that. So don't afraid to don't be afraid to

be wrong. Uh instead you should be concerned if you're not doing anything. Um so yeah, we want to see others learn and share what they've learned as well so we can all be better together. And yeah, as promised, uh here are some of the resources we find helpful, some of the accessibility guides we have published. So you can find them at the link here, ubu.link/bererlin, or you

can scan the QR code. So yeah, that's it for us. Any questions? >> Maybe let's move to the right so the QR code can be scanned. >> Here you go. >> Yeah. Thanks again for this very important talk and I already see one question. >> Thank you both. Um I was I was wondering be because when we think about accessibility it's always about like people with disabilities

as well but um do you consider also power users you know like you know these users who never use a mouse but always go like quick click click click click with a keyboard is that part of your p practice as well? >> Definitely. Well, that's the thing with with accessibility. Making sure that you have different ways to interact with an interface is going to be beneficial for

everyone, even though you didn't initially intend it for a specific person. So, yeah, power users using keyboard stuff. That's actually kind of like the standard personas that we look at because we have like some very technical products. Um, but yeah. Yeah, that's part of the that's part of the picture >> and a design colleague actually flagged that up um that he was using keyboard navigation. Uh he

he's very reliant on it. Uh just because he prefers it, right? And well that's that's well known about accessibility. Uh well when something is accessible it becomes more accessible generally for everyone right it's not really a compromise quite the opposite right and um it can be that and I can I can also think for instance of colleagues um I have we had one doing a lightning talk

uh he had a temporary uh disability and then he got to explore uh things I think it was like voice control was it? voice control and uh remote pointer. >> So yeah, there there's this the situational and temporary um accessibility issues that that are generally an afterthought, maybe no thought about that um because maybe they are less obvious. They lead they lead us to to these and

then again it shows up that we have diverse team. Uh maybe at a certain time there's people that have specific needs, right? And and we're tapping on that and that helps us for instance in that case it'll help us have better focus states, right? um the but even on the quality level like this this he's a designer so he told us you know I expect the focus

rings to have always the same color or else it's confusing I just don't notice it as easily right and it was very very very helpful >> yeah thank you very much for sharing uh the work that you've been doing it's uh great to see companies this big uh making the effort and a bit connected to what he was saying uh I kept I don't I want to

hear your take on uh maybe a bit of a hot topic IC >> which is um so I really love this philosophy of solving for one extending to many right like this idea of okay I'm solving for this very specific persona but then everybody benefits from it uh do you think with the agentic workflows and agents going to use services and products people will be like investing

more and more in accessibility in the sense that an agent cannot see the UI they can like they need to understand how to navigate through a site or through service without using a keyboard, without seeing anything and needs to recognize patterns. Yeah. Area labels blah blah blah blah. How do you think this will impact uh accessibility? >> I think it's going to be really interesting. Um the

I mean there is like for example in in our marketing team there are some people thinking about like how do we create content to make sure that it's like crawable by AI and a lot of these are like these is like this is a simple question and here is a straightforward answer which is actually really nice even if you're not an AI agent to be able to

just go on an FAQ and be like oh that was a question I was wondering about and this is the easy answer. So, um we have seen that already very clearly in these areas. For design specifically, it's not necessarily that we're like spec like focusing on that, but um definitely that's going to become something more important and I think go ahead. >> I'm I'm I'm very cautious

about that. I mean, we talked a lot about awareness, right? So yeah, you may have the tools with the capacity like you can have models that maybe can help you with this kind of thing but if awareness is not part of the people designing the tool wrapping the the the LLM or or if you are not for instance I see the conflict for instance with the VI

coding right if you don't care about accessibility and you don't know about accessibility maybe the LLM spits out something that is more accessible than you would have right but that doesn't mean that it's sufficient right so I see still a lot of room for intent from whoever is creating these tools to make sure that it works. Um, of course, having an interface that is as flexible as

an as an agent or or a chatbot can help interpret things. I see a lot of potential for instance in terms of cognitive stuff, right? Like maybe um simpler language or things like that. But on the implementation in general of everything, if there's no awareness, I there there won't be an improvement out of the box on how things are working just because of AI or agents, right?

Um I think research asking questions will still be very helpful. You can feed that into whichever tool you're using that leverages AI, either as a production tool or as a something that is more facing the user, but the intent needs to be there. And I don't expect an LLM or or an agent by a bcoded agent to have that intent if we don't tell them to. Um

because the probably the data over which they were trained wasn't perfect either, right? Uh so u yeah I'm not skeptical. I think it's opportunity but there is a lot of intent that needs to be put into >> Thank you for your talk. I feel overwhelmed whenever I look at these resources and I wonder if there's like the 20% that we can start with. Yes, definitely. Um well,

so the week has like some quick guides that are a little bit less overwhelming than their normal full website with every single thing. Um but um overwise the guides we also have are a little bit more streamlined towards one use case. So it helps with also simplifying instead of looking at everything. Um and then the next advice I have is what Gloria was saying about focus on

one and then extend to many. So you're not going to make something accessible for every single type of constraints right off the bat. You might want to focus on something that is close to you. So it's like, okay, what can I do for people that have like low vision? Um because you might have uh people that have like, yeah, not great vision. You ask them to take

off their glasses and see how it works. So focusing on like one thing that you have a bit more knowledge about or you're more interested in and then just move on from there. But yeah, it is overwhelming. >> Yeah, thanks again for this amazing talk, Leia Rufini and Juan Ruina. >> Thank you. >> Thank you very much.