Author: Richard Ishida
This document provides ideas to stimulate discussion during the first face-to-face meeting of the GEO (Guidelines, Education and Outreach) Task Force of the W3C I18N Working Group. All of the content is open for discussion and liable to change. The intent is merely to provide a 'stake in the ground' to stimulate discussion and provide a base for capturing additional ideas.
This document assumes a very basic familiarity of the work of the Web Content Accessibility Guidelines Working Group (WCAG WG). WCAG operates within the Web Accessibility Initiative (WAI) at the W3C.
Disclaimer: Note that this is intended to be a WORKING DOCUMENT. No implementation intent is implied. No guarrantees are made about the sensibleness, coherence or good structure of ideas. The document is liable to constant change. I have written this quickly as a stream of conciousness, so please forgive any lack of clarity.
Sections are aligned with suggested topics for discussion for the upcoming face to face (FTF).
The number of topics the GEO group will tackle will depend upon the availability of resources and the interests of the working group members.
I've tried to number the points so that we can refer to them more easily. For example, we could refer to the point about the glossary as point B.1.4.
I think that a consideration of the intended users is a fundamental first step in developing the guidelines. Sounds obvious? Well, yes, but it's not always done first. And there's always the tendency to work out the features/functionality of any web pages as part of the architectural/implementation discussions, rather than as part of the discussion of users' requirements. I think there are a number of areas for discussion, as outlined below.
who are we targeting? - I think we should target specific types of user so that we can test scenarios better. We need to decide what types there are out there, and then decide which ones we can address.
I think we should not approach the work with the mindset of 'how does one marshal all the information out there into a logical and elegant whole'. Rather we should ask ourselves, 'who are we trying to help, and how do we put together the information that they most need in a way that is most acccessible to them'. The user drives this, not the information. This should be a practical, rather than academic, exercise. Our approach is not to create specifications, but to create usable resources.
I think an initial distinction should be drawn between people who:
Should we include authoring tool and user agent developers in our initial group of targeted users? These people may have a much more important impact on the development of the internationalised web. On the other hand, should we initially focus on a perhaps more manageable subset of guidelines such as we would encounter when limiting our scope to content developers?
A small amount of extra detail on this topic can be found at http://www.w3.org/International/geo/plan/geo-scoping.html under the heading "Major customer types".
usability requirements - once we have decided on some user types, we need to consider how to present the information to best fulfill their needs - ie. what features our documents should have, how we should serve them, etc.
I suggest that we initially consider developing something more akin to the WAI Techniques documents (eg. http://www.w3.org/TR/2000/NOTE-WCAG10-HTML-TECHS-20000920/ ) than the WAI Guidelines (eg. http://www.w3.org/TR/WCAG20/). I think it will be easier for us to develop the right genericised guidelines if we start out from this direction, and I think there may be a larger audience for techniques than guidelines at the moment
I suggest structuring the data in such a way that we can extract all the directive statements into a self-standing checklist format, but that we allow people to get more information about a particular checklist point or group of points as needed (incremental disclosure). I think we should write the data in such a way that a beginner can be presented with examples and explanations, and read the information like a book, but then we should be able to present the same data to an expert as a checklist. Even so, the expert may need to read up on an area they are less familiar with, and I think that the architecture should allow them to immediately find detailed information at the right level for the specific topic they are concerned with.
I think it would be useful to allow people to filter out stuff that doesn't relate to their user type - eg. Charset declarations may not be relevant for graphic designers. We'll need to think this through a little to determine which user types are relevant.
I think it would be good to have a separate glossary (but link to that from the text).
I think we may need to make available pointers to additional resources (eg. IANA's charset names) to both experts (ie. checklist users) and beginners alike. This should be on request, though. I expect there will be many instances where people come to the guidelines just to find a link to such things as IANA charset names or lang tag values, etc.
We should probably also consider making these available via the International Activity web pages (Hints & tips) or via a tips database such as Martin mentioned in a recent mail.
Our users may also find it helpful if we provide or point to instructions, rather than just state rules. For example, configuring Apache web servers with correct HTTP Charset.
The v2 WAI guidelines have 'checkpoints' and 'rules'. I think we should have something like the rules, of course, but I'm not sure about checkpoints - at least not until such time as we develop guidelines.
WAI has HTML and CSS techniques, and also has a Core Techniques document. I'm not sure this is a good approach - it forces the user to look in two places for information. I think it would be good to write the information once only, but integrate it into the guidelines relating to any relevant task.
How browser-specific should we or could we be? I know I'd always like to see information about which browsers support what features of a standard. Would that be appropriate though in a W3C deliverable? I feel there's a tension here. It wouldn't be good to recommend the use of a particular construct if it isn't supported by browsers (at least not without mentioning that fact), but it would be good to mention the availability of such features if users would then lobby the user agent or tool developers harder to incorporate support for these features.
Should we target users with particular versions of browsers? Should we worry, for example, about Netscape v4.0 or earlier, or just focus on the capabilities of more recent versions of the main browsers? Or perhaps you think we should completely abstract ourselves from concerns about browser support.
An ideal approach for content developers would be to integrate our guidelines and checks into authoring tools. We should discuss whether this is possible, and whether we should have some activity in this respect parallel to our general guidelines development. This may lead to us developing something along the lines of WAI's ATAG. What would it take? Who would want to do this?
We should consider possibilities for translating the guidelines we develop as soon as is practical. We should be on the lookout for people who would be interested in helping out here. We could even consider whether there are areas of the world where lack of translation is impeding the adoption of the techniques we describe. If so, it would be good to actually look for people who could translate the guidelines for those areas.
subject areas - we need to decide which subject areas to address first, since there are many candidates.
I suggest we start out with some 'low hanging fruit'. To my mind, this would include advice on the correct usage of HTML, XHTML and CSS. These are areas where WAI currently has techniques documents. I would also include the Ruby specification in the low hanging fruit.
We could of course also, depending on the interests of the group, consider use of additional W3C specs such as SVG, XSLT, XSL-FO, DOM, Voice, XForms, XML Schema, etc.. I would like to address at least one of these topics from the beginning. We will need to discuss which is / are most appropriate.
What about non-W3C technologies such as Java, ECMAScript, JSP, ASP, etc? Should we address these?
With regard to CSS, we would need to decide whether to include references to the proposals in CSS3. There is a lot of internationalisation related stuff in CSS3, but of course, it is not yet a recommendation. Having said that, some of the features proposed do already work in browsers (such as vertical text, auto-spacing in ideographic text, etc.). A similar question arises with regards to XHTML 2.0.
This is part of a broader issue. Do we point to proposed new features related to internationalisation, or restrict ourselves to discussing features that are part of current W3C recommendations? Implementations of future features are subject to possible change and browser specific idiosynchrasies - but at the same time, perhaps making people more aware of these through the GEO things will speed up adoption and therefore the internationalisation of the web.
There is another issue that needs to be addressed relating to scope of the guidelines. For example, do we want to include pointers on how to help users navigate to the right localised site? There is a lot to be said on this account and it is definitely advice that is needed, but it is not the same as indicating the intended correct usage of W3C defined technologies. Should we address it? It will probably need some slightly different treatment because there may be no 'correct answer'. We may just want to suggest a number of possible scenarios or best practises. There are a number of areas relating to internationalisation in general, rather than web content specifically. Another example would be the creation of graphics or multimedia that contain cultural bias - hand gestures, colour, symbolism, etc. Does that fall into our remit?
This is closely related to the previous point. I think we should seriously consider the needs of localisers as well as the end user. Several aspects of internationalisation relate to facilitating the process of localisation and / or translation rather than to creating a usable interface for the end user. Examples include the provision of flags for non-translatable elements in DTDs, and the supply of other information needed to maximise efficiency in translation. This is a major concern for the business world, because it influences cost and time to market. I believe we should incorporate the requirements of the localisation industry in our guidelines. We already have a link with the XLIFF team at OASIS with a view to developing localisation requirements.
In this regard, we could consider taking further the concepts at http://www.xerox-emea.com/globaldesign/paper/dtds/dtd-paper.htm which looks at requirements for developing XML dtds and schemas. WAI also has guidelines for XML accessibility..
We should also consider how we can create synergies with the WAI guidelines/techniques. It would be great, in my mind, if a developer could choose to see both WAI and I18N rules when looking for guidance on how to implement, say, a table - rather than have to look the information up in two different places. How could we achieve that? What would it look like? We would obviously need to discuss this thoroughly with the WAI folks.
I can forsee a situation where we uncover gaps in the W3C standards (eg. perhaps a need for a way of specifying particular kinds of locale information, or ways of achieving radically different address forms in XForms depending on the country). We should agree a plan for how to deal with these situations.
Other activities besides guidelines? - we should also consider any other activities we should engage in. For example, creation of a tips database, or improvement of the hints & tips section of the Internationalisation Activity web site. Creation of an area on the website that links to other people's guidelines and tips? etc.
Conformance - at some point we should look at producing conformance logos, like WAI, and levels of conformance. I think we need to develop content first, before addressing this. However, perhaps we should bear it in mind as an end goal.
Once we have agreed on the user's requirements, we should then (and only then) consider how to implement the guidelines in the best way to meet those requirements.
We need to look at possible approaches to serving the guidelines content so that we can serve it up in a number of different ways.
I suggest that the editing process for developing the material should be based on editing in an XML master document (possibly with external entities for repetitive material) and use XSL to transform it into whatever output formats would be appropriate.
I think any output presented to the user should be in XHTML and be encoded in utf-8.
We will need to develop a DTD or XML Schema to support the editing. WAI has a DTD we could look at. (We may want to add stuff to that.) We ought to include internationalisation features in our DTD/Schema.
I'd like to hold a brainstorming session on the EO side of the task force. Suzanne Topping has some ideas in this regard, which she will, I hope, send out prior to the meeting.
I think it would be useful to start brainstorming topics for inclusion. Although we may get many ideas from looking at what's out there (Action: begin looking for what's out there! ), it may also help to think around some of the key activities/tasks that a user will perform that involve i18n.
Its probably worth taking a look at the section headings in the WCAG HTML techniques document. They seemed to me to have quite a good way of organising tasks. Perhaps we can build on and adapt their headings for our needs.
Richard Ishida ([email protected])
$Id: ftf1-discussion.html,v 1.2 2002/11/27 22:33:04 rishida Exp $