Aspects of accessibility that we agree upon

Given the huge debate (amount of email and heat) on 'accessibility', and the fact that slowly people with different views (Position A and Position B, as it has been simplified) appear to be getting closer to at least understanding each other a little better, it seems useful to try to list those aspects of accessibility on which there is a reasonable amount of agreement. If we can at least have reasonable agreement on what we agree on, it could become a little easier to start concentrating on those aspects we still have big disagreements over.

Introductory note on terminology

Accessibility and universality

Not everybody within the HTML WG uses the term "accessibility" in the same meaning. Some use it to indicate "accessible to all users in all browsing situations", some use it to indicate "accessible to users with disabilities". This has caused some communication problems.

It appears that within W3C, the term "accessibility" is defined to mean "access for people with disabilities", and that "universality" is defined to mean "accessibility for all users in all circumstances". Although some of us would favour using words in their regular dictionary meaning, given that we are a W3C WG, it may be the most practical if we adopt that W3C terminology and meaning. At least so we can avoid misunderstanding each other needlessly.

fallback, alternate, and equivalent

There has been a lot of confusion and miscommunication due to people using different terms for the same and the same terms for different things. We appear to be agreeing now on using these three terms thusly:

• "equivalent" refers to the meaning of the content. For instance, both an image and the contents of its alt attribute are to convey the same. Thus "equivalent" refers to the meaning, not to a mechanism
• "alternate" refers to the mechanism through which equivalents are provided and can be chosen from by the user
• "fallback" refers to the UA mechanism of automatically presenting an alternate when the 'main' equivalent can for whatever reason not be presented.

At this stage these distinctions appear to be necessary. To authors and users, "fallback" sounds like as if an equivalent is somehow 'less'. Even though to a given user, it may very wel be more. But for a developer dealing with parsing HTML and deciding what to present, the term "fallback" makes perfect sense, as that describes what his code is doing.

Agreements

Uniformity of markup

The more unified the mechanisms are that authors have available to provide universality or accessibility, the easier their job will be, and the more likely they will bother.

Although there have been some proposals, there is no consensus yet on how to achieve this uniformity.

HTML5 must provide universality

Many accessibility problems would best be solved through rather precisely targeted solutions. Some exampes:

• Take a video with sound: for a deaf person, a captioned video may well be the ideal alternate. Text, especially markked up, would also help, but would offer a less rich, or at least a substantially different type of experience
• for someone who is blind, for that same video an audio equivalent might be more ideal than a textual equivalent.

However, those ideals cannot be provided by HTML itself. They rely at least in part on third-party authoring tools, file formats, plug-ins, etc. Even where HTML can provide the ideal solution, it would probably be for that accessibility issue only. There's no way the HTML spec itself can provide the ideal accessibility for all.

What HTML can provide however, is textual equivalents for all non-textual objects. If it can provide marked up textual equivalents, that would be even much better. Not only because it could provide users with a more rich equivalent, but it seems likely that authors would be more encouraged to bother (as opposed to the plain text poverty of @alt).

Thus there appears to be consensus that HTML can and should provide for at least a sort of 'base level accessibility', or uniformity, and that ideally that should be in the form of marked up text.

There is no consensus yet on how to achieve that, because textual equivalents are not possible with the IMG element and we don't yet know/agree on how to solve that.

HTML5 should provide ideal acceptability

We seem to agree that it would be great if HTML could allow for ideal equivalents for specific accessibility issues, but we still have to start looking into those, case by case. It may well be that in many cases HTML cannot provide the ideal alternate.

Things like @scope and @headers appear to, at least at the moment, fall into this category.

All equivalents must be available to users

Sometimes consuming multiple equivalents is useful. For instance for someone relying on screen magnification it can be useful to consume an image, but also its textual equivalent. Even for someone with excellent eyesight it may not always be obvious what an image is meant to convey. Access to an equivalent would be helpful. A user may simply distrust that an equivalent is in fact an equivalent, or feel that in that particular situation the default fallback is not the ideal equivalent.

(This touches upon the need that equivalents can be consumed side by side. For example, it can be useful to listen to audio and read its transcript simultaneously. There is no idea yet though how a UA could implement a universal simultaneous presentaton of equivalents. Possibly reviewing individual use cases (which user in which situation would need to access which types of equivalents simultaneously) can help us get an idea of how that could work.)

Several approaches are being discussed but there is no agreement yet on how to achieve this.

Disagreements

Although the point of this document is to index what we agree upon, there are 1 or 2 disagreement that seem to be big enough obstacles that they disserve listing here:

equivalents need to be marked up as such explicity

This river appears to still be far from bridged. Some are convinced that explicitly is a requirement, others that it would be better to leave this up to author prose.

Do not throw away what little we have

Although only a small group of users benefits from current HTML accessibility features as they are authored, to that group they are absolutely essential. At least until something betters comes along. (Applies to things like @alt, @longdesc, @headers, @summary, etc.)