- From: Richard Ishida <ishida@w3.org>
- Date: Thu, 31 May 2007 13:41:09 +0100
- To: <public-i18n-core@w3.org>
Folks, I made some brief notes below wrt what I would reply to WCAG. I'm sending to this list for people to make additional comments and consider in preparation for me seeking endorsement during next Tuesday's telecon. (I'll probably edit my text below before sending to WCAG folks - these are just rough notes.) Please take a look. This is the first of two emails from Loretta. (Note that I will also reply with a separate email for each original comment - reinstating the original subject lines, to make it easier for us to track the issues.) RI ============ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] > Sent: 18 May 2007 00:42 > To: Richard Ishida > Cc: public-comments-WCAG20@w3.org > Subject: Your comments on WCAG 2.0 Last Call Draft of April > 2006 (1 of 2) > > Dear Richard Ishida , > > Thank you for your comments on the 2006 Last Call Working > Draft of the Web Content Accessibility Guidelines 2.0 (WCAG > 2.0 http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We > appreciate the interest that you have taken in these guidelines. > > We apologize for the delay in getting back to you. We > received many constructive comments, and sometimes addressing > one issue would cause us to revise wording covered by an > earlier issue. We therefore waited until all comments had > been addressed before responding to commenters. > > This message contains the comments you submitted and the > resolutions to your comments. Each comment includes a link to > the archived copy of your original comment on > http://lists.w3.org/Archives/Public/public-comments-wcag20/, > and may also include links to the relevant changes in the > updated WCAG 2.0 Public Working Draft at > http://www.w3.org/TR/2007/WD-WCAG20-20070517/. > > PLEASE REVIEW the decisions for the following comments and > reply to us by 7 June at public-comments-WCAG20@w3.org to say > whether you are satisfied with the decision taken. Note that > this list is publicly archived. > > We also welcome your comments on the rest of the updated WCAG > 2.0 Public Working Draft by 29 June 2007. We have revised the > guidelines and the accompanying documents substantially. A > detailed summary of issues, revisions, and rationales for > changes is at > http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please > see http://www.w3.org/WAI/ for more information about the > current review. > > Thank you, > > Loretta Guarino Reid, WCAG WG Co-Chair > Gregg Vanderheiden, WCAG WG Co-Chair > Michael Cooper, WCAG WG Staff Contact > > On behalf of the WCAG Working Group > > ---------------------------------------------------------- > Comment 1: > > Source: http://www.w3.org/mid/20060627170742.9C4774F144@homer.w3.org > (Issue ID: LC-1370) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-WCAG20-20060427/ > > Comment 1 > At http://www.w3.org/International/reviews/0606-wcag2/ > Editorial/substantive: E > Owner: RI > > Location in reviewed document: > Introduction > > Comment: > The content of the introduction is long and written in a > legalistic style that is hard to get through. I think this > can putoff, or at least scare, web designers and content authors. > > > I suggest that you provide short summaries of each major > section, written in a friendly style, so that people can get > thegist of the section. That way the complex normative text > can remain, but does not have to be read in detail until needed. > > > Also, use more active phrasing. For example, "The set of > technologies that an author assumes are supported and turned > on inaccessible user agents is called a baseline." could be > written "A baseline is what we call the set of technologies > that an author assumes aresupported and turned on in > accessible user agents." This is easier to read, makes it > easier to find the definition of 'baseline', and gives a > quickeridea of the content of the paragraph for those who are > skimming text. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have reworked the entire document to make it shorter and > easier to read and understand with different levels of > expertise. This includes > > Easier language to understand > - Wrote simpler guidelines > - Removed as many technical terms (jargon) as possible > replacing them with plainer language or, where possible, > their definitions > - Eliminated several new or unfamiliar terms. (authored unit, etc.) > - Removed the term Baseline and replaced it with "web > technologies that are accessibility supported" and then > defined what it means to be accessibility supported. > - Removed the nesting of definitions where we could (i.e. > definitions that pointed to other definitions) > - Tried to word things in manners that are more > understandable to different levels of Web expertise > - Added short names/handles on each success criterion to make > them easier to find and compare etc. > - Simplified the conformance > > Shortening the document overall > - Shortened the introduction > - Moved much of the discussion out of the guidelines and put > it in the Understanding WCAG 2.0 document > - Shortened the conformance section and moved it after the guidelines > - Moved mapping from WCAG 1 to a separate support document > (so it can be updated more easily) > > Creating a Quick Practitioner-oriented Summary / > Checklist-like document > - Created a Quick Reference document that has just the > Guidelines, success criteria and the techniques for meeting > the success criteria. > > We can't always use active phrasing but we have tried to use > it wherever we could - much more than in last draft (though > success criteria need to be in a true/false format) > > We have summary information at the front, and each guideline > and SC has a link to more explanatory info. > > See if this version isn't easier to use and understand. This does seem a lot better. There is something important thing missing for me - a focus on answering the unspoken questions of the reader quickly at the top of the page. I think there should be a section entitled "Who should read this?". It should be the first subsection in the introduction. It should use short sentences to say something about who reads what for what purpose. I also think much of the difficulty in getting WCAG accepted by content authors is that they come to the document with the wrong expectations, and could do with some additional signposting. The WCAG guidelines are used to (a) set general targets for design, and (b) to evaluate conformance to accessibility needs. Most content authors, however, will typically be asking themselves "How do I find out what do I need to do, right now, to make this accessible?". The more useful document in that case is the *techniques document*. The guidelines are so abstract and high level that content authors will struggle to use them for that purpose. I think the introduction should describe that *very clearly*, and in terms of the questions the *reader will be asking themselves*. For example, the headings "WCAG 2.0 Supporting Documents", and "Organization of the WCAG 2.0 Document" sound to me like descriptive titles, written from the point of view of the author of the document (it answers the question "How can I describe how this all hangs together?"). It doesn't grab me - it sounds like a chore to read that stuff. The intended reader, on the other hand, will be asking themselves "Who is this for (do I need to read it)? What do I need to read, and where do I start? If this is for me, how do I use this stuff?". Structuring the introduction around those questions will, I believe, help a great deal. I also think you should move the section "Components of Web Accessibility" lower down the introduction. It isn't vital to know that stuff at such an early point, and it gets in the way of answering the more burning questions in the mind of the reader. I would also shorten and rearrange the first few paragraphs of the introduction. I think it should be replaced with a short paragraph describing what this document is for. Much of the current content is detail that can be addressed after addressing the reader's burning questions (Do I need to read this? What do I need to read?) under a title such as 'Scope'. (Note also that I feel that the quick reference doc is not much better for content authors wanting to know what to do. I think that they will find it easier to use material organized by task, rather than by abstract groupings.) > > ---------------------------------------------------------- > Comment 2: > > Source: http://www.w3.org/mid/20060627174721.BB9AE4EEC9@homer.w3.org > (Issue ID: LC-1371) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-WCAG20-20060427/ > > Comment 2 > At http://www.w3.org/International/reviews/0606-wcag2/ > Editorial/substantive: S/E > Owner: RI > > Location in reviewed document: > Guideline 3.1 > > Comment: > The term 'primary' is used here in a different way than > currently used in i18n documents. We use 'primary language' > to meanthe intended audience of the document - as specified > in the HTTP header or the meta statement. Our equivalent for > your term 'primary language' wouldbe 'default text-processing > language', based on the associated explanations. This is what > is expressed via the language attribute(s) on the html > element. (Note that we are currently considering options for > replacing the term 'primary language' with something less > ambiguous and moreaccurate.) > > > For a summary of our current usage see > http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.100519373 > [http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.100519373] > > > We believe that what is necessary for accessibility is > identification of the text-processing language - ie. so that > text-to-speech systems know what language they are dealing with. > > > We suggest that you say "The natural language or languages of > the Web unit..." > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have revised our terminology to "default human language". > We have changed the use of this term in both the guidelines > and techniques. I think this is ok. > > ---------------------------------------------------------- > Comment 3: > > Source: http://www.w3.org/mid/20060627170913.258EC4F144@homer.w3.org > (Issue ID: LC-1372) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-WCAG20-20060427/ > > Comment 3 > At http://www.w3.org/International/reviews/0606-wcag2/ > Editorial/substantive: E > Owner: RI > > Location in reviewed document: > Glossary: Natural languages > > Comment: > Nit: "Natural languages" -> "Natural language" ? > > ---------------------------- > Response from Working Group: > ---------------------------- > > The draft has been updated as proposed. Ok. > > ---------------------------------------------------------- > Comment 4: > > Source: http://www.w3.org/mid/20060627173516.043A04F0C9@homer.w3.org > (Issue ID: LC-1375) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/ > > Comment 3 > At http://www.w3.org/International/reviews/0606-understanding-wcag2/ > Editorial/substantive: E > Owner: RI > > Location in reviewed document: > 3.1 Additional techniques > > Comment: > We would be interested in knowing what you will say about use > of dc:lang > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have removed this advisory technique, since there is no > user agent support for using dc:lang for this purpose. Ok. > > ---------------------------------------------------------- > Comment 5: > > Source: http://www.w3.org/mid/20060627173550.D4DC74EED6@homer.w3.org > (Issue ID: LC-1376) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/ > > Comment 4 > At http://www.w3.org/International/reviews/0606-understanding-wcag2/ > Editorial/substantive: S > Owner: RI > > Location in reviewed document: > 3.1.1 Example 1 > > Comment: > "A Web unit produced in Germany includes content in both > German and English, but most of the content is in German. The > primary natural language is identified as German (de)." > > > If the primary language is expressed using HTTP or meta tags, > it is possible that both languages should be identified if > this is a document aimed at a bilingual audience. If the > primary language is to be expressed in the html element tag, > only one language can be chosen. > This example is too vague. This goes back to the question of > what WCAG means by 'primary language'. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have clarified our use of primary language to be the > default human language of the Web page, and we changed SC > 3.1.1 to read "The default human language of each Web page > within the content can be programmatically determined." We > included a reference to Internationalization Best Practices: > Specifying Language in XHTML & HTML Content, and added a > discussion of multilingual documents to the Intent section. > We added "default" to the example to make it clearer why this > satisfies the SC. > > Currently assistive technologies do not support specifying > languages in HTTP headers or meta tags, so those techniques > are not considered sufficient at this time. > > HTTP headers and meta tag marking of languages can identify > multiple languages, as you point out. Specifying multiple > languages in the http header or in meta-data would not > specify a default text processing language, so such usage > would not satisfy this success criterion. This would be > discussed when those techniques are written. I suppose this is ok. I'm not sure how useful the example is, without implementation detail, but that is a different question. I think I would have preferred something like "A Web page written in HTML and produced... The default human language is identified in a lang attribute on the html element. Since the lang attribute can take only one value, and since most of the content is in German, German was specified as the default human language." > > > ---------------------------------------------------------- > Comment 6: > > Source: http://www.w3.org/mid/20060627173627.E53FE4EEC9@homer.w3.org > (Issue ID: LC-1377) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/ > > Comment 5 > At http://www.w3.org/International/reviews/0606-understanding-wcag2/ > Editorial/substantive: E > Owner: RI > > Location in reviewed document: > 3.1.2 Related resources > > Comment: > The links to Liam Quinn's documentation are not very > specific. We are also concerned that the information at the > end of these links no longer constitutes best practise - for > example, if you look under SPAN there are recommendations to > use the tag, rather than , and attribute values are given > without quotes. > > ---------------------------- > Response from Working Group: > ---------------------------- > > Thank you, we have accepted the comment and have removed the > links to Liam Quinn's resourses. Ok. > > ---------------------------------------------------------- > Comment 7: > > Source: http://www.w3.org/mid/20060627173707.64EEE4EEC9@homer.w3.org > (Issue ID: LC-1378) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/ > > Comment 6 > At http://www.w3.org/International/reviews/0606-understanding-wcag2/ > Editorial/substantive: E > Owner: RI > > Location in reviewed document: > 3.1.2 Related resources > > Comment: > There should be a pointer to > http://www.w3.org/TR/i18n-html-tech-lang/ > [http://www.w3.org/TR/i18n-html-tech-lang/] > when that document is published. Note that it is currently a > WD, and that the title has recently changed in the editor's > copy to "Internationalization Best Practices: Specifying > Language in XHTML & HTML Content". > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have added this resource to Success Criterion 3.1.2 Ok > > ---------------------------------------------------------- > Comment 8: > > Source: http://www.w3.org/mid/20060627173744.7B0E14EEC9@homer.w3.org > (Issue ID: LC-1379) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/ > > Comment 7 > At http://www.w3.org/International/reviews/0606-understanding-wcag2/ > Editorial/substantive: E > Owner: RI > > Location in reviewed document: > 3.1.3 Idioms > > Comment: > The markup for the Dutch example says: > > > Hij ging met de kippen op stok > > > We recommend that you remove the -NL unless you really want > to make the point that this is an idiom specific to the > Netherlands. In general, language values should be kept as > short as possible. > > > On the other hand, since the W3C uses American English > spelling, you may want to change the lang attributes in the > html element to "en-US" > - which will help for spell-checking, and possibly also for > voice browsers? > > ---------------------------- > Response from Working Group: > ---------------------------- > > Thanks for catching these. We have made the changes. Ok now. > > ---------------------------------------------------------- > Comment 9: > > Source: http://www.w3.org/mid/20060627173803.BA38B4F3D6@homer.w3.org > (Issue ID: LC-1380) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/ > > Comment 8 > At http://www.w3.org/International/reviews/0606-understanding-wcag2/ > Editorial/substantive: S > Owner: RI > > Location in reviewed document: > 3.1.3 Idioms > > Comment: > The markup for the Japanese and Dutch examples should include > xml:lang attributes as well as the lang attribute, since this > is XHTML served as text/html. > > > Please check this for any other phrases in non-English text. > > ---------------------------- > Response from Working Group: > ---------------------------- > > The draft has been updated as proposed. Ok now. > > ---------------------------------------------------------- > Comment 10: > > Source: http://www.w3.org/mid/20060627173824.EA12C4F0C9@homer.w3.org > (Issue ID: LC-1381) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/ > > Comment 9 > At http://www.w3.org/International/reviews/0606-understanding-wcag2/ > Editorial/substantive: E > Owner: RI > > Location in reviewed document: > 3.1.5 Resources > > Comment: > Since this section says that this guideline can be applied to > non-English text, it seems strange that there are no > references at all to non-English assessment techniques in the > Resources section. > > > Please provide some. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have added references for some non-English assessment > techniques to the Resources for Success Criterion 3.1.5. Great. > > ---------------------------------------------------------- > Comment 11: > > Source: http://www.w3.org/mid/20060627173941.A46EF4EEC9@homer.w3.org > (Issue ID: LC-1382) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-UNDERSTANDING-WCAG20-20060427/ > > Comment 10 > At http://www.w3.org/International/reviews/0606-understanding-wcag2/ > Editorial/substantive: Owner: > Location in reviewed document: > 3.1.3 Idioms > > Comment: > "Example 3: In Japanese, the phrase > "ã•ã˜ã‚'投ã'る（ã(c)ã†ã™ã‚‹ã" ã¨ã‚‚ã§ã > ãªããªã‚Šã€ã‚ãらã‚ã‚‹ã"ã¨" literally translates > into "he threw a spoon". But it means that there was nothing > he could do and finally he gave up. " > > > The Japanese original text is confusing, since it contains > both "he threw a spoon" *and* the explanation. The latter, > that is ã(c)ã†ã™ã‚‹ã" ã¨ã‚‚ã§ã > ãªããªã‚Šã€ã‚ãらã‚ã‚‹ã"㨠, should be deleted. > > > (If the non-English text in this comment is mangled by the > email process, please follow the above link to the original table of > comments.) > > ---------------------------- > Response from Working Group: > ---------------------------- > > Thank you for pointing this out. We've deleted the > explanation in parenthesis and have fixed some grammatical > errors in the example based on other comments. The example > now reads, "Example 3: In Japanese, the phrase "さじを投げる" > literally translates into "he throws a spoon". But it means > that there is nothing he can do and finally he gives up." Ok now. > > ---------------------------------------------------------- > Comment 12: > > Source: http://www.w3.org/mid/20060627174652.F38284EEC9@homer.w3.org > (Issue ID: LC-1383) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/ > > Comment 1 > At http://www.w3.org/International/reviews/0606-wcag2-techniques/ > Editorial/substantive: S > Owner: RI > > Location in reviewed document: > H55, H56 > > Comment: > It is not clear to us why correct support of the 'direction > of the text' is an accessibility issue. We recommend that you > remove all mention of text direction from this document. > > > This would include F5, H1, H34, H56, H55 > > > (If you disagree with this recommendation, we will come back > to you with a substantial number of additional comments based > on the content of this document related to text direction, > and probably recommend that i18n WG needs to be involved in > drafting that text. For now we will hold all such comments > until this one is addressed.) > > ---------------------------- > Response from Working Group: > ---------------------------- > > Thank you for pointing out that the direction of text is not > an accessibility issue. As long as the text itself is > presented in reading order, text direction just affects the > rendering. We are removing general requirements for > indicating the direction of text, but retaining several > techniques for SC 1.3.3, to ensure that the reading order of > the text is not compromised to achieve the desired visual > effect. We would welcome collaboration from i18n on those > portions of the document. > > We made the following modifications to How to Meet SC 3.1.1 > - Removed the second paragraph of the Intent Section > - Removed Situation A and Situation B , keeping the Situation > A sufficient technique as the only sufficient technique for SC 3.1.1. > - Removed the section and technique for identifying text > direction in HTML > - Removed the advisory CSS technique > - Removed Example 2 > - Removed the common failure > > We made the following modifications to How to Meet SC 1.3.3 > - Removed "Adding the dir attribute to a block level element > to change its directionality" from HTML techniques > - Removed advisory CSS technique "Specifying the direction of text" > - Removed "and the direction is identified as right-to-left" > from Example 2 > > We have also incorporated the following edits: > - Deleted technique H1: Adding the dir attribute to a block > level element to change its directionality > - Deleted technique H55: Using the dir attribute of the html element > - deleted F5: Failure of SC 3.1.1 due to using CSS styling to > control directionality in XHTML/HTML > - removed SC 3.1.2 from referenced SC list for techniques H34, H56 Thanks for removing all this stuff. I'll send comments on 1.3.3 separately. +++++++ Comments on 1.3.2 (what they refer to as 1.3.3) and related techniques H34: Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text direction inline http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H34 The example of source code is problematic, since it assumes a particular behaviour on the part of the authoring tool (see the discussion on this at http://www.w3.org/International/geo/html-tech/tech-bidi.html#d2e277 ). I would recommend just describing that the ‏ is placed immediately alongside the exclamation mark, and showing before and after examples of the displayed text, as in http://www.w3.org/International/geo/html-tech/tech-bidi.html#ri20030726.140315918 Note, also, that for people to appreciate the examples, their user agent needs to support bidi text display and Arabic fonts. This is why I am providing a pseudo-arabic version of the example in our best practices doc. Note also that you don't have to use a character entity, although that may be inferred from the current text in H34. In fact, there are more than one possible issue with that: - the editor may not display character entities as you'd expect, due to the bidi algorithm (on the other hand, the editor may make RLM characters visible, like Notepad does, in which case this becomes a better solution) - there is a case for using NCRs rather than character entities in XHTML, since it is XML-based and the entities are declared outside the document, and some parsers may not validate when such entities are involved. If you keep the example you should probably modify the text to say "Inserting a Unicode right-to-left mark (in this case via the HTML character entity) ..." or just indicate that characters, entities and ncrs are possible approaches. H56: Using the dir attribute on an inline element to resolve problems with nested directional runs http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H56 In H34 you say "The concepts used in this technique are described in What you need to know about the bidi algorithm and inline markup." I think you should repeat that and add that document to the resources for H56 too. Also the link in "necessary because the Unicode bidirectional algorithm" should point to the same version of this document as in H34 (rather than the copy on my personal site). The use of the example of source text runs into similar problems to those described for H34. You can see how I attempted to explain this in examples at http://www.w3.org/International/geo/html-tech/tech-bidi.html#ri20030726.140315918 ++++++ Should we keep the technique that describes setting direction on the html tag or block elements ? > > ---------------------------------------------------------- > Comment 13: > > Source: http://www.w3.org/mid/20060627174721.BB9AE4EEC9@homer.w3.org > (Issue ID: LC-1384) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/ > > Comment 2 > At http://www.w3.org/International/reviews/0606-wcag2-techniques/ > Editorial/substantive: S/E > Owner: RI > > Location in reviewed document: > H57 > > Comment: > The term 'primary' is used here in a different way than > currently used in i18n documents. We use 'primary language' > to mean the intended audience of the document - as specified > in the HTTP header or the meta statment. Our equivalent for > your term 'primary language' (based on the advice given in > your techniques) would be 'default text-processing language'. > This is what is expressed via the language attribute(s) on > the html element. (Note that we are currently considering > options for replacing our use of the term 'primary language' > with something less ambiguous andmore accurate.) > > > For a summary of our current usage see > http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.100519373 > [http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.100519373] > > > i18n WG needs to discuss this section with WCAG WG to > understand more clearly what the intent is with regard to 'primary' > vs.'text-processing' language, and to help formulate clearer > guidelines. > > ---------------------------- > Response from Working Group: > ---------------------------- > > We have revised our terminology to "default human language". > We have changed the use of this term in both the guidelines > and techniques. Ok. > > ---------------------------------------------------------- > Comment 14: > > Source: http://www.w3.org/mid/20060627174741.951774EEC9@homer.w3.org > (Issue ID: LC-1385) > > Comment from the i18n review of: > http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/ > > Comment 3 > At http://www.w3.org/International/reviews/0606-wcag2-techniques/ > Editorial/substantive: E > Owner: RI > > Location in reviewed document: > H57 > > Comment: > This technique is titled: > > > Using the lang attribute of the html element > > > But it should make reference to the xml:lang attribute too. > We suggest: > > > Using language attributes on the html element > > ---------------------------- > Response from Working Group: > ---------------------------- > > We agree with this suggestion and have changed the title of > this technique. Ok now. >
Received on Thursday, 31 May 2007 12:40:35 UTC