Impact on Techniques of baseline proposal

Below is a very high-level take on the impact on Techniques of the proposal to externalize baseline from WCAG. This was developed by Michael Cooper, Ben Caldwell, and Becky Gibson. We recognize this as incomplete - in particular we need to walk through the techniques and look at them one by one - but this is what we can see at the high level.


Because a baseline is not defined in WCAG, we cannot write techniques to a particular baseline. Instead, we must write techniques within each technology for each success criterion from a few perspectives:

* Techniques for technologies that are in the baseline and supported by user agents
* Techniques for technologies that are not in the baseline and equivalents alternatives are required, most likely in a "host" technology (e.g., noscript for scripts)
* Techniques designed to address known problems with user agent support for technology features.

"Technologies" are document formats like HTML, CSS, etc., though we might need to be more specific to User Agents here. Techniques would indicate in prose and metadata to which of these categories they belong, and would provide information to help authors make reasonable choices about their baseline. Authors would select techniques to follow based on baseline and, to some extent, user agent target information. The WCAG WG would provide a few non-normative recommendations on appropriate baseline and advise on techniques to follow for each of those predefined baselines, but authors would be free to choose other baselines and would have to select techniques to follow accordingly based on the information available in the techniques.

The goal for techniques is to clarify (through identification of sufficient and advisory techniques) what example strategies that can be used to claim conformance at a particular point in time. In other words, the impact on techiques is not that information about baseline needs to be excluded, but instead that baseline assumptions and the relationships between techniques that hinge on various baseline choices need to be clear.

We recognize it will not be possible to inventory all possible techniques in each of the three above categories. In particular, we will only be able to mention techniques for a small number of user agents. We did an inventory of user agents [1] and will need to select which user agents to support.

A major issue that comes up for us is the concept of "graceful degradation". The temptation is to require that technologies not in the baseline fall back gracefully if not supported, which is to say the page is still functional when the technology is not supported, even if less attractive or missing some features. This can have an impact on the accessibility benefits, especially to understandability, that may be provided by the technology. If we need to address that issue we would have to provide techniques for emulating the features of the technologies within the fallback, but this is often in contradiction to other recommendations we would like to make. For instance, to allow for graceful fallback of CSS, do we have to require the use of layout tables and <font> elements to make sure the layout is preserved as much as possible to support understandability?

We will need to conduct an analysis of each of the existing techniques from this perspective to evaluate the full impact of baseline.

Michael

[1] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/att-0404/draft_test_matrix.html

--- Signature ---

Michael Cooper
Accessibility Product Manager, Watchfire
1 Hines Rd Suite 200, Kanata, ON  K2K 3C7  Canada
Tel: +1 (613) 599-3888 x4019
Fax: +1 (613) 599-4661
Email: michaelc@watchfire.com
Web: http://www.watchfire.com/

Received on Thursday, 31 March 2005 17:51:28 UTC