Pre-publication checklist

From Cognitive Accessibility Task Force

This is a short summary of the most important points for editing. If these are done then Michael should be OK with the rest. (The full requirements are at and )

A sample is available at

NOTE: When proofing an issue paper please make sure all changes that might change the meaning are: 
1. In an email to the group 
2. in the commit notes on github
This is really important. A lot of research went into each paper and when people proof  read them they should not make any substantive changes without the people who did the research getting a change to discuss it.
we will remove editors rights for people who fail to do this

1. Add an few lines of introduction such as:

This document an issue paper looking into the challenges and issues faced by users with learning disabilities and cognitive disabilities when using voice menu systems and voice ML.

This is part of a series of issue papers written by The Cognitive and Learning Disabilities Accessibility Task Force (COGA). COGA is a joint Task Force of the <a href="">Accessible Platform Architectures (APA) Working Group</a> and the <a href="">Web Content Accessibility Guidelines Working Group (WCAG WG)</a>.

This work will be used as a base document for other work including a road-map for improving accessibility for people with learning disabilities and cognitive disabilities.

2. Edit the document for spelling and grammar. Check that all the sentences are complete sentences.

No empty sections or sections that just have a heading. If there is a heading with no content underneath add a not that this needs to be filled in or remove the section.

3. Check the structure. We need nested structure as follows:


Every section needs a heading, the script will take care of the actual level number, just make sure the heading level is consistent

4.We need well formed code. If some tag is opened, we need to be certain it's also closed at some point.

5. Use div elements with the class "example" to mark up code examples. You can use a span if the example snipit is mid-sentence. (if your are not sure how to do this we can fix it afterward.)

6. No naked links. Links should be of the form <a href=""> WCAG Extension Requirements</a> [[wcag2-ext-reqs]] (ignore the color it is a wiki thing - and see bellow for the reference part).

Note that the brackets are only needed if the document is a reference document.

Also links should be only to stable URLs.

7. References to W3C publications should use the format [[short-name]] (ignore the color it is a wiki thing)

Look at "latest published version" in the document for the short name ( it's after the tr/ and up to the next slash /)

For example [[WCAG20]] references WCAG 2.0

where WCAG20 is the specification at

For sections within a document use

<a href=""> WCAG Extension Requirements</a> ([[wcag2-ext-reqs]] , section 13.3.2)

8. References to other publications

We've created our own database of listings with short names. See

If you can find your paper in our database please use the short name provided.

If you can not find it (ad have looked) please send the information about the reference to Ayelet and lisa and we will give you a short name and add it to the database (or you can add it yourself if you can figure it out...)

For example, ADI-1 is the short name of the following entry in the JSON in the biblio.js file:



"title": "World Alzheimer Report 2010",

"publishDate": "2010",

"authors": ["Alzheimer's disease International"],

"etAl": false


(Note ayelet can give you a short name if you do not want to write this.)

Then in your document you can add the following references:

see World Alzheimer Report 2010 [[ADI-1]]


see World Alzheimer Report 2010 ([[ADI-1]] , section 12)