At Atlassian, we take accessibility seriously enough that we have entire teams dedicated to it. There are experts on hand to provide feedback on designs, and answer questions about implementation details. There's a team that runs audits of new features before they're launched. It's honestly pretty good.

But obviously not everyone has the resources available for this kind of setup. So what can you do instead? I'm going to talk you through a range of tools and processes that we use to improve the accessibility of our products, what each does well, where they fall short, and what they cost to implement. You can then use this information to figure out which solutions best fit your particular situation, and how you can get the best bang for your accessibility buck.

If you're using React, there's a good chance you've been writing functional components with hooks for a while now. And I think most of us would agree that hooks make our components cleaner and more elegant. But hooks have a dark side too - they can be confusing and make code more difficult to reason about. And what's going on with the Rules of Hooks? Why can I only use hooks inside component functions? And why can't I call them conditionally?

To find out, we're going to have a look at how hooks work under the covers. We can then use this information to better understand what's going on in the hooks we use and help us to write our own custom hooks.

When people talk about CSS layouts these days, it’s all about flex and grid. And, don’t get me wrong, flex and grid are pretty cool. But normal flow is still the default layout on the web, so most of your app is probably laid out using normal flow. And that’s totally ok - normal flow is actually great, when we’re using it in the way it was intended.

It can be a bit counter-intuitive though - for example, why is it so hard to centre anything vertically? So, let’s have a look at how normal flow works, when it's a good choice, and what some good options are for when it's not.