- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Thu, 19 Nov 2009 19:01:20 +0000
- To: aurélien levy <aurelien.levy@free.fr>, public-html-a11y@w3.org
- Cc: "public-html-a11y@w3.org" <public-html-a11y@w3.org>
aloha, aurélien! i understand your concerns from a huiman-language perspective, but the definition of SHOULD and SHOULD NOT for purposes of normative documents is contained in RFC 2119, "Key words for use in RFCs to indicate requirement levels, RFC 2119, S. Bradner, March 1997.", which is cited in HTML5's references -- the pertinent extract are quoted below <quote src="http://www.rfc-editor.org/rfc/rfc2119.txt"> 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. </quote> so, if you encounter one of the above-listed words in a proposal and it appears in all capital letters, it is usually the author's intent to reference RFC 2119 implicitly by capitalizing the word/prase. personally, i strongly believe that exposition of "summary" SHOULD be a decision of the end-user -- the default SHOULD be do not render, and there should be multiple means or the user to have the summary communicated to her -- for example, for some populations, a tooltip exposition is preferable, for others, exposition in a sidebar or context menu, which contains an outline view of the document's structure, along with all labelling and descriptive meta a good model for such an exposition strategy is the University of Illinois - Champange-Urbana's Functional Accessibility Evaluator (FAE), an add-on/plug-in available for FireFox:, which is a boon not only to those seeking to ensure that their content is accessible, but which also provides many of us using assistive technologies to unparalleled access to a document's structure and user-interface -- i use its "forms view" to fill out forms when using firefox http://html.cita.illinois.edu/tools/#firefox good to hear you on the list, aurélien , hope this helps, gregory. ----------------------------------------------------------------- Accessibility, Internationalization, and Interoperability are not "features", "overlays" or "add-ons". Rather, they are core components of any architecture -- programmatic or otherwise. ----------------------------------------------------------------- Gregory J. Rosmaita, gregory@linux-foundation.org Vice-Chair, WebMaster & Listmaster, Open Accessibility Workgroup http://a11y.org/ http://a11y/specs ----------------------------------------------------------------- ---------- Original Message ----------- From: aurélien levy <aurelien.levy@free.fr> To: %%WORD169%y@w3.org Cc: "%%WORD169%y@w3.org" <%%WORD169%y@w3.org> Sent: Thu, 19 Nov 2009 19:02:21 0100 Subject: Re: FW: CHANGE PROPOSAL: Table Summary > > Changes from the last draft include > > > > ... > > > > 3) Changed visual user agents MUST NOT render summary to SHOULD > > NOT render summary, based on feedback from Kelly Ford and Laura Carlson > > > I'm a bit concerned about this one. I perfectly agree that > "should not" is more politically correct but at the same time it > open a door for web browser manufacturer to choose between > render it or not. This open door can lead to some differences > between browser who may be confusing for users and even for > creators regarding the "WSYIWYG authoring tools *SHOULD* render > it visually" sentence. ------- End of Original Message -------
Received on Thursday, 19 November 2009 19:01:58 UTC