*> “Many of us are temporarily able bodied and will face exclusion as we age. When we design for inclusion, we’re designing for our future selves.”
Accessibility is like security, usually neglected and left as an afterthought unless one is impacted by it. Actually it’s worse than how security is treated because the consequences of not being accessible aren’t as wide or as bad as a security incident (even in jurisdictions where accessibility has more value).
What would make it easier for developers to include accessibility is better built-in tooling, similar to the MS Word example cited in this article. There are browser extensions that can help test for and report accessibility issues (and remedies), but it’d be better if these are built-in in the toolset used.
Of course, the author has no control of this and I'll keep reading.
The amount of work and hours put into developing and maintaining (nevermind learning from scratch) is hugely exceeded by the 10-15% potential increase in revenue, which I'm dubious about to begin with. Is the 200 hours/year it would take to maintain at $100/hr worth $20,000 in incremental revenue? I just don't seethat happening.
I don't disagree with most of the article, but the expectation that "you should do this without considering opportunity cost" makes the entire argument moot.
I use Firefox, and I rarely see a site that doesn't work because I'm not using Chrome. Firefox market share is somewhere around 5% now, and most people will use another browser if they need to for their bank or other important site.
If a business owner gets a call from a Firefox user who can't access their site, it's the developer's fault. Treating the requirements of an estimated 15% who need a small number of aids as though it is a decadent extra seems like a problem of professional standards.
