Hello everyone. My name is Melanie Sumner. I work on Accessibility and Ember 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 lightbot 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 the 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 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 boot camp 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 focus 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 our 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 a scale, we have to be especially aware of this.

So what are we missing? We must not confuse the quick answer with the 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 a complete 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 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 Jira 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 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

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 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 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 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 Lint today. And if you want to get involved and help, there are a few ways that you can contribute. Use Ember Template Lint 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, 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 on GitHub, LinkedIn, or Twitter. I can't wait to hear from you and hear about your

accessibility journey. Thanks.