Other way around: they are so big, they cannot afford not to. They have so many users in total that simply making small changes to help some tiny segment, like say the completely-blind, they are able to add millions of users.
If your total number of users is only in the thousands, you won’t notice missing a few hundred potential customers/users.
And of course, being large, they tend to be multi-national. So now even if they started in a country that doesn’t give a crap about access, the company is very likely to have expanded into a country where it’s mandated by law and non-compliance == ginormous fines and a nasty write-up in the Wall Street Journal or Forbes (bad news makes stock values go down, and what if the bad news comes right at the end of a quarter?).
My answer to TechnoBear’s question is, it’s a two-factor deficit: web devs don’t know, and web devs don’t care. The latter don’t deserve any money for the broken stuff they build, because in order to be horribly inaccessible, you had to build expressly ignoring web standards. And if you’re incapable of following W3C web standards, you’re not a professional and probably incompetent. Or, possibly, you are not building products and services for the general public, but strange personal experiments with unsupported stuff. Which you don’t then release and tell everyone it’s ready for them to use. Google is a flagrant example of almost deliberately building fancy new garbage that completely ignores web standards, or uses them in such a messed-up way like
<span role="link" data-foo="longSetOfNumbers">Edit</span>
(yes this example is seen in the wild!) that you wonder what kind of drugs they’re offering the work force there…
The former group has to be met with care: first they don’t know, but then they have known unknowns-- they want to build accessibly but all they hear are a11y-professionals (using weird terms like a11y) saying seemingly horribly complicated and difficult stuff and there are all these rules and checklists, the worst part of which being a lot of them have to be interpreted.
If you f*ck up some Javascript, it just won’t run. You’ll get an error somewhere. But not passing a WCAG Guideline, it often seems like a vague hand-wavey problem, just like usability problems.
…Which is why, if basic disability/computer use awareness is at the core of any web-dev class, tutorial or article, and then with clear solutions (and I’ll use SitePoint’s Javascript Anthology book as an excellent example of this, the authors repeatedly mention accessibility and add code to the examples for these issues), it’ll become part of the basics of future web-devs. They’ll know what to think about. They’ll know what to look for. And lots of what they build will have accessibility baked-in, which is the cheapest way to be accessible.
Once web devs already have a basic knowledge, they’re ready to ask questions for the less-easy stuff, because it’ll be part of their work flow.
Where I work now, people cannot choose their users and stuff simply must work regardless of how the users access the product. So they come to parts of the company (like the part I’m in) and ask, is this accessible? If now, how do we make it so? And I think this is growing in at least more larger companies.
Also companies like Karl Grove’s Tenon.io (which automates a11y into building, deploying and testing software in an automated way) are making it easier for companies and developers to see that there are issues.
