 Okay, so good afternoon. So this is actually the continuation of the previous talk about Maintaining accessibility on a long run through testing So just to make a quick poll, what do you think is the accessibility problem of this? What is the problem with GNU plots for? the colors red and green is the In the worst choice of colors to do because a lot of people actually can't distinguish and then Like 8% of the people of the male people cannot distinguish between the two Or at least have problems and then with group 5 they improved this so you see I mean just wondering How many people here please raise your hand if you are colorblind in the room. Is there somebody no? But that's 8% normally so statistically there should be 1% at least Anyway So what is accessibility? What to make it simple. It's making something usable by everybody. Whatever the specific needs situation, etc So of course, it's blind people deaf people, etc But also people with cognition issues I don't know all people have problems with Understanding your your software things like this on motor issues You cannot press a shortcut because you need your both and both your true hands and you don't you have only one and Quite often it can be you because you have a package and you cannot type with the true hands or a Lot of people here have low vision and you're lucky because you have glasses with which you can wear all the all the time, but Some people cannot have this There's a poll which says actually 10% of the people are really handicapped in their daily life and 20% would say that they are limited in their daily life due to Conditions, whatever the thing is it's it's really it really is a matter for everybody actually and For free software, this is really about freedom zero the freedom to run the program for any purpose Okay to run but More to that and to be able to use the program and then there's the second Freedom freedom number one. This is free software. You can modify it. That cannot happen. I will explain why It's question of priority as was mentioned previously. It should be prioritized It's actually just like security and internationalization In the rest of the talk really try at some points thinking. Yes, this is like security and Internationalization it's the same kind of we have to keep it in mind all the time and The question is who is doing this? the problem is it concerns just some fraction of the people they are they are already having a hard time using computers and Having the skills to actually program modify the program. It's even less people and Then you have people who have programming skills and could do something on this But then being aware and understanding what needs to be done. It's even less people So there's really extremely small fraction of the people who can actually work on this So the sentence this is free software. You can modify it that cannot work actually You could say okay, let's pay some people to do this Okay, so we have some people which monitor all the software in the free software world So we would need a lot of people keeping getting updated with all the evolutions We have here and there and so we have for instance John Marie at Igalia who does this on everyday life, but he cannot do everything It's not possible and spending your whole day. It's just debugging things. It's really more than painful So no, it's it's not feelable as a solution. So the support has to be spread among Every developers Integrating into their development process just like security just like internationalization Nobody develops a software without taking a security issues into account nowadays. At least they shouldn't really Accessibility is the same kind of priority Just to give the low things so the You know rights of persons with disabilities So I put everything so you can read it offline, but basically discrimination is Exclusion on the basis of disability including denial of reasonable accommodation So even if you don't do this on purpose, it's considered exclusion and reasonable What does it mean not imposing a disproportionate or undue burden? Okay? It's not much more clear, but at least it has a legal meaning and disproportionate The question is how to make it proportionate So we will propose a regression testing So there are two things For start we want to avoid introducing new issues. So everything that is Developed nowadays should not have accessibility issues by pointing them out as soon as the development While the programmer is programming the tools tells it. Oh, this is bad. This is bad. This is bad Here is how you should fix it and then the programmer learns and then he will not do the Mistakes again. So that's an extremely important thing to not go back Make sure that we don't have new issues While we still have the old issues That we have to work on so we have a list and then okay We have to work but it's a second priority after making sure new things don't get regression So what are we talking about technically? Just extremely briefly the idea is we want to make the same software accessible For a lot of reasons I don't detail but basically we can't re-implement LibreOffice for instance So we have to make it accessible The idea is you have your application and then the screen reader uses an accessibility bus to access the abstract representation of the application and This is basically a tree of widget and then okay, you have all the information cool a lot of toolkits Provide this information that's fine But the problem is it doesn't mean that it's necessarily usable because maybe you have this dialog box and Maybe you implemented it that way so you have labels and then you have text and there's nothing that relates one with the other So ideally you would say there is a label for some text But maybe you have just written your code that way or maybe it's the XML file you use which imposes that way of doing it Okay, we could say oh, sorry about this You could say that the screen reader should have a script to fix and to know that it should relate one with the other But it's not viable on the long term because the screen reader then gets a lot of ugly hacks And it's not maintainable on the long term with each new release you have to fix to update the hacks It's not really something we want Instead you should just declare properly the relationships between the widgets. Sorry To declare them properly means you say that this text is labeled by this label. So that's what we will focus on Just some takeaway slides. I don't detail them because I don't have the time But basically design logically without taking into account graphic things use standard widgets use labeled widgets make sure you have logical rejections seeps and keep it simple and Making it simple will help everybody actually to use your software You can try accessibility tools You can enable enable the screen reader and see what happens and try to use just a keyboard Don't cheat and see what shows up on the braille device If you want there is a debugger to check exactly what is there, okay, but Maybe it's not something that we should promote because it shows that it's quite a lot of work to work on accessibility Well, maybe we can do a lot of things without going that far So trying to use automatic tests in continuous integration And that's what we propose as a first step now and to try to avoid some classes of new issues And still have a fix me list to fix the previous one The idea is that that way we can make people aware of the question with is it enough to fix issues And then okay, they take that into account and then maybe later on we can expand the kind of things We want people to keep in mind all the time when they are developing So about regressions, you know about what regression So you move one step forward that actually you go two steps forward and two steps backward Because a new feature breaks an old feature a bug fix breaks a feature you have Regressions here and there so you need regression testing and user testing Concerning accessibility it's way worse Usually when you make one step forward you actually have ten steps backwards and new features are just not usable at all quite often and Bug fixes break usability completely quite often and User testing doesn't work because there's there aren't so many Concerned users and it's difficult to for them to test the development versions of your software and The developers themselves don't have any idea on how to actually fix it because they are not accessibility experts So how to test this what what should be done? So regression testing could be an idea to make them learn progressively So new features, they should be hopefully usable. That is there are shortcuts There are logic relationships. Is that convenient? Maybe not but at least the new feature with some effort should be accessible I mean the person who actually needs accessibility Maybe it's not convenient, but at least it can achieve the task with more time that should be ideal Ideally be needed, but at least it does work and and for the old features We should make sure that they remain usable So there are three things we are thinking about right now which are relatively simple So labels with widgets all widgets should have some label which says what it is about Except maybe some special cases labels conversely if they are there For the visual rendering that's probably for a reason and so if there's a label without a widget attached to it probably there's something problem like somewhere and Also shortcuts all the widgets should be reachable through shortcuts So maybe pressing tab or maybe it's in the toolbar and so you have an F something shortcut to be able to access it quickly so maybe these are the Really simple rules that could be tested automatically that we can enforce and make sure that they will always work And that's already a huge progress compared to what we have nowadays So how to test this? We could try to test online so run the application and check that we have labeling But it's quite expensive. It's low and okay, but which source line Corresponds to that we'd get it's difficult. Maybe we can do that inside the toolkit, but It's also the same problem. How do you get back to the source code? Okay, maybe there's research to be done here Static analysis Passing the source code. I don't really see how to do this at the moment I mean looks not so easy But a lot of applications use glade so XML files basically and so what we've been working on and will work This month is a tool which shows the warning. So saying that this widget doesn't have a label for This label doesn't have a widget attached and this widget doesn't have a label and there are actually like 16 lines apart. So probably actually these two needs to be related and that's all So it's really simple to fix those and hopefully this tool will allow to make that easy So of course, we have other issues like there are multiple named mognic for one For one widget or The link is actually broken. Okay, these kind of things we can debug automatically And we can include that in the build process So we've been running this on LibreOffice and we got like 8,000 runnings That's a lot We can start with compilation 8,000 warnings. So we want to implement a notion of suppression which says okay these 8,000 warnings we have to fix them at some point, but Day zero we have zero warning and we remain at that and if there are new warnings Okay, we fix them and then when we have time when we take the time to do we fix those all right warnings We have suppressed and then we should be able to make progress actually There are false positives Sometimes you say no no this actually is not interesting to label or some things Probably we can automate some of these and mark those which we cannot automate because it's really on the semantic We will be working on that this month So to have a look at all of these try to sort them out see with the people what they prefer the way they prefer etc So that's the HIPRA company and Martin Peuchot who wrote the initial tool and which we will use and Extend and that's funded by TDF. So it's on some JIT from now Probably we will try to move it to some place like maybe at GNOME or JITLAB. I don't know we can discuss Our idea is that it should be As globally used as possible. It doesn't have to be only for LibreOffice Maybe there are LibreOffice specific things From what I've seen in the 8,000 warnings. I Probably not so many LibreOffice specific things I guess So to conclude it's really a problem for a lot of people And actually as said before it actually helps everybody when you have shortcuts to do your daily work You actually get save a lot of time so and making the software simple etc It really helps for a lot of things But we need to raise awareness of on this and regression testing maybe is a nice tool Starting with just a few warnings and see how well it is accepted, etc And then get to integrate accessibility in the development process itself to enforce the things that okay We have agreed on enforcing making sure that it's always like this just like security and internationalization I Haven't talked about keyboard shortcuts, but yeah, we would also work on this just not not now. Thanks So we stay here for the weekend Maybe just one question Into so can the script be? Integrated in inside glade So I asked on the glade mailing list. They didn't answer I'm not sure glade doesn't seem to develop so much, but yeah, that was our idea They're saying that okay, there's that glade tool and okay integrate the thing is a lot of people use UE file UI files, but without actually using the glade library so I Prefer that it's just one script that people use just like lint like valcrin valcrin is not inside the compiler. I Don't know, but I mean we are open to whatever Yeah, a thousand. Yeah, usually yes So for instance, I didn't show it, but the sort dialogue box there are eight warnings and yes There are eight issues quite often. It's a small issue That is you have the word ascending and descending and you have to know that it's the sort things And it's just leaving ascending and descending with the sort word It's small, but it helps a lot actually And it's really easy to fix Okay