The release date is next week and you're still head down banging out hacked code that barely passes reviews just to make the deadline. It's not pretty code, but it works. Kind of. Barely. You have some unit tests, but you've used up all the wishful thinking you could muster to hold it all together.
Documentation is lacking. The closest you came to writing that is the handful of code comments like "//TODO: Fix this later" and "// I'm so sorry."
You've copy-pasted so much code that your clipboard history looks like a "What Not To Do" programming tutorial. I mean, you've put out some spaghetti code in your career, but nothing like this time around. Eh, who has time for refactoring anyway?
You wanted to get to some performance optimisations, but the most you could do was to comment out some of the console.log statements in your code.
The user experience is a bit sloppy and the design is not quite what you intended.
In all this commotion, who has time to think of accessibility?! Ridiculous!
If only you had more time...
My friend, you don't need more time. You need more focus. Work will just expand to fill up your time.
Think of accessibility from the start. Instead of whimsical widgets, focus on using semantic HTML elements. It takes less time than throwing in endless divs with ARIA roles. And it creates a solid foundation for you to build on.
Keyboard navigation isn't extra work when it's part of your component testing workflow. Take those few extra seconds to verify tab order and focus states while you're already testing your interactive elements.
Colour contrast checks can be automated in your CI/CD pipeline, catching issues before they even reach code review.
Building accessibility from the ground up requires less effort than retrofitting them later. It's not about having more time – it's about making accessibility a core part of your definition of "done."