Version 1.0 of the Web Content Accessibility Guidelines focused heavily on the techniques for accomplishing accessibility, especially as related to HTML. Version 2.0 takes a different approach: it focuses more heavily on the principles of accessibility, and presents some techniques in separate documents. By focusing more on principles rather than techniques, version 2.0 of the guidelines is more flexible, and encourages developers to think through the process conceptually.
The four main guiding principles of accessibility in WCAG 2.0 are:
Perceivable
All forms of communication require input into the brain via at least one of the senses of the body. The Internet is a medium of communication providing access to knowledge and processes through electronic means. The most relevant senses in this context are sight, hearing, and touch. (Other animals have learned elaborate communication systems through taste and smell, but we humans are comparatively deficient in that department. Besides, tastes and smells are harder to transmit electronically.)
Any discussion of web accessibility is based upon the assumption that people need to be able to perceive web content. They need to be able to input the information into their brain so that they can process it. If the information cannot get into the brain, it is inaccessible. As obvious as that statement may sound, it is a principle which is frequently ignored by developers. Too many sites contain web content that cannot even be perceived by some of the people who would like to access it.
Operable
Not everyone uses a standard keyboard and mouse to access the web. Some people use adaptive devices or alternative devices that accommodate their disabilities. Some people simply prefer to use the alternative technologies. While this may not seem like an important point at first, consider the fact that some web content can be operated only with a mouse. Mouse-dependent web content will be inaccessible to a person cannot use a standard mouse—due to tremors, insufficient fine motor control, or even a lack of hands altogether. A person in this situation is likely to use an adaptive technology of some sort, such as a mouth stick, to manipulate the keyboard. In some cases, the person may be able to use a trackball mouse (e.g. with a mouth stick), but others need to rely on the functionality of the keyboard. (See also the motor disabilities article.) People who do not have use of their vision usually rely on the functionality of the keyboard as well. They may be able to manipulate a mouse just fine, but it doesn't do them much good because they can't see where to click on the screen. The keyboard is much easier for a person who is blind to manipulate. (See also the visual disabilities article.)
Keyboard accessibility is one of the most important principles of Web accessibility because it cuts across disability types and technologies. Most of the alternative and adaptive devices used by people with disabilities emulate the keyboard in terms of functionality. Content that is accessible to the keyboard is operable by the devices that emulate keyboard functionality, no matter how radically different those devices are in appearance from standard keyboards.
Understandabile
Let's say that web content is perceivable and operable by all kinds of users of all abilities, but it is understandable to none of them. Is the web content accessible? Of course not. Understandability can be just as big a barrier to accessibility as any of the more technical issues. Talking about understandability moves the discussion into the broader realm of usability. Usability became a hot topic in the late nineties and early 21st century. It still is a hot topic, but has moved from being a fringe fad to being a topic of mainstream conversation among web developers. Web accessibility never achieved "fad" status, but awareness of the topic has also increased over time. Unfortunately, too many people still separate usability and accessibility into two separate disciplines. Trying to separate principles into mutually exclusive categories of "usability" versus "accessibility" would be pointless. There is too much of an overlap between the two. After all, could an unusable site ever be considered an accessible site? Not if accessibility means anything.
Robust
Not everyone uses the same technologies now, nor will they in the future. People use different operating systems, different browsers, and different versions of browsers. Some people have advanced features enabled. Others have these features turned off. Some people are early adopters of new technologies. Others are slow to adapt to the rapidly-changing currents in the flow of technological advances.
Despite the differences between users and the technologies they use, they all expect the web to work. When they go to a site that uses methods not supported by their technologies, they get frustrated and may never return. In the past it was common to sites optimized for certain browsers or versions of browsers. Fortunately, most developers now try to develop their content so that it will work in many versions of many browsers. One of the most noticeable exceptions to this general trend is found in web sites owned by companies which develop their own browsers. They think that they can persuade people to use their company's browser if they create lesser versions of web content for all other brands of browsers. While this may be an effective marketing technique, it is not a good accessibility technique.
Users should be allowed to choose their own technologies to access web content. This allows the users to customize their technologies to meet their needs, including accessibility needs. web content that requires a certain technology, such as a certain browser, may exclude some types of users who either don't want to use that technology or can't use it because of their disability. As a general rule, the more control the user has, the more likely the user will be able to access the content effectively.
Of course, there are limits to this logic. Netscape 1.0 was a revolutionary browser when it was introduced, but has now gone the way of the dinosaurs because technological evolution has produced newer, better technologies. Modern web developers should not be forced to develop to the "lowest common denominator." Older or inferior technologies will never be able to support the full range of possibilities offered by newer, more capable technologies. In fact, the accessibility capabilities of the newer, more capable technologies is also superior. Developers can and should feel free to take advantage of technological advances in all areas, including in areas related to accessibility.
Developers can set a baseline of requirements. For example, they could decide to fully support browsers that are four years old or newer. Users of older browsers could still access the content, but perhaps it wouldn't be styled properly due to lack of support for Cascading Style Sheets. In the case of Adobe Acrobat files, developers may choose to support only versions 5 or greater, since all previous versions had virtually no support for screen reader users. Similar decisions could be made for different versions of media players. As long as the baseline is not too restrictive, limiting full support to a subset of technologies is a reasonable approach. And, again, to the extent possible, it is still best to let the user decide which technologies to use.