How well accessibility is addressed varies a lot, just like other measures of quality vary a lot from tool to tool. Some applications are terribly designed for potential users who are blind, or who are deaf, or who have reduced manual dexterity. Some cannot be used by people who are color blind. Some cannot be used by people with slow internet, or people who use one browser, or people who only have a cell phone. There are a lot of ways to make a poor quality product by only paying attention to whether you can use it. And if you do that, then users who find your website or application will clearly receive the message “I don’t care about you enough to do the bare minimum”. That’s something that real developers are, in fact, fine with. So yes, in the “real world” people create software that is unusable.
The type of thing that is briefly covered by freeCodeCamp is baseline standards: just using the built-in features of HTML to allow for technology standards. At any company, those standards will probably be required. In fact, they’re largely built into any good UI library so as long as you know how to use your library and testing frameworks it will require almost no effort. How well accessibility and usability will be understood and designed for will depend on the product and on the team. If you’re making a social interface where users come to entertain themselves, you want the experience to be enjoyable to diverse users. If you are making a form widget that lets people unsubscribe from a mailing list, then they just need to be able to use it quickly and effectively. In larger companies there will be people whose full-time job is to design the product and as a developer your job is to make sure that you are always following the requirements. On smaller teams, some of the responsibility for design will fall to the developers and it will be important that you know how to check whether your project is accessible and how to address accessibility issues.