Proofreaders checklist

How to record and report errors found

If you use Microsoft word - one method is to simply copy the document into Word (or open the document in Word) and turn tracking on. It is easy for copy editor to find the corrections and it is easy to look at the corrections in context. If you like you can also highlight them in yellow but that is not necessary.

If you do not use word you can:

1. describe the correction, or
2. or put [was] [new] at the front of a line with the corrected sentence or just the phrase. You dont need to put the whole sentence, just enough that is can be found with a search for those words. Easiest if you put them on two successive lines so that they line up. it makes it easier to find the differences, especially if it is just a capitalization or comma. For example
   • [was] ...enough however to be sufficient
   • [new]...enough, however, to be sufficient

General Things to check (applies to all sections)

Standard things to look for

• Check spelling
• Delete repeated words
• Check subject-verb agreement.
• Check pronoun references
• Check noun-pronoun agreement
• Plural: URIs is the correct method. URI's is possessive - not plural.
• Proper format fo rnumbers.
  • Numbers from 11 on should be written as numerals.
  • Spell out numbers from one to ten when used in sentences,
    • except
      • when paired with mathematical operators or symbols (e.g., <1),
      • when indicating a unit of time (e.g., .5 times per second), or
      • when referring to numbered steps in the procedures (e.g., step 1).

Hyphenation rules

• Hyphens should be used when a compound adjective modifies a noun
  • For example, programmatically-determined text.
• Do not hyphenate most prefixes such as non, re, sub, etc.
  • Exception: non-text (because it is a compound adjective)

Punctuation checks

• Commas before and after "however" when it occurs within a sentence, or after the word when it's the first word in the sentence
  • (it was late, however, and I didn't want to call. However, it was late and I didn't want to call.)
• Comma after the last item in a comma-separated series (list) within a sentence
  • ("meat, potatoes, and vegetables" instead of "meat, potatoes and vegetables")

"Which" and "That"

• Look for misuse of "which"
  • Use “which” for nonrestrictive clauses that provide additional, but not essential information, in a sentence.
  • Example: “The party, which was originally scheduled for December 6, was canceled.”
  • If the “which” clause is deleted, the meaning of the main clauses (that the party was canceled) remains intact.
• Look for misuse of "that"
  • Use “that” for restrictive clauses that identify the thing they are attached to.
  • Example: “The shoe that she tried on was too large.”
  • “That” is used to identify a specific item in this case and cannot be taken away without changing the meaning of the sentence.

Special things for WCAG Documents

All docs

1. Eliminate contractions (e.g., "don't" should read "do not") (Hint. Search for 't)
2. Look for use of the word "graphic(s)." Replace with "image(s)."Disability-related phrases and etiquette
3. Use "photosensitive seizure disorder" instead of "photosensitive epilepsy"
4. Use "cognitive limitations" instead of "cognitive disability"...others?

Rules for lists

1. Each list item begins with a Capital letter - UNLESS list items are separated with comma or semicolon
2. List items end with a PERIOD only if item is a complete sentence.

In the WCAG 2.0 document itself

• Principles are only place we use "MUST". -
  • Example: Content must be perceivable
• Guidelines use imperative voice and always starts with a verb expressed as a command.
  • Example: Make text content readable and understandable.
• Success criteria are statements of fact that are true or false.
  • Example: Titles and headings are descriptive.

In the Understanding WCAG 2.0 document and techniques docs

• Technique titles
  • Use a verbal that ends in –ing.
  • Do not use the words “must,” “shall,” or “required” anywhere in technique descriptions.
  • Example: Providing additional contextual help for the form field requiring change.
• Sufficiency criterion
• Each Situation should be marked as a heading
• Each sufficient technique or combination of techniques should be numbered
• There should be nothing else numbered anywhere in the Techniques section.
• All technology specific and advisory techniques should be bulletted (unordered list)
• Examples
  • All examples should be in the present tense
  • They should describe something that is - not somethign that should be.
  • All examples should be formatted in one of two formats
    • IF all the examples are short, one sentence examples or just phrases
      • Use an ordered list (Having the examples be numbered faciliatates review and later reference.)
    • IF the examples include multiple sentence examples
      • Put "Example 1:" along with a title as a heading above each example
      • The example would then be a standard paragraph.
      • If you dont have a title for the example - then you can just have "Example 1" for the header

Check for these commonly misspelled words

• anti-alias - hyphenate
• ASCII - all caps
• Bézier - always capitalize, and accent the first e
• braille - capitalize only when talking about Louis Braille
• built-in - hyphenate when used as an adjective or noun, not when built is a verb
• DTDs - no apostrophe
• dingbat - one word
• ECMAScript - one word, cap S
• et al. - no FULL STOP after "et"
• FULL STOP (.) - FULL STOP is the formal name. Dot and period are good aliases.
• heading - Term for h1-h6. Tables and HTTP have headers.
• HTTP/1.0 - needs slash when referred to as a protocol, none in free text
• HTTP/1.1 - needs slash when referred to as a protocol, none in free text
• home page - two words
• Java - cap J
• JavaScript - cap S
• Level 1, 2, 3 - cap L when referring to a W3C technical report
• line feed - two words
• lowercase - one word
• markup - one word
• MIME type - two words, MIME is all caps
• namespace - lowercase unless referring to the Namespaces in XML specification by name
• NUMBER SIGN (#) - usually not crosshatch
• on-line - hyphenate
• PDF - all caps
• PostScript - cap S
• read-only - hyphenate
• ruby - lowercase
• schema - lowercase
• schemas - preferred to schemata
• semicolon - one word
• stand-alone - hyphenate
• style sheet - two words
• subset - no hyphen
• superset - no hyphen
• uppercase - one word
• URI reference - usually not URI Reference or URI-Reference
• URIs - no apostrophe (see [PLURAL])
• user agent - lowercase
• user interface - lowercase
• Web - always capitalize
• Webmaster - one word, capitalized
• Web page - two words, capitalize Web
• Web site - two words, capitalize Web (see [GRM])
• well-formed - hyphenate
• white space - two words
• worldwide - one word
• World Wide Web - three words, no hyphen
• W3C Note - not W3C NOTE