 I'm just trying to get the decoration OK. So basically, this is me online. So if you see that picture, equal to this face. And my name online is Billy Bones. And so just to clarify, the idea of accessibility is that everyone should be able to access any application on the internet regardless of what disability they may have. They may be cognitive thinking slow. Let's put it that way. Like colorblind, no hands, cannot talk and cannot see. All these things should be covered. And most of the internet is probably not covered, because it's not necessarily easy to achieve that. OK, so the second part is achieving accessibility through testing. And through testing, I mean, how can we improve the ergonomics of testing and be able to achieve accessibility at the same time? So how do we solve a hard problem by making it easier to do something, which is actually not solving that problem? So it's a little bit convoluted. OK, so what does it mean to do ergonomic internet testing? Or what is the requirements? Tests should be stable. So if you change the guts of your code and the output is the same, your test should not break. Because if your test break, that's pretty annoying, because everything works the same way, right? And for that to happen, it has to be decoupled from the implementation. So if you receive a design, you should be able to write a test for that design without even knowing how you're going to implement that design before you write the test. So this is like the path to test development for web applications. So approaches that exist at the moment, we have the super old one and the most powerful one, which is CSS selectors. While CSS selectors are pretty powerful, because you can select anything you want, it's very convoluted. Like if you look at the click handler, no one knows what that button is. That's not even valid CSS, but anyways. And it's very coupled to your code. So if you change your CSS, your test will break. Confirm. Yeah, so 100% coupled. Okay, so then the solution to that, there were two solutions. One was data test helpers. So in HTML, it's valid to write data dash for any custom attribute you want to add to your tags. And so what that did is that, okay, well, we're not relying on the way the code works. We just add like little annotations around the place. And then we check those annotations when we test and we make sure that they work. So that gave stability, but still coupled to the code somewhat. Like you have to know what those tags will be when you write the test. And I call it a vestigial annotation because the first thing we do is we strip it from the DOM when we put to production. So we put in all this effort and we don't get anything out for our users. Okay, then copy by our style, I'm sure it exists in other things, but this is what we use at Trig Echo for the backend testing. And so this is more ergonomic in terms of the, it uses the way that the user will experience a site to do the test. So you want to click the button save, you just click save and you achieve your goal. So I say it's quite stable because it's your definition of how language is related to a bug or not. So Trig Echo, if the label changes, it's probably a bug. And if it's not a bug, then we should update the test because that's the different experience that we're making for the users. It's not coupled to implementation because you can read the design and write the test. And yeah, so the problem is that sometimes it doesn't work and doesn't work as expected. So the experience is not that clean. And then finally, there is an icon here, but it's very light. I didn't know how to change the color is page objects. So page objects are pretty old pattern also used to resolve CSS electors. So what it does is it abstracts the DOM into JavaScript objects that your test interface is worth. So instead of having a CSS elector in 20 places, you'll have a CSS elector in one place. And so when that changes, it's easy to fix. And when you read the test, your computer goes into sleep. So apparently I need to always give it a notch like Dory. Okay, so yeah, that's the current approaches. Okay, so now I'm going to cover what it means to migrate. So migration is about the journey from A to B. So it's about the journey from accessibility to, well, not accessible to accessible. And we're all very used to the refactor process, which is what we use for migrations. We have good tests. We show the errors or we make something which causes all our tests to break. We do the refactoring for fixing those tests. And then we smile because everything works. Right, so in the case of, I'm going to start talking about this in the case of linters. So like ESLint and those kinds of things. Basically you'd enable a rule and all your tests would break and then you'd fix those areas or ignore parts of it to have the world ended up. Okay, so now we get to introducing of semantic testing. Okay, so what is semantic testing? If we want to access a UI element in a test, we do so as if we're using a screen reader. So we are interacting with the page as a user would and less powerful user because we don't have like cognition and eyes. So as a user that's interacting with the page from a screen reader, right? And so this is what ensures that we are able to test whether your app is usable from a screen reader or not because we implement the same specification defined by HTML, the W3C. Okay, one more little extra piece here, which is expressing constraints, relationships and processing instructions in a less powerful language increases the flexibility with which information can be reused. The less powerful the language, the more you can do with the data stored in that language. So the most powerful language is CSS selectors and the least powerful language is using the word save, right? And so in between save and the actual DOM element, there's a lot of information that exists and that information can be used to optimize your code or run checks on your code. Like, oh, sorry, like this was a mistake that you did. It works, we'll let you do your test and continue on. But if you want to actually get accessible, you need to resolve these errors which we store for you and you can configure. Okay, so there is a little bit of current art on the project. So this comes, we use at Tregeco, we use Rails and Ember. And so I initially built it for Ember, for the Ember community. So it's under a package called Ember Semantic Test Helpers and then I extracted semantic DOM selectors which is the engine that converts save into a HTML element and I extracted QUnit semantic assertions also from Ember, from the Ember package which uses semantic DOM selectors to make assertions which test the semantics of the application and its accessibility in terms of text and annotations. Yeah, there was, at some point there's gonna be, there should be some architecture diagram. Okay, so if we take the following code. We have a login wrapper and a login input which is a label, a label that's targeting a login input and that label is email, the input is the input and then when you click the login button you will end up on the second page there which is article, section, et cetera. So the way you would write the test with the classes is you would select, you would say, okay, we'll fill in login wrapper input and the test will go and fill that in with that value and then click this button and then assert that the correct CSS is on the page. That means we've done the transition successfully. But this is gonna break when you change the CSS and if what's interesting is as you scale teams, at some point someone that's completely not part of this code has to read this test and they won't really necessarily understand, like this is a simple one but sometimes it can get quite complicated. So the idea is to change that to English so it reads like a story which is a bit BDD style, behavior driven development. So we go fill in email, Alice at example, click the login button and assert the section. So on the second example here we have a lot of things going on. Firstly the fill in helper will make sure that the thing that you're filling in is semantically correct. Is semantically correct. By semantically correct I mean the tag that you're using and the way you've decorated your tag with attributes actually conveys what it is because the way it's conveying itself is the way a screener will announce it. It will be like button, login. Do this to click the button and if it's not really a button it's not gonna do that action for the user. Click will assert that it's a button and that the text is there and then assert.section dashboard exists. Asserts that you're using the correct section element. It asserts that the heading is correctly bound to the section with the correct tags and that it exists. So we've actually asserted many more things on this section than we have on this section. Okay and also just to bring a little bit of migration in here is that the current tooling is very black and white. Okay you're either accessible or you're not accessible and in order to do a migration to migratory path you would have to keep checking it out or add extra tests specifically for accessibility and since we want to improve ergonomics we actually want to remove the concept of accessibility from engineers while they're writing features and then be able to turn on those concepts from the background as needed. So that's why it's all heading away under the covers. Yeah okay so this is the architecture diagram I was talking about. So we have some of the packages, the relations. So we have ember semantic test helpers which takes both semantic DOM selectors and q-unit semantic assertions and it's got its own infrastructure to actually do the full flow from finding an element to acting on the element. And then we use q-unit DOM which basically semantic assertions proxies the elements that found from the finding engine to an DOM assertion engine. And inside the ember semantic test helper package there's an engine which is about actors. So we have finders and we have actors. So the finders is the DOM selectors which is the screened apart but once the element is found it needs to be acted upon, right? So probably the most interesting component is the select box. No one enjoys using the original select box of HTML and so we all write our own select boxes and actually getting that to be semantically correct is very difficult. So there's a lot of work to be done and research needs to be done in how to do it properly so that we can build an acting engine which will be able to walk the DOM tree based on the correct attributes and also fall back to common mistakes to help improve like by the way you need to do this and that to actually do the acting properly, right? Not only works really well for like inputs and buttons and roll input and roll button, yeah? Okay, so this is sort of the back end of what the testing API is so it's a configuration, right? And the configuration is inspired from Linters where you can say, okay, I want like this preset which is a more babble if anything or you inherit from this rule selection. So for example, the first one is Aero compliant so if your app is not Aero compliant anything that like for example, if you label if your label targets the four attribute targets the input, that is correct. But if you label the four attribute targets the dev which has input inside of it, that is absolutely wrong. And we try to like make backup plans so that we don't stop your productivity and your ergonomics while giving you a path to get to the correct result. So that will be in the second configuration here where we have invalid four relationship is that rule. And you can toggle these zero, one and two or error, warning or silence. Also exactly from the define as ESLint and you can configure these different rules. So there's also one to one mapping with a finder to a rule. So if you install the finder you will be able to configure that finder and there would be like options to configure it as needed. And here's an example. We had a test and I just made the test invalid. And so basically the control scan or type barcode ID was found through an invalid label for relationship. And this one I put the error level to zero so that it will actually throw errors. This allows me to fix those errors and then go back to green. So we go back to that refactor circle of life. And if I don't want to have errors right now but I would like to know if anything's wrong we can just log to console. And then finally the last one is silence where you wouldn't even know you're doing anything wrong but you're at least able to code faster and have an enjoyable time. So to summarize all of that the key features are configurable and extensible. It's decoupled from the implementation. So with the first key feature we solve the problem of Kabybara where it doesn't always work and sometimes you like hit walls. So solve that problem. It's not coupled to the implementation so we can do TDD, solve that problem. The annotations that we're creating instead of data tests which we strip away straight away we annotate using HTML attributes of accessibility and semantics which is useful annotations was now absolutely becoming more accessible. And then yeah so stable as in like for us changing the word save to don't save is a bug. So your test shouldn't break unless you change the text on the page. And you can resolve the stability if you don't like it that much with page objects which I previously explained. Yeah okay so I have implemented this at TREG Echo and what successes have I found from this process. Firstly our teams are much closer to be able to write in TDD so write the test first then build the app and this will help them enjoy faster feedback cycles versus like waiting for things to get rebuilt slowly and pages to load and servers to communicate. We have useful annotations so even though accessibility is not important to TREG Echo our app is actually becoming accessible by accident. And within the culture we have a culture of semantic code and accessibility code which is important like just how we learnt our JavaScript you know we put a comma here and a curly there and a space there. We need to make sure that we don't that we get out of this whole of divs or HTML because divs are generic and they mean nothing. And so having this here people now actually think oh what is the semantic of my document? What does this tag mean? What does that tag mean? How would someone that's blind like access this? So all in all it makes us write better code and better programs for free. Okay so not everything is good. The downfall is that so there's three different ways to become accessible and you actually get like well I don't know if you get a certificate but you have to like meet some compliance. For different levels which is the A level, double A level and triple A level. Triple A level is the hardest, A is the easiest. So if you look through those compliances what we are asserting is only a small subset of that. So to actually use this as like a truth for an app and through testing right now is not totally possible. These numbers are totally made up. I have no idea what percentage is covered but I just know it's like probably not more than 50%. Okay so from that it's like okay well that's good. We have ergonomics but what moonshine ideas can we use to actually push that number to the top of that barometer I think it's called. So the idea I have is for visitors. So previously we discussed the finders and actors where the finder would get the thing and give it to the actor. So now we have a visitor pattern where the finder will find something and visitors will have an option to visit that object before it gets given to the actor. When they visit that object they can assert something. So for example I'm making a test click button save. The finder will find the save button and then the visitor will be like I am looking for any button. So it will match to the button and then the visitor can assert the color contrast between the foreground and the background of the button and then it can make like oh by the way like your color control is not correct and then that gets passed to the actor and then the actor acts on it and you've written your test. You haven't actually changed your testing code you've just installed a package in the config file like an extra visitor to get that assertion and then that would help us actually complete that bar. And then more extreme than that I was told to put many seats to make it funny but we have like alcohol which is lines of coverage for seeing how much our thing is tested. So we could actually probably with all this information we could build like accessibility coverage sheets or reports which can be used and then you can do things like on your CI make sure that your percentage of accessibility coverage doesn't decrease. So at least you stay at the same level. So that's that and then so basically the roadmap this is more like if this interests anyone or if you know anything about accessibility like I'd love to have some conversations so I've built it for Ember so a lot of work to do there. I've extracted the engine so that we can use this engine on any framework that's available even no framework. And then the dot dot dot is because I'm not really sure but yeah please like I don't know how much time I have off to us but give me a card or take my card to email. We can talk about that. And then finally I have to plug and so we're always hiring our stacks like JS Ruby but if you do PHP like feel free to apply. And yeah my presentation like the template was sponsored by Tray Gecko so that's why there's branding everywhere. It looks pretty nice. And yeah that's about it. Thank you very much. No questions. I don't know if it's just me but I couldn't bridge the gap between my writing semantic code and as a by-product making your coders make things a bit more accessible. What happens in the free? Okay so I'm in between from the user side or from the developer side? Okay so basically you would do something like assert dot input for example. I think it's just one second. Yeah so like for example this is the in between part I suppose right. So if your input like an extreme example they say you made you wanted a circle input right. And that doesn't exist in HTML. So you make a dove. And then you'd have like on key events in that dove where someone types in and it like would sort of fill in the circle. But now the problem is that a dove is meaningless to a screen reader right. The screen reader would just be like oh it's a dove moving along, pretty boring. But if you put like for example like roll text area that converts the dove into a text area from a semantic point of view. So the semantic is what that object is on the dome and how a robot or screen reader would interpret that item. Another example for like let's say SEO right. You make your link actually like a span because of some styling reason. And you don't put the correct semantic decorations on that like roll link or something. Then the robot would just skip over that though this is not a link. But actually if the robot had theoretically clicked it and you want them to click it so that they can navigate through your whole site. So what we're doing is we're asserting that this is an input and we're asserting or we're asserting this is fillable like a text area input, select box, radio theoretically. And then we're clicking a button. So we're asserting that it really is a button. We may, are you sure it's a button? Yes, it is a button. And we're asserting that this is a section and that the section has a H1 in it and the H1 is connected to the section through like area label by and like IDs. So that will be in the ideal case where we are area compliant. But given the fact that we are probably not which is like the sort truth I think like it's a bit of an assumption. We have fallbacks, right? So if you made a mistake here we have strategies to help you fix that mistake. And if you have mistake, a common pattern mistake that we haven't like provided a solution for you can either make a package or like convert to our repo or just in your app you can make custom finder that finds a common mistake. Because we don't want to stop productivity while we provide a part and like a to-do list to how to make your app accessible at the same time. Does that make sense? And for example, your things like email login is this standardized or? Oh well this is just a text on the page. So if I was testing this app so this is the app, right? And the app has got an input which is they will buy email. So if this was wrapped, yeah, if this was in a div and that thing targeted the wrong thing if any of this was wrong it wouldn't be area compliant. This is pretty much area compliant. How did it distinguish? In terms of difference between login and email. Okay, so that raises an interesting different kind of a point which I didn't include in this because of time constraint but there's a concept called inclusive design. And for certain areas if you have multiple login buttons one could argue that that is a bad design for someone that doesn't have eyes, right? Or someone that is cognitively impaired because you would have to like connect the buttons to visual indicators as to what they do. So maybe it would be better to actually write it differently. But at the same time we don't want to stop ergonomics so we have ideas for example within helpers. So you could go within to find a section and then within that block you could say click this button because we don't want to stop productivity at the same time. But it's all working off like English. Yeah, any other questions? Okay, thank you very much.