Requirements

For WRI certification to carry weight it is important that these requirements are generally supported by the community. Therefore the requirements are defined through discussion on a public mailing list. Everybody is welcome to particpate, whether you are a professor in Web standards, an AWPS developer, a web designer, an AWPS user, or just interested. All that counts is the quality of your argument.

To qualify for bronze certification, a Web Publishing System needs to comply with all must level requirements. Also complying with all should level requirements qualifies for silver certification. Also complying with all bonus point level requirements qualifies for gold certification.

Note that the bonus point level requirements are likely simple to implement in most AWPSs, so the jump from silver to gold comes cheap.

Bronze certificate requirements

• Requirement 1

  must produce both valid and well-formed HTML 4.01 Strict or XHTML 1.0 (including a proper doctype declaration).

• Requirement 2

  content must be accessible purely through HTML; no dependancy on CSS, javascript, Flash, PDF, etc.

• Requirement 6

  must discourage abuse of TABLE for non-tabular data

• Requirement 8

  must encourage use of semantic mark-up such as EM, STRONG, ADDRESS, ABBR/ACRONYM, TITLE and LANG attributes, LINK, CODE, DFN, THEAD, TFOOT, TBODY, FIELDSET, LABEL, etc.

• Requirement 9

  must ensure logical heading level tree (Only use H2 if H1 is used, etc. See also Spartanicus' "Headingology")

• Requirement 10

  must encourage descriptive TITLE element contents

• Requirement 17

  Attempts at circumventing CSS bugs in IE must be done through conditional comments only, and must target only existing versions of IE, not future ones.

• Requirement 18

  must produce flexible designs that can be rendered well in all browsing environments - no attempts at pixel-precise lay-out

• Requirement 21

  must include TYPE attributes with proper MIME type info for hyperlinks not pointing to Web pages (See User-friendlier hyperlinks)

• Requirement 22

  must strongly encourage logical order of content within HTML, allowing CSS to affect the presentation of that order. For example, a navigation menu should come after the main content, even if it is presented next to that content

• Requirement 23

  Frames must not be be used

• Requirement 24

  To avoid ‘jumpy’ rendering (but note Andrew Fedoniouk's remark)
  • HTML must include width and height in pixels for IMG and OBJECT
  • CSS must not define width and height for IMG and OBJECT, unless when defined in %, em or ex (or possibly cm, mm and in, in the case of print Style Sheets)

• Requirement 25

  must encourage proper use of ALT attribute: to provide an alternative, not to abuse it for descriptions.

• Requirement 26

  must not assume a specific built-in Style Sheet. For example, if color is defined, background must also be defined, because there is no guarantee that the user-agent's background colour will be white. The proper way to deal with this is to either use no CSS, or use CSS that starts out with ‘zapping’ user-agents’ buillt-in Style Sheets (See Tantek and Eric Meyer). An example would be:

  	
  	*
  	{
  		margin: 0;
  		padding: 0;
  		font-size: 1em;
  		font-weight: normal;
  		font-variant: normal;
  		font-style: normal;
  		text-indent: 0;
  		text-align: left;
  		color: #000000;
  		background: #FFFFFF;
  		line-height: 1em
  	}
  	:link, :visited {text-decoration: none}
  	:active {cursor: progress}
  	UL, OL {list-style:inside none}
  	A IMG, TABLE, TABLE * {border:none}
  	A:hover {cursor: auto}
  	
  	

• Requirement 27

  must support content-negotiation (serving the user’s preferred language automatically)

• Requirement 28

  EMBED must be used only as fallback for OBJECT

• Requirement 29

  Attempts at creating links such as "click here" must make the AWPS go into immediate self-desctruct mode.

• Requirement 30

  If the AWPS deals with aspects of server configuration, it must do so in the spririt of the WRI requirements. Examples:
  • provide proper MIME types
  • provide proper charset info
  • “be conservative in what you send and liberal in what you accept”, meaning: only allow browser sniffing after a firm warning, and then still only by serving 'special' content to user-agents that are known to be capabale of handling it -- everything else should be served the most widely supported formats possible.

• Requirement 31

  must comply with ATAG 1.0 Checkpoint 1.1: Ensure that the author can produce accessible content.

• Requirement 32

  must comply with ATAG 1.0 Checkpoint 1.2: Ensure that the tool preserves all accessibility information during authoring, transformations, and conversions.

• Requirement 33

  must comply with ATAG 1.0 Checkpoint 2.1: Use the latest versions of W3C Recommendations when they are available and appropriate for a task.

• Requirement 34

  must comply with ATAG 1.0 Checkpoint 2.2: Ensure that the tool automatically generates valid markup.

• Requirement 35

  must comply with ATAG 1.0 Checkpoint 2.3: If markup produced by the tool does not conform to W3C specifications, inform the author.

• Requirement 36

  must comply with ATAG 1.0 Checkpoint 3.1: Prompt the author to provide equivalent alternative information.

• Requirement 37

  must comply with ATAG 1.0 Checkpoint 3.2: Help the author create structured content and separate information from its presentation.

• Requirement 38

  must comply with ATAG 1.0 Checkpoint 3.4: Do not automatically generate equivalent alternatives. Do not reuse previously authored alternatives without author confirmation, except when the function is known with certainty.

• Requirement 39

  must comply with ATAG 1.0 Checkpoint 4.1: Check for and inform the author of accessibility problems.

• Requirement 40

  must comply with ATAG 1.0 Checkpoint 4.2: Assist authors in correcting accessibility problems.

• Requirement 41

  must comply with ATAG 1.0 Checkpoint 5.1: Ensure that functionality related to accessible authoring practices is naturally integrated into the overall look and feel of the tool.

• Requirement 42

  must comply with ATAG 1.0 Checkpoint 5.2: Ensure that accessible authoring practices supporting Web Content Accessibility Guidelines 1.0 Priority 1 checkpoints are among the most obvious and easily initiated by the author.

• Requirement 43

  must comply with ATAG 1.0 Checkpoint 6.2: Ensure that creating accessible content is a naturally integrated part of the documentation, including examples.

Additional requirements for silver certificate

• Requirement 3

  should encourage use of Open Standards-based content where possible. (For instance, offer movies in MPEG format, not QuickTime, WindowsMedia, RealPlayer; offer text in plain text or HTML, not in Microsoft Word (“.doc”) format. Etc.)

• Requirement 5

  should produce purely semantic/logical HTML, no presentational HTML and no DIV soup (Should be a must, but might be imposible/unrealistic to force upon users, so this should indicates that Web Publishing Systems should do their best to steer users towards using semantic markup)

• Requirement 7

  should encourage use of descriptive CLASS and ID names (no class="red")

• Requirement 11

  should generate appropriate LINK elements for navigation to typical locations such as help, next, previous, up, home, search, first, last, index, etc. (See The LINK element - Navigating the WWW.)

• Requirement 12

  should insert LINK element (link rel="alternate") for other languages

• Requirement 13

  should insert LINK element (link rel="alternate" type="application/rss+xml") for offered RSS

• Requirement 15

  if CSS is produced, it should be in accordance with W3C’s CSS 2.1 spec.

• Requirement 16

  if CSS is produced, it should as much as possible be external CSS.

• Requirement 47

  should comply with ATAG 1.0 Checkpoint 4.4: Provide the author with a summary of the document's accessibility status. For instance, by incorporating CTIC' TAW in the authoring tool.

• Requirement 49

  should comply with ATAG 1.0 Checkpoint 6.1: Document all features that promote the production of accessible content.

• Requirement 52

  URLs should not contain information that is not relevant to the user. File name extensions like ".asp", ".php", "cgi", etc. that only have meaning on the server, should not be in URLs. Since users cannot trust file name extensions in URLs to have any reliable meaning, other file name extensions shouldn't be used in URLs either. (See also W3C’s “Common HTTP Implementation Problems”.) Ideally, URLs should be be guessable and easy to type by end users.

Further requirements for gold certificate

• Requirement 19

  bonus points for setting a unique ID on the site (BODY or HTML element), so it can be targeted with User CSS (not required, because this is more the realm of user-agent configurability)

• Requirement 20

  bonus points for providing heading levels (all block level elements?) with an ID, so that people can easily reference or bookmark a section in a Web page. IDs must not be reused; a new ID must be generated whenever a heading (block level element?) is added, or else bookmarks and links would get outdated whenever the page is changed.

• Requirement 50

  bonus points for complying with ATAG 1.0 Checkpoint 3.5: Provide functionality for managing, editing, and reusing alternative equivalents for multimedia objects.

• Requirement 51

  bonus points for complying with ATAG 1.0 Checkpoint 6.3: In a dedicated section, document all features of the tool that promote the production of accessible content.