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 -------