 Hello everyone. My name is Melanie Sumner. I work on accessibility and number at LinkedIn. Before I start, I want to give a huge shout out to our community and the way everyone is making the best of a not great situation. I think the Together framework proves once again that we really are all in this together. Today, I want to talk to us about the shift left mindset and how I think this will not only improve the quality of your code base but help you level up in your craft. My son brought home some coding homework the other week. As you can probably imagine, I got really excited. I've been leaving him little hints like casually placing code for kids and anyone can code kind of books around the house where he could see them or taking photos of my book collection and showing him how many likes I got on Instagram. Anyway, his homework was a kind of light-bought code game. Learn about procedures, loops, and conditionals while helping a character move around the map and turn lights on and off. I helped him get through his homework but naturally, since he's 13 and it was homework, he wasn't as excited about it as I'd been. It got me thinking about when I learned how to code and how other people learn how to code. What about you? How did you learn? I've seen a few different paths. Maybe it's your hobby. Maybe you went to college and earned a degree in computer science. Maybe you did something else first and decided to switch careers through a coding bootcamp or maybe you're self-taught. All of these ways are great but they are inevitably incomplete when you're building for the web. If the past 31 years of the web have taught us anything, it's that change is constant and that means any learning path you choose is inevitably going to leave something out. This is especially true when it comes to crafting accessible experiences for the web. It ends up being kind of tricky if you're trying to interview folks to fill positions. An interview process needs to be efficient for the company but sometimes the efficiency measures taken for the business reasons can really leave out all the things that we need to be checking for when hiring front-end developers. I'm sure we've all seen the social media posts about whiteboarding algorithms during an interview only to end up with a daily work that is more about making forms and vertically centering elements on a screen. So I'm not going to get into the interview process at this point but I think it's an area that really needs to change in our industry so let's keep that dialogue going in other spaces. But right now let's talk about where what we can do where we already work. Now today what are the practical steps that we can take to elevate the craft of the front-end? Continuous learning is a must and I don't mean in a theoretical sense. There is always something new to learn for front-end web development and excellence goes beyond lines of code. And to be clear I don't think that there's just one way to do this. I think it really depends on the part of the stack that you're focused on and what your interests and goals are. For example if you have a computer science degree but you're building UI components for a living additional study will likely be necessary in user experience and design. If you're a bootcamp trained developer who finds themselves writing tools additional computer science study will likely be necessary to improve the tools you create. And no matter what kind of education you've gotten you will likely need to study assistive technology since it's not included in most curriculum. An example of this in another field is in soccer or football if you name things correctly. Typically players will develop the basic skill sets of the game endurance ball handling game strategy then players will find their niche the kind of position they like to play such as offense or defense and an area of the pitch left right or center. As a result you can end up with different play styles or career tracks if you will I've identified three. There's a kind of player that develops as an all-around player on either offense or defense but can play on any area of the pitch. In this case we have an attacking midfielder who can also play left wing or right wing he can do them all. Sometimes even after they've trained for their niche a coach can ask them to switch things up and a left back becomes a left wing instead. Some players develop their niche and stay with it no matter what kit they're wearing. No matter what kind of developer you are think about the position you're playing right now and further develop your skill set accordingly. Some percentage of your time must involve either deeper knowledge of the niche you are already in or balancing out your skill set by increasing the knowledge of the domains that will be affected by your work. The next time you are at work for every UI component for every workflow that we write code for we must be asking ourselves questions that will help us keep our users in mind. Would I enjoy this user experience? Could I perform this workflow with my eyes closed? Could I still complete this workflow with only my keyboard? If I blurred my vision and looked at the screen could I still tell where the outlines are as I tab through the interface? If I pulled this up on my mobile device what happens when I have the accessibility settings turned on? Do I know what this looks like in high contrast mode? For every new feature request that comes in do a quick self-check. Do you know how that new feature request will affect your user experience? Please especially think about that the next time you start to engage with a designer on a new feature. So what do good patterns look like? When we think about patterns what comes to mind? A typical pattern looks something like this. Basic examples that show how to use it. Variations on the basic examples to show some flexibility. A rendered sample of the pattern so you can get an idea of what it should look like and some way to copy the code so you can paste it into your own IDE. These patterns are typical but I believe they're missing the essentials. Maybe you think that it's someone else's job to consider performance which really can help rationalize any given number of realities we face on a daily basis. Poor management, general accessibility, ignorance even sometimes their own laziness. But the thing is even the most concise framework code in the world will not matter if we're not thinking about the feature code that we create. It might be beautiful, it might be easy to use but if it's missing the expertise say in accessibility you can end up with a beautiful UI that is completely unusable for a percentage of your user base. You can confirm this with some math. What does an optimal DOM tree look like? Less than 1500 nodes, max depth of 32 nodes, no parent with more than 60 child nodes. And there's a free add-on idea for you. Not only will the non-optimal experience feel sluggish which really should be enough for us to revisit implementation it can also make screen readers outright crash. If we are working on any kind of code that needs to scale we have to be especially aware of this. So what are we missing? We must not confuse the quick answer with a complete answer. It's not enough to provide patterns that tell us what to do. Good patterns will also explain why. Patterns should also include anti-patterns, what not to do and why not to do them. By investing in the effort to create patterns that are the complete answer we give ourselves the right tools to craft better solutions for our users. By understanding both the pattern and the anti-pattern we will know when to raise a red flag on a designer prototype. It helps us to get to the finish line instead of stopping at an incomplete solution. Here's the thing if it's not accessible then it's not a complete solution. You're not finished thinking about the problem yet. Don't stop until you get there. I've seen too many features need to completely rewrite after the fact because they decided to delay the accessibility audits until later. If you think about accessibility as a core requirement your MVP will actually be an MVP and not just technical debt. Point three stop issues sooner. By equipping ourselves with a more holistic view of our digital products we enable ourselves to stop issues sooner. We can prevent bugs before they even start. We can increase the percentage of our code base that doesn't regress in the first place. Do you know how many accessibility issues your product has? If you don't know do you know how to find out? Hint. If you happen to be one of my colleagues it's possible to find out. Another thing that we have in our corner as developers are tools. In some cases they might be tools we're still trying to create but first let's look at the ones we already have. We have linting and testing tools that can help us before we commit any lines of code to the code base. In Ember we have two great options for this. Two of these are Ember A11Y testing and Ember template lint. Let's talk about Ember template lint. In the last six months we have been slowly but steadily figuring out how to give the Ember community something special. Not only is there an octane configuration we have also been adding more accessibility related rules to Ember template lint. Why should you make sure it's in your app and that the accessibility related rules are turned on? Here's why. Because by actively using this add-on you benefit from actionable insights because you can benefit from these right from your code editor and we even now support IntelliJ. You can start checking for these accessibility issues before you commit any code. Why else should you use it? Because it's okay not to know everything. It's okay to accept that there are things you don't know and depend on your tools to help you out. The Ember template lint add-on provides you with the support for some things you might not even know yet. Did you know that you don't always need to add alt text to images but that the attribute always has to be there? Did you know that you don't have to put image in the alt text because the screen reader already reads out that it's an image? The require valid alt text rule will help you out there. Did you know that every input needs an associated label? Did you know that there are valid values for the role attribute and that you can't make up your own role? Or that there are different kinds of rules and some of them are abstract and must never be defined in your code? Or did you know that interactive elements always require a role? Ember template lint and Ember A11y testing can help you check these things in your app. Proactively generating more elevated quality code before you push your code means that we can reduce the number of your tickets which will give you more time for your next big idea. I think this is the best reason for using Ember template lint. You're giving your future self the gift of more time to spend on the next idea. Challenge alert. Mia wants to know, do you know what will happen if you ran Ember template lint on your code base today? Try it and see. Next time you're in your code base, run Ember template lint and see what kind of issues it reports. Accessibility audits will reveal these issues and more so why not take care of the ones we know about now? We've started working on ways to test the common failures and that's something that hasn't existed yet. As we work out how to put these automated tests into place, every Ember developer will be armed with better decision making support from the moment you start writing code but we still have a long way to go. Some of you have heard me refer to accessibility as a final frontier of the web and here's why. Intent matters. Accessible interfaces are the ones that can be used in the way they were intended to be used but we still don't have a way to say here's the intent of this piece of code. Until we can programmatically assign intent to our custom code, we will have gaps in our automated testing. Until we have had to look at the full scope of the accessibility test automation problem that we face today, we will not be willing to say this is how you do it and this is how you don't. And this is what I mean about the need to shift left. Don't wait for the audit. Move accessibility into the design and development workflow. I genuinely believe that understanding the needs of users with assistive technology will not only show us a clear path forward for the web but it will also increase our holistic understanding of what our code needs to look like in order to create the next generation of user experience for every device. Here's the thing. To me accessible code is performance code is valid semantic code and this kind of code has a higher degree of quality to it. An elevated level of craft. Whether you started knowing how to write code with these with knowledge about these kind of quality standards, it should be your eventual goal. I want you to try something when you get home. Set a meeting on your calendar or an alarm on your phone, something that allows you to set up a weekly check-in. Take a little time for some self-reflection. Did you have a today I learned moment this week? If you didn't, figure out why. Challenge yourself to make this idea happen. Keeping the today I learned mindset is essential for success in our field. Maybe you do this by reading a new book. Maybe you do this through daily challenge exercises to warm up in the morning. Maybe you do this by trying out some assistive tech features, assistive tech on features as you build them. Maybe you do this by reading the spec. Or maybe you do this by thinking about what spec doesn't exist yet but needs to. I asked someone once what the difference was between Java and JavaScript and I got an answer I really liked. Java versions are Java's way to become more spec conformant, while JavaScript is still evolving and deciding what that specification should look like. This means that until the web platform as a whole is a lot more stable, we will be required to continually grow our knowledge and skills. I hope I'm not the one breaking this news to you, but our chosen career path requires passion, patience, and persistence. Whether or not developing the shift left mindset appeals to you, you can still try turning on Ember template link today. And if you want to get involved and help, there are a few ways that you can contribute. Use Ember template link and Ember A11y testing when you write code. Contribute to these code bases by filing issues for bugs or requesting new features. Or join the accessibility strike team. The thing is conference talks can be really inspiring. They call on us to imagine the future, to show us the bleeding edge of tech and inspire us to reach for excellence. But what happens when we go back to work the next day and we're faced with the reality of the code base we work in? Figuring out how to turn that conference inspiration into reality can be really challenging. Reality is usually a bummer. The great news is that we can influence that new reality. Accessibility is a journey and Ember's in it together mindset will make this journey easier. We can carry this weight together and together craft a more accessible future for all of us. Thank you for the gift of your time and attention and here's where to find me on the internet and github, LinkedIn or Twitter. I can't wait to hear from you and hear about your accessibility journey. Thanks.