Accessibility, making content and applications accessible to people with special needs (blind, deaf, and people with cognitive impairments) is, to my mind, an important issue. Section 508 is a by-law in the USA that attempts to make sure that applications and content from government (at least) is accessible for all, irrespective of community. Is this topic one that comes up at all in your work? Who should be responsible for it?
4 回答
When I worked at larger companies, every spec had a section on accessibility. Every aspect of a feature was required to have a keyboard shortcut listed in the spec, and every UI element was required to have its accessibility role and text listed in the spec. Test would then files bugs against features that were implemented without accessibility. This was true in native code, managed code and websites.
Everyone on the engineering team, from PM to Dev to Test is responsible for it.
It comes up all over the place for us. We'll just say that a certain client requires it. For us the responsibility is between the developers and the business analysts, but we don't have the most efficient SDLC process. Generally, the BAs put it in the requirements document and the Devs go through it and see if it is possible to accommodate all the requests. The testers are then responsible for making sure that it complies with the requirements document. We do have outside consultants who specifically in things being 508 compliant that look at the applications to make sure they do. Really it's everyone's responsibility on the project, because it is so important. When dealing with the government a lot of revenue is at stake and making a mistake like that can cost you in the long run.
I'm a totally blind individual who uses a screen reader. At the fairly large company I work at accessibility isn't mentioned accept when I grumble because I'm unable to use one of our products. Most of the company’s products are more or less accessible do to the technologies used, and if the product deals with charting or presenting graphical information screen reader accessibility becomes less of an issue. I believe the main reason it isn't part of the development process is because no customers have complained. Part of the reason customers may not complain is because the company produces tools for developers and if a blind developer can't use a specific tool there much more likely to find a way around the issue to accomplish the same task then a blind individual in accounting who can't use SAP software which runs an entire department. Note the preceding statement is completely anecdotal and my opinion with no evidence to back it up.
Every time I'm asked to perform an audit on a site's accessibility maturity, the number one flaw is that the software isn't designed with accessibility in mind. Designers and developers many times have a thin understanding of accessibility. The believe they have thought of accessibility when in fact they haven't.
Many times solutions are inserted long after the product has been released. This results in the software being more difficult to make accessible. In addition, the level of accessibility cannot reach that of a software system that began with accessibility in mind. In the long term, it costs more money and has poorer results to 'force' accessibility into a product late in the life-cycle.
As far as the responsibility, it is the responsibility of the company to create an accessibility policy and then ensure it is correctly implemented. It needs to come from the top down or else it won't be a true consideration. The designers, developers testers and their managers all need to do their part to make certain the company's accessibility policy is living up to expectations. Marketing and public relations can benefit by talking about the accessibility of the software as an attribute of corporate responsibility the company is living up to.