Accessibility is a general term used to describe the degree to which a product (e.g., device, service, environment) is accessible by as many people as possible, and the ventures to produce accessible products and services. Accessibility is often used to focus on people with disabilities and their right of access to entities, often through use of assistive technology.
The Web Accessibility Initiative (WAI) is a key resource for usable web accessibility. WAI’s accessibility standards are developed through the W3C process in cooperation with individuals and organizations around the world, with a goal of providing a set of standards that meets the needs of individuals, organizations, and governments internationally. In addition to standards, WAI produces many documents that offer guidance on how to include accessibility in a good user-centered design process, including people with disabilities and their needs early in the process. Other work of WAI focuses on how building on the benefits of accessibility for other audiences, such as older adults, people on limited bandwidth and users of mobile devices.
In order to make your website as accessible as possible, not only to users with disabilities, but also to those with slow connections, or different browsers or operating systems, the best guidelines to follow are those offered by the World Wide Web Consortium (W3C) Web Accessibility Initiative.
This paper presents two sides of a debate over user-controlled text sizing of Web-based documents, and a suggested approach for designing Web sites that support full use of user-controlled text sizing, while maintaining the integrity of a site’s visual design.
For many web developers, accessibility is complex and somewhat difficult. The Accessibility Project understands that and we want to help to make web accessibility easier for front end developers to implement.
On an increasing number of web sites you can find the phrase "accessibility statement". Sometimes it is very visible and hard to miss, in other cases we can barely find it. Did you ever read any of these statements? If you ever did, do you read it on all sites where you find them? In this article I will explain what is the accessibility statement, and give you a couple of points to decide if you need it on your web site.
How do software companies evaluate whether accessibility criteria mandated by law are met? Confirmation is often provided by filling out a checklist. However, the method used for determining compliance to the checklist is not specified. Typically the task of filling out the checklist is done by accessibility specialists, usability professionals, quality assurance testers, or, in one case we know of, the development team that wrote the software. We have conducted several types of accessibility evaluations, walkthroughs, and testing with scenarios by sighted test participants and testing by blind test participants. While testing with blind participants takes considerable preparation time, we have uncovered important findings that were not revealed with sighted participants. We consider accessibility testing by blind participants an important component of our evaluations.
Empathy is what separates us from the rest of the animal kingdom. We have an ability to imagine things the way that others see them and how it makes them feel. We don’t even have to have a disability ourselves. Accessibility is NOT a checklist. Accessibility is about usability. Accessibility is a paradigm shift. Accessibility is a personal issue.
It's been a long trip, but we’re almost out of the dark. We finally have browsers that offer substantial support for several technologies established by the World Wide Web Consortium (W3C) and other standards bodies. Designers and developers can use many core features of XHTML and CSS and sometimes DHTML without worrying about the hazards of cross–browser chicanery. As browsers have evolved, it’s become easier to comply with the W3C’s Web Accessibility initiative (WAI) and, in the United States, with the amendments to Section 508 of the Rehabilitation Act of 1974 (commonly called “Section 508”).
I'm not saying we shouldn't do it; I just wish the conversation about accessibility would be more frank when it comes to the opportunity costs and real costs to implement it. And I'm embarrassed by my own petty frustration in having to accommodate someone who has a real beef with the world and a legitimate cause for frustration.
And, as a result, selling the concept is never all that easy. Sure, you can harp on about all the 'business benefits' (potential increased audienced, reduced bandwidth costs, good PR), but what you really need to be able to do is show that it's possible to do this without compromising on the design. That's often where the problems begin.
The demand for accessible sites is growing, but web workers, like you, are often unclear how to make sites more accessible. Designing an accessible site isn't necessarily harder, but it involves unique limitations that make you approach design from a different perspective.
Making the Web more accessible for users with various disabilities is to a great extent a matter of using HTML the way it was intended: to encode meaning rather than appearance. As long as a page is coded for meaning, it is possible for alternative browsers to present that meaning in ways that are optimized for the abilities of individual users and thus facilitate the use of the Web by disabled users.
I’ve been thinking about one particular artifact of the folksonomy phenomenon — the folksonomy menu that serves as a sort of buzz index providing users with a quick visualization of the most popular tags (technically I think it’s called a weighted list). Popular tags are displayed in a larger font and it’s relatively easy to identify hot topics at a glance. This visual representation of the popularity of any given tag is undeniably cool. However, once the coolness factor wears off it becomes fairly obvious that these menus are also not very accessible.
Forms are often the most tricky aspect of web development for beginners to get their head around, largely because it means stepping out of the comfort zone of one-way information - no longer are you simply presenting information at the person viewing your site, now you are asking for input, for feedback that you have to process in some way. And just as it may be difficult for HTML beginners to understand just how they handle form data, so is it difficult to understand some of the issues relating to accessibility.
Though somewhat rare, there are occasions when the accessibility needs of screen reader users appear to be at odds with the needs of visual users. This kind of conflict occurs when Web developers put form elements inside of a data table matrix, when they want to use images as headings instead of text, and in other situations. Adding extra text helps screen reader users, but can complicate the visual layout, thus reducing understandability. One solution is to use CSS to hide the text from sighted users in a way that is still accessible to screen readers. The details of this technique are discussed, along with the technical reasoning behind it.