About a week ago, Andy Clarke wrote a post entitled Advocating the quiet revolution. To sum it up, it’s about not trying to justify every choice of technology to your managers, clients and other people in your team, but just by default write code with web standards, separation of content and presentation and accessibility in mind.
While this is true and a good advice for you personally, it mostly only applies to situations with small teams/companies and when the customers don’t have developers that will inherit your code and continue to build on it. When working on a larger scale or in conjunction with the customer’s developers, it is crucial to explain and motivate the choices of technology, and why everyone in the project should abide to these guidelines.
Because, if you do things right on your own and avoid informing everyone else affected by this, they won’t understand your code and will just alter it as soon as they get the chance. And if you just put your foot down and demand valid accessible code from the developers without giving them reasons why, they will just run to the manager, complaining that it will take longer time to develop then (which is not true, but they usually state that out of fear, because they’ve just realized that they lack the necessary skills).
You don’t have to be a raging standardista full of elitism to convey this message; on the contrary. If you explain in a humble way why this is important by mentioning factors like lesser bandwidth usage, SEO, faster loading pages, maintainability of code etc, then they might understand you, from a business perspective as well as a developing perspective.
So, make sure you write good code. But also make sure to inform people around you why you do it, and why they should do it too.