Requirements for add-on submissions

To submit a new add-on, or a new version of an add-on included on the website:

  • Host it (ideally on GitHub, the add-on template makes this easy), and create a pull request against addonFiles. Anyone can submit a pull request, with requests from authors preferred.
  • Edit the get.php file. You need to make sure to have a unique key (add-on ID) in get.php for your add-on.
  • Check that the add-on URL is correct.
  • Ensure that the manifest is correct. Including API versions: only once the first NVDA Beta is released will the API be considered frozen, therefore 'lastTested' should not be set to that version until after the beta.

NV Access plans to make available an add-on store, where reviews of metadata will be automated. In the meantime, the mentioned pull requests will be reviewed, approved and merged manually, so the inclusion of your add-onn may take some time.

To add or update the webpage for your add-on:

  • Request an invitation on the translations mailing list. You need to do this even if the add-on doesn't need translations at this point in time.
  • Follow instructions to download the repo. You may checkout just the website adding "/website" to the URL to manage add-on documentation.
  • Under the addons subfolder, add an addonRepoName.mdwn file. Ensure that it contains a title and tags such as dev, stable or legacy, so that the webpage can be rendered in the corresponding sections of the website. The following examples maybe useful:

    • access8math.mdwn, with tags dev and stable.
    • AudioThemes.mdwn, with tag dev.
    • teamViewer.mdwn, with tag legacy.
  • Pay attention to markdown syntax:

    • Use asterisks followed by space, not dashes, for lists. Dashes are allowed on Github and on the website, but just in English. When the documentation is converted to .po files, using dashes doesn't split the list in the desired items.
    • If URLs aren't too long, use "reference" style for links, that is, include the corresponding urls at the botom of the file, with a blank line between urls, and a blank line at end of file.
    • Try to use short paragraphs, lists, and headings of level 2 or 3, for a good structure and understandable documentation.
    • For nested lists, put a blank line before the first sub-item and after the last one, and use four spaces to indent.
  • If you want to manage translations for your add-on via the NVDA's translation system, request it on the add-ons mailing list.