I've never really learned much about accessibility but it seems like an important topic.
When you build a website or piece of software, or when you're talking to a client about a website, where does accessibility come in? Or from your experience, if you don't have accessibility in something you've built for a client, do you get a lot of requests to include it, or does it limit you in some financial way?
What are the numbers, I guess. What's the return in your business, how many people have you talked to that need it? Do you yourself need accessibility features?
I do mainly Flex/Flash and it seems like I'll have to do a bit of work to have full accessibility.
Thanks for the help.
As a person with a disability myself, I am consious of adding accessibility features when I write software
Accessibility is an area of software design concerned with making software user interfaces avvessibile for people with physical or mental disabilities or imparements. Different people have different specific needs and you can't be expected to cater specifically to each but there are some broad groupings
Visual Imparements:
This includes blindness or color blindness. To assist in this area consider providing "good" alt text (clarified blow) and hints so that screen readers can present a view of your content that makes sense aurally. Providing easy access to links to raise text size and/or access to some high contrast stylesheet options is also a good idea.
Non-Mouse Users
There are a huge number of conditions that can prevent one from being able to successfully mouse, it took a few years for me and my brain, which is somewhat unreliable when it comes to spatial relationships to pick up the skill. For these people keyboard access is really helpful, I don't work in the web space so I'm not sure if there are standard keys to use, but these are communicated by screenreaders and tooltips so having any is better than none.
Hanselminutes episode #125 is quite educational. He talks with a blind user about accessibility on the web and in generalAccessibility is omitted from a lot of design processes, either because businesses don't have an immediate need for it and therefore don't consider it at all, or consider it a low priority feature. Leguslation in various countries has helped a bit in this regard, but the real problem is that accessibility in general is usually an afterthaught to the design process,
1"Good" alt text is judicious use of alt text that accentuates the content or purpose of a page, navigation elements should have alt text describing where interacting with them will take the user, similarly, things that aren't content, like spacers should have no alt text at all, because there is nothinng worse then hearing "Foo's widgets spacer spacer spacer spacer spacer nav_Products spacer nav_support"
I think accessibility is usually completely forgotten about (either implicitly or explicitly dismissed beforehand because of issues like cost) in most software development projects. Unless companies (or individual developers, more likely) already have experience with either people with disabilities or with writing software with disabilities of users in mind.
As a developer I at least try to do keyboard shortcuts correctly in software I work on (because that's something I can easily dog-food myself, since I try to keep hands-on-keyboard as much as possible). Apart from that it depends on whether there are requirements about accessibility.
I do think this kind of thing is part of "programming taxes", i.e. things that you as a developer should always be doing, but...
I am only aware of this - at least more than the average developer, I think - because I have once written software for a software magazine on floppy disk, or Flagazine. This was in PowerBasic 3.2, grown out of BASIC sources in a magazine, making these sources available by BBS and disk, eventually growing a menu around the little applications to easily start them, etc.
One of our primary users (and later members of the editorial staff) was blind and was appalled when we switched from text mode to an EGA mouse driven menu, as his TSR screenreader software couldn't do anything with graphics. It turned out that his speech synthesizer simply accepted text from a COM port. It had a small (8K I think?) buffer that would be instantly cleared on reception of (I think) an ASCII 1 character. And that was it.
So we made the graphical menu (and most other programs on the Flagazine) completely keyboard accessable at all times and in the graphical programs we use a small library I wrote to send ASCII text to a configured COM port. This had small utility methods like ClearBuffer(). With this, and the convention of speaking possible menu actions when pressing the space bar, made all of this software accessable to our blind users.
I even adapted a terminal application for my HP48 calculator (adding a clear buffer/screen on ASCII 1) so I could use that to emulate a speech synthesizer. I would then test all of our software in each Flagazine by attaching my HP48 with the emulator running, turning off my computer monitor and trying if I could use all the software without seeing anything.
Those were the days, about 12 years ago... ;-)
I am a blind individual so have to develop with accessibility in mind if I want to use my own programs. I find my self focusing on accessibility based on the type of application I’m writing. When doing command line or mainframe applications I don’t think about accessibility since those environments are inherently accessible. With web based applications I have to give some thought to accessibility but not a lot. This is mainly because I write simple web applications for limited use so don’t have to worry about making the interface appealing, just usable. The area I spend the most time focused on accessibility is desktop applications. For example using .net I need to make sure accessible properties are set properly and that labels are in the proper position in relation to a text box so my screen reader can find them and associate them with the proper control.
Related
I create applications, that are divorced from any native framework. All rendering happens in OpenGL, with a context provided by GLFW, all in C, with no framework to rely on supplying compatibility. As such, standard screen readers like NVDA have no chance of picking up information ( excluding OCR ) and my applications are an accessibility black hole.
How can I provide an interface for screen readers to cling unto? I presume this is a per OS thing... How would that be possible on Windows, Linux, BSD or even android? In the *NIX world, I presume this would be Desktop environment dependent...
I'm finding a lot of information on this, with a framework as a starting point, but have a hard time finding resources on how to do it from scratch.
I'm fully aware this is far beyond the capability of a sole developer and know, that writing programs by ignoring native interfaces is a common accessibility hole, which you are advised to avoid.
However, I have a tough time finding resources and jump-in points to explore this topic. Can someone point me in the right direction?
TL;DR: How to provide screen-reader compatibility from scratch. Not in detail - but conceptually.
As you have already well identified, your app is an accessibility blackhole because you are using a rendering engine.
It's basicly the same for OpenGL, SDL, or <canvas> on the web, or any library rendering something without specific accessibility support.
WE can talk about several possibilities:
Become an accessibility server. Under windows, it means doing the necessary so that your app provide accessible components on demand from UIA / IAccessible2 interface.
Use a well known GUI toolkits having accessibility support and their provieded accessibility API to make your app.
Directly talk to screen readers via their respective API in order to make them say something and/or show something on a connected braille display.
Do specific screen reader scripting
However, it doesnt stops there. Supporting screen readers isn't sufficient to make your app really accessible. You must also think about many other things.
1. Accessibility server, UIA, IAccessible2
This option is of course the best, because users of assistive technologies in general (not only screen readers) will feel right at home with a perfectly accessible app if you do your job correctly.
However, it's also by far the hardest since you have to reinvent everything. You must decompose your interface into components, tell which category of component each of them are (more commonly called roles), make callback to fetch values and descriptions, etc.
IF you are making web development, compare that with if you had to use ARIA everywhere because there's no defaults, no titles, no paragraphs, no input fields, no buttons, etc.
That's an huge job ! But if you do it really well, your app will be well accessible.
You may get code and ideas on how to do it by looking at open source GUI toolkits or browsers which all do it.
Of course, the API to use are different for each OS. UIA and IAccessible2 are for windows, but MacOS and several linux desktops also have OS-specific accessibility API that are based on the same root principles.
Note about terminology: the accessibility server or provider is your app or the GUI toolkit you are using, while the accessibility client or consumer is the scren reader (or others assistive tools).
2. Use a GUI toolkit with good accessibility support
By chance, you aren't obliged to reinvent the wheel, of course !
Many people did the job of point 1 above and it resulted in libraries commonly called GUI toolkits.
Some of them are known to generally produce well accessible apps, while others are known to produce totally inaccessible apps.
QT, WXWidgets and Java SWT are three of them with quite good accessibility support.
So you can quite a lot simplify the job by simply using one of them and their associated accessibility API. You will be saved from talking more or less directly to the OS with UIA/IAccessible2 and similar API on other platforms.
Be careful though, it isn't as easy as it seems: all components provided by GUI toolkits aren't necessarily all accessible under all platforms.
Some components may be accessible out of the box, some other need configuration and/or a few specific code on your side, and some are unaccessible no matter what.
Some are accessible under windows but not under MacOS or vice-versa.
For example, GTK is the first choice for linux under GNOME for making accessible apps, but GTK under windows give quite poor results. Another example: wxWidgets's DataView control is known to be good under MacOS, but it is emulated under windows and therefore much less accessible.
In case of doubt, the best is to test yourself under all combinations of OS and screen readers you intent to support.
Sadly, for a game, using a GUI toolkit is perhaps not a viable option, even if there exist OpenGL components capable of displaying a 3D scene.
Here come the third possibility.
3. Talk directly to screen readers
Several screen readers provide an API to make them speak, adjust some settings and/or show something on braille display. If you can't, or don't want to use a GUI toolkit, this might be a solution.
Jaws come with an API called FSAPI, NVDA with NVDA controller client. Apple also alow to control several aspects of VoiceOver programatically.
There are still several disadvantages, though:
You are specificly targetting some screen readers. People using another one, or another assistive tool than a screen reader (a screen magnifier for example), are all out of luc. Or you may multiply support for a big forest of different API for different products on different platforms.
All of these screen reader specific API support different things that may not be supported by others. There is no standards at all here.
Thinking about WCAG and how it would be transposed to desktop apps, in fact you are bypassing most best practices, which all recommand first above anything else to use well known standard component, and only customize when really necessary.
So this third possibility should ideally be used if, and only if, using a good GUI toolkit isn't possible, or if the accessibility of the used GUI toolkit isn't sufficient.
I'm the autohr of UniversalSpeech, a small library trying to unify direct talking with several screen readers.
You may have a look at it if you are interested.
4. Screen reader scripting
If your app isn't accessible alone, you may distribute screen reader specific scripts to users.
These scripts can be instructed to fetch information to give to the user, add additional keyboard shortcuts and several other things.
Jaws has its own scripting language, while NVDA scripts are developed with Python. AS far as I know, there's also scripting capabilities with VoiceOver under MacOS.
I gave you this fourth point for your information, but since you are starting from a completely inaccessible app, I wouldn't advise you to go that way.
In order for scripts to be able to do useful things, you must have a working accessible base. A script can help fixing small accessibility issues, but it's nearly impossible to turn a completly inaccessible app into an accessible one just with a script.
Additionally, you must distribute these scripts separately from your app, and users have to install them. It may be a difficulty for some people, depending on your target audience.
Beyond screen reader support
Screen reader support isn't everything.
This is beyond your question, so I won't enter into details, but you shouldn't forget about the following points if you really want to make an accessible app which isn't only accessible but also comfortable to use for a screen reader user.
This isn't at all an exhaustive list of additional things to watch out.
Keyboard navigation: most blind and many visually impaired aren't comfortable with the mouse and/or a touch screen. You must provide a full and consist way of using your app only with a keyboard, or, on mobile, only by standard touch gestures supported by the screen reader. Navigation should be as simple as possible, and should as much as you can conform to user preferences and general OS conventions (i.e. functions of tab, space, enter, etc.). This in turn implies to have a good structure of components.
Gamepad, motion sensors and other inputs: unless it's absolutely mandatory because it's your core concept, don't force the use of them and always allow a keyboard fallback
Visual appearance: as much as you can, you should use the settings/preferences defined at OS level for disposition, colors, contrasts, fonts, text size, dark mode, high contrast mode, etc. rather than using your own
Audio: don't output anything if the user can't reasonably expect any, make sure the volume can be changed at any time very easily, and if possible if it isn't against your core concept, always allow it to be paused, resumed, stopped and muted. Same reflection can apply to other outputs like vibration which you should always be able to disable.
How can I ensure (or try to make) web access available for all - who may have a variety of disabiltes?
Any advice for any standards or web sites that could give me some pragmatic advice for the design of a site?
There are a number of considerations you need to address here, if your website isn't catering for a specific disability then you have to work on a broad range of features. In this situation the first thing you need to remember is that you sadly can't cater to everyone. Look at the list below and identify which of these disabilities you can sensibly cater for
Visual: Visual impairments including blindness, various common types
of low vision and poor eyesight, various types of color blindness;
Motor/Mobility: e.g. difficulty or inability to use the hands,
including tremors, muscle slowness, loss of fine muscle control, etc.,
due to conditions such as Parkinson's Disease, muscular dystrophy,
cerebral palsy, stroke;
Auditory: Deafness or hearing impairments,
including individuals who are hard of hearing;
Seizures: Photoepileptic seizures caused by visual strobe or flashing effects.
Cognitive/Intellectual: Developmental disabilities, learning
disabilities (dyslexia, dyscalculia, etc.), and cognitive disabilities
of various origins, affecting memory, attention, developmental
"maturity," problem-solving and logic skills, etc.
The easiest here is the Seizures, eliminate flashing / strobing content from your site, or more importantly if you cant put up a warning before displaying this type of content.
Users with Motor / Mobility issues may have problems interacting with content on your site that requires a high amount of precision, this can be helped by increasing the size of your UI elements, or allowing the user to resize these elements if needed.
Generally make anything clickable as large as is feasible and if you have elements that have features such as drag drop, make the drag handles large so the user doesn't have to click a tiny area.
Auditory is also a fairly easy consideration to make, at the least simply provide text alternatives to any media content your site may have, for larger sites using video then considerations such as sign language may be an option.
Visual is probably the most common consideration web developers need to make. Firstly partially sighted users may want to increase the text size to your page, so make sure that your UI can cope with this. Use clear and readable fonts and make sure there is contrast between the background color and the font color.
Color blind users may wish to change your site color scheme to meet their needs, you can find information easily on the types of color blindness and develop a couple of alternative CSS styles to meet these needs. Also a high contrast option for everything on your site may benefit partially sighted users.
Cognitive / Intellectual is one of the harder considerations to meet, so look at the individual disabilities. ADD for instance makes it hard for a person to focus and makes them easily distracted, considering this think about advertisements, they are designed to distract us and draw our attention, thus by limiting advertisements on your site you can get rid of the ones that flash and scream Click ME!.
Dyslexic users may struggle with reading huge chunks of text which also fits in with considerations for partially sighted people, here you could have an audio option so the text is read aloud to the user.
One more consideration here is the use of color in your website. It has been proven that certain colors can stimulate emotions, for someone with emotional or developmental issues using colors that are considered calming vs ones that excite (reds for example) may improve their experience of your website.
All of the above are design considerations, looking at the development (Code) next there isn't too much you can do, most of the considerations about your code are because of third party applications interacting with your site.
Generally make sure your code is well formed, correct tags / closing tags etc. Make sure it is valid HTML / XHTML / CSS etc if you can validate to the strict standards it wont hurt your cause. Tags such as links / images should have appropriate Alt text to describe what the element is, for instance alt="image1" is fairly useless to a screen reader but alt="Image showing ...... clicking this will take you to....." is useful.
If you can find some trial software grab yourself a screen reader, load up your website, close your eyes and try interact with it, its going to be hard but at least you can see how your user will interact with your site and more importantly you can use the screen reader to check your site actually gets read the way it should.
There are plenty of 3rd party plugins you can integrate with your site to aid your users too, so look into those, things like the option to magnify text or read aloud with just a click will be well received as long as they are not too intrusive to your non disabled users.
Helpful links
http://www.w3.org/TR/WCAG10/ The W3C Disability guidelines are a good place to start
http://en.wikipedia.org/wiki/Web_accessibility Wikipedia web accessability
http://www.etre.com/tools/colourblindsimulator/ Allows you to see how images will appear to colourblind users
http://colorfilter.wickline.org/
http://www.w3.org/WAI/ W3C Web Accessability Initiative Guidelines
Section 508 is the section of the law that requires that US government websites be accessible.
More information is here, including best practices on making content accessible to all.
http://www.section508.gov/
Generally you should support screen readers by using semantic markup, and avoid flashy content and audio -- these are usually impossible or just difficult to make accessible.
You should also look at web typography guidelines and look to hiring a good designer. Poor color schemes, typefaces, and font sizes make reading on the web much harder than it needs to be.
If you're from the UK, from a legal POV you want to be looking at the Equality Act (which replaced the Disability Discrimination Act).
The foundation of web accessibility is based on the graceful degradation/progessive enhancement model (sounds more complicated than it is!). A List Apart wrote a great article on it some time ago.
A good starting point for web professionals is the RNIB's Web Access Centre. Obviously this mainly deals with those user who experience visual disability, but it's a very useful resource.
Web AIM is also a good site for resources/articles although I'm not sure how often it's maintained these days (still, the information there is relevant).
There are far too many individual little things to bear in mind when developing accessible interfaces, but if you take the time to read some of the articles on those sites, you'll pick up the fundamentals which will then lead you onto the more nitty-gritty things.
Accessible development is about a change in mindset as much as learning the nuts and bolts. You need to to be constantly asking yourself "How might other people use this? What barriers might be in their way? What browser are they using? Does this work without colour/JavaScript/CSS?". Learn how to take your site apart and see if it still works.
Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is the W3C Recommendation from Web Accessibility Initiative (W3C/WAI).
An overview can be found here: http://www.w3.org/WAI/intro/wcag20
There are very broad Principles as well as precise Techniques (for HTML, CSS, JS, Flash, etc) and the intent of each and every criteria. These aren't documents meant to be read at once and you'll want to learn more from tutorials and articles found on the web (archives at 456 Berea Street, WebAIM, videos about accessibility)
The W3C Quick Reference guide to WCAG 2 lists all of the relevant techniques you'll need to implement the WCAG2 principles and guidelines that Felipe mentioned, with code examples if appropriate on the individual technique pages. If it's all a bit too technical for you, WebAIM's checklist is the same thing only in plain English.
Unfortunately there's no magic wand for getting sites to be compliant. You have to go through each bit of content and test it and modify it if necessary. Luckily, even some small improvements can make a big difference.
A lot of good answers, but I can't help adding my input as well.
If you want to ensure a website is disabled friendly, there are a number of considerations that should be taken. One that I have not seen on here (perhaps because I skimmed) is to ensure that you use high-contrast colors, with a solid background behind text.
However, you should NOT use white on black or white on black...dyslexics commonly cannot see those colors. Use an off-white for background or text.
Also, make sure your text is large. Ensure as much of the content as possible is standard text, so that text-to-speech programs can "read" the website. Text-to-speech cannot read images. Text links instead of buttons would also be advisable, for the same reasons (though there may be a means of associating text with a button for these scenarios...?)
this is my firts post here ever.
I have to develop an aplication for a group of people with special needs. The functionality is really trivial, however, i have no clue of how to do the interface for them to be able to use it.
Their intelectual habilities are perfect, they are actually studying high school, but one of them types with his nose which needless to say, is very dificult and another one types reaaaaaaally slowly with only one of his fingers and neither can use the mouse.
I was wondering if i could use javascript to develop a usable interface, based on huge grids or something like that or maybe you guys have a better idea.
Political incorrectness aside, why don't you ask them? You're talking about accessibility here, if they're using computers they must be able to tell you about what they like or dislike about user interfaces that they've encountered.
I'm going to split my answer into two parts - design and implementation.
From a design perspective, it's important not to be intimidated by the fact that the users use a computer in a different manner. Treat this like any other project. Observe how they currently use other apps, and ask about the kind of things that they find helpful, or have difficulty with. If they claim nothing is difficult, ask a teacher or assistant, who will be familiar with the kind of things they struggle with.
Once you've started implementation, try an idea and get initial feedback. If you simply ask how they find the prototype, they'll likely say it's ok. Instead, try observing them using it without saying anything or giving guidance. If they get stuck, let them find their own solution to the problem. If appropriate, you could ask the user to speak their thoughts out loud (e.g. "I need to save this form, so I'm scrolling to the bottom, and clicking save").
On the development side, try to use web standards (valid HTML, CSS and Javascript). People often point to the "Web Content Accessibility Guidelines 2.0" (WCAG2) but this is quite turse and hard to understand; there are many more friendly articles on "Web Accessibility".
Someone with a physical disability is likely to use an alternate input device, such as a "Switch", onscreen keyboard, head-tracking device, a device for pushing keys on the keyboard, or speech recognition. Many of these methods involve simulating the keyboard, so by far the most important thing is to consider the accessibility of your site without using a mouse. For example, try tabbing through the page to see if you can access all elements in a reasonable amount of time. Consider using the acesskey attribute to provide an easy way to jump to different parts of the page (using 0 through 9 is often recommended so you don't interfere with browser shortcuts).
Also make sure that no part of your site is time-dependant, as different users may take different amounts of time to perform a task. For example, don't use the onchange Javascript event to update a page based on a listbox selection. Ensure you have alt text for images, so it's accessible for speech recognition. make the pages short enough so that excessive scrolling isn't required, but not so short as to require following lots of links.
Those are just some ideas to get your mind going in the right direction - but there are many accessibility resources on the internet - steal freely, and don't reinvent the wheel.
I realise I haven't addressed your question about Javascript - that's because I think it's probably one of the less important considerations. If possible, use Progressive Enhancement techniques to make the site work with and without Javascript. You might also look into the WAI-Aria standard for giving semantics to your Javascript.
And finally, to reiterate my initial point - make something simple, show it to the users, tweek, and show again.
It doesn't really matter what technology you use. Use whichever suites you.
But, make sure that you make UI components BIG in size(Bigger buttons, bigger font, bold font, coloured font(are there any colour blind?). This is for the ease of use of people (you said someone types with nose).
Also, better to have audio as informative source along with the usual screen display whenever some wrong action is performed on the application. This way visually impaired people will be assisted more.
Do it well, you are doing a divine job.
The first thing that you should read up on is the Web Content Accessibility Guidelines written up by the W3C.
In a nutshell this document describes the basic principles for people with disabilities in general.
For your needs regarding persons with special needs, you might want to look at Jakob Nielsen's article on Website Usability for Children, wherein principles of web design for young children or people with otherwise limited cognitive ability are outlined.
At what point does accessibility become non-pragmatic? and what is that shady gray area dictated by?
My guess is that as legislatures catch up, we are not far from having legally mandated accessibility requirements in the same way that physical buildings, workplaces, and the like have to adhere to accessibility requirements. Such legislation will often eliminate the doubts.
Since accessibility generally means providing the services to as many people as possible, no site is universally accessible, even by merit of not covering all languages. It's common to stick to a few main languages or countries, though it's good to design for expansion (the way that Amazon does).
As for disabilities, sometimes it depends on the site and the services it provides.
I personally think that as the population ages, it makes sense to address low-vision customers who use assistive devices, so websites that are text based and low on flash/scripts make a lot of sense. That being said, users with small mobile devices have similar needs so you can catch two birds.
It depends on your software. Making a word processor accessible is a lot more necessary then making the latest first person shooter accessible. As a blind computer user I get angry if Microsoft Office doesn't work, but don't care if I can't navigate the menus in Quake III. It also depends on your customers: if you are selling to the government than accessibility is going to be mandated (at least in America). Accessibility isn't mandated for most non-governmental companies, though, so you can get away with as much or as little accessibility as your conscience, time restraints, and budget force you to implement.
There's another kind of anti-pragmatism going on:
Firms scrambling to comply with the letter of the law (e.g. 508), and throwing together whatever low-hanging fruit they they can find, just to be on the safe side, but not actually applying any resources to implementing accessibility as a design solution.
Peppering your html with tabindex and aria attributes (which may not even be necessary) can easily make your site no more accessible, or less usable, than doing nothing.
This kind of thing (which is not unusual) certainly strikes me as anti-pragmatic.
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?
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.