- From: Scott Luebking <phoenixl@sonic.net>
- Date: Mon, 17 Dec 2001 09:51:38 -0800
- To: w3c-wai-ig@w3.org
Hi, The consensus item: RE: CLIENT SIDE AND SERVER SIDE SOLUTIONS S1 - serving content in different forms is an acceptable way to comply with the guidelines as long as equivalents for all of the information are provided in the different forms and it is all available through the same URI (though it may be linked to it) (server side solutions are acceptable - as specified) is a paradigm shift with some interesting aspects and ramifications. For example, users of the guidelines will want to know what is needed for a web page which will primarily be used by blind people. Web pages whose audience will be blind people are actually quite easy to format. One general overall layout could be linear with some introductory information at the top, followed by a document index which starts with a skip link, followed by significant elements in order of importance. There probably needs to be some usability testing on possible formats to recommend in guidelines. If a separate version is provided without all the flashy items which makes use of web pages harder by blind users, this could simplify the demands on browsers for handling accessibility issues. The burden would then move more to authoring tools to produce multiple versions of web pages. However, it might in a way actually simplify the task of authoring tools. An authoring tool could keep track of significant elements in a web page and could check that the same elements are in the blind version. Or the authoring tool could generate a web page with additional information stored in comments about how the web page should be generated by a server for blind users. A slight more complicated approach would be to use self-configuring web pages using configuring statements, macros, symbols, etc. A more complicated approach could be using XML for situations where the content of various documents have a similarity. I believe the correct tools to produce multiple versions of web pages would improve efficiency. For one version of web page, developers can go crazy and not have the additional work of making sure that accessibility requirements are being met. In another version, the design will be simpler which means that there can be more focus on accessibility. Another that efficiency could be improved is that the simpler version could have its accessibility checked more easily. Scott > Hi > > > Looking at the further discussion, I have some revised thoughts. > Speaking for myself only, the ends are more important than the means. > Therefore, from my pperspective, if the means to provide increased accessibility (and usability) to a wider range of users is by creating multiple versions (at the site or page or page element level) on the fly, then > that is perfectly fine. It's hard to say, in the general case, if there is such a thing, how practical this is. > As long as > 1. equivalent information is provided via all the different versions > and > 2. all the versions are kept equally up to date, > then the end is achieved. > > The phrase "universal design" to me simply means to take different groups into account. It seems to me that both Scott's design outline and that expressed in WCAG are both > "universal design" and the differences is at > the implementation of the design. I hope I'm not muddling up the distinction, I'm just trying to see where precisely we disagree, if we really do disagree. > > For example, Scott's step 4 > 4. for each group of users, identify approaches which can be > used by users in the group to meet their needs given their > characteristics. (here's where the creativity in pushing bounds > and coming up with original solutions can come into play) > > iterates over "groups of users" whereas that expressed in WCAG seems to iterate over something like "information chunk" which mostly corresponds to "page element" as opposed to entire page or site. > (e.g. For each element, provide an equivalent...) > Could this difference in the early design phase account for the difference? Am I making any sense? > > Steve
Received on Monday, 17 December 2001 12:51:49 UTC