The word "accessibility" refers primarily to the degree in which something is accessible by people with disabilities, but in a wider sense it also measures resistance to external or temporary handicaps, such as noisy environments or bad lighting.
The main method to ensure accessibility is to encode data at as high a level of abstraction as possible, but it is also important to hook into already existing accessibility technologies.
The structure/style dichotomy is a clear example of the former: rather than
encoding that something is red, W3C formats allow (and urge) an author to
encode first of all the reason why it is red. The redness is added as
a rule on top of that. With HTML, for example, rather than <font
color="red">, a careful author writes <em
class="warning"> and puts the rule that warnings are displayed in
red in a style sheet. This way somebody who has no means to display (or see)
red at least has a chance to substitute something else that alerts him (such
as a nasty sound).
With XML-based formats, at least the well-designed ones, the
problem should be less than in HTML. In contrast to some versions of HTML,
most XML formats do not have stylistic elements at all. In such formats you
may see an element <warning>, but no
<font>, so a style sheet is obligatory.
Sometimes a whole technology can be seen as an accessibility feature. SVG has other advantages over raster image formats, but a very important point is that it allows the image to be taken apart and traversed as a hierarchy of objects, rather than a collection of colored pixels. You can in effect read out an SVG graphic. And even better if the author has inserted textual descriptions of each object.
Isn't it more work to make accessible resources? Will people not be lazy and omit structure and annotation? Not always. Some people want to be good. Some are required to be good (by law, or by their employer's public image). But it is also the case that properly structured and annotated code is easier to maintain; accessibility is sometimes an investment with an initial cost, but eventual benefit. In well-designed formats the accessibility features aren't added as an afterthought, but are merged with the features for maintainability and code structuring. An SVG graphic can be analyzed and the pieces used again to create a new graphic. A PNG image, on the other hand, is pretty much the end of the line.
The alt and longdesc attributes of HTML's
img element were an afterthought. As a consequence it
feels like an extra effort to have to think of an alt
(=alternative) text. And if you think of a good one, it may not be possible,
because of the limitations of HTML attributes: no way to emphasize a
word of the alt text, no way to make a list or a table, etc.
The img element was added to HTML without thinking about
accessibility (or about some other things for that matter, such as fallbacks
and captions) and the alternatives that were proposed, fig and
object, simply came too late and never really caught on.
Accessibility features have to be integrated from the start, in the
specifications as well as in the tools that implement them.