W3C home > Mailing lists > Public > public-html-a11y@w3.org > November 2009

Re: FW: CHANGE PROPOSAL: Table Summary

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>
Message-Id: <20091119185744.M49635@hicom.net>
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.

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 
along with all labelling and descriptive meta  

a good model for such an exposition strategy is  the University of 
- 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 


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:26 UTC