Accessibility is like performance, and security, and portability: You don't create the product, and then "spoon a little security in" right before shipping. You build it from the start as secure, with security as a first-class goal, and gate features on whether or not they are secure. Same for accessibility. You don't try to take an existing inaccessible project and wave a magic accessibility wand around it late in the game. It should be a first class design principle. If you are hiring a UI designer or interaction designer, pay attention to how seriously they take accessibility in their designs. If they're good, their designs are accessible by default, because as a Cousin Comment said, accessibility is not just "usable by the disabled" it's "usable by everyone".
I would argue that "usable by everyone" is an unreasonable goal which tends to result in catering to the lowest common denominator.
For example, take buildings -- they typically have stairways, often as a fire escape route. However, stairways are not usable by everyone. Should we ensure that buildings have no stairways at all because there exist some people who can't use them?
To apply this analogy to web accessibility, consider WCAG 2.5.5 Target Size -- in order to pass, click targets must be 44px by 44px. Seems reasonable right? Try designing a desktop spreadsheet program with 44x44 click targets. It's basically impossible to do in a way that doesn't severely impair the design for people who can click smaller targets.
> I would argue that "usable by everyone" is an unreasonable goal which tends to result in catering to the lowest common denominator.
Extremes are always unreasonable, the goal should be to support everyone that you reasonably can. Nobody is telling anyone to make their tools work for the blind deaf and mute quadruple amputee - but that does not mean that it should be acceptable to completely ignore the variations in capability of people wanting to use your product.
> To apply this analogy to web accessibility, consider WCAG 2.5.5 Target Size -- in order to pass, click targets must be 44px by 44px. Seems reasonable right? Try designing a desktop spreadsheet program with 44x44 click targets. It's basically impossible to do in a way that doesn't severely impair the design for people who can click smaller targets.
Blindly following guidelines leads to problems, yes. But you can achieve the goal of making the spreadsheed usable for someone who has trouble with small click targets: For a desktop program you should consider adding efficient and discoverable keyboard navigation so that noone needs to click anything. This will help power users as well as those with fine motion problems. In general, a program, unlike a physical staircase, is also something that can dynamically adapt to the needs of the user. For example you could make your spreadsheet zoomable. For a desktop program it could be OK to rely on third-party (or platform-provided) zoom utilities - just don't write your program in a way that makes those impossible to use.
For buildings such dynamic adaption is not as feasible and so we make compromises that require some people to rely on others for help in incommon situations. But even there we should do what we resonably can - for in many parts of the world public buildings do have wheelchair-accessible entrances these days, even if the emergency exit is a stair.
