First, a disclaimer: my background is primarily in enterprise UX (building for either intranets or for the customers of the financial company where I work) so if anything sounds particularly odd from the agency or indie standpoint, my apologies.
Level 1 is a good start, and if all your sites are 100% complaint with Level 1 you’re probably ahead of most of your competitors, and thus your clients are ahead of their competitors. They may even be able to use it as a marketing tool. But I’m struggling with the rest just as you are. I think the key is to stop making it optional.
To use a very tenuous analogy, ten years ago back-up cameras in cars, if they existed at all, would have been an expensive optional feature. Today they’re part of the base model. (Tomorrow they’re the law.) What happened during those 10 years? The price of a back-up camera went down, sure, but it didn’t disappear. Customers began to expect it, manufacturers caught on, and the price of the base model went up to compensate.
Today, accessibility is treated like an expensive optional feature, when it should be a standard feature. As an industry, we already moved “support more than one browser” and “support for mobile” into the base model. Those were both expensive features, but they were required by our customers. Accessibility should be required by our customers, but even if it isn’t right now, I’m betting that at least in the US it will soon be required by the law. We might as well be ahead of the game and put it in the base model.
As for the cost, well, the most expensive time to deliver a product that requires a new skill is going to be the first time we use it. The first time we switch to a new language, a new library, or a new methodology, there are lessons to learn and kinks to work out. (In my experience we don’t usually line-item charge clients for those changes, even though they make us less efficient. “There’s a 10% increase in costs because we’ve decided to learn Angular.”) But a few weeks or months in, we learn a lot—and we start building a library of working code (or design patterns) of our own. We can then leverage what we’ve learned to lower the cost of accessibility in the next project. That continues until a) we know enough about what we’re doing that it’s only a 2% increase in costs instead of a 20% increase, and b) we don’t even consider not doing it because it’s the right thing to do and nobody’s going to argue with 2%. To get there, we need to start.