Changelog is out of date.

To repeat:

1. Try $ wcag localhost:8000 --id=<achecker id>
2. Try $ wcag localhost:8000/a/sub/path --id=<achecker id>
3. Notice the errors will be identical because in both cases only the homepage is being checked.

CLI requires an AChecker API id:

$ wcag domainname.com
Please provide an AChecker API ID with `--id` or setting an `ACHECKER_ID` environment variable. Register at http://achecker.ca/register.php to get an ID.

http://achecker.ca/register.php returns 404, it looks like the original service is no longer there.

What is the status of this project? Any hope of getting it back to a useful state?

Now only 0.12 is tested. I think it would be a good idea to add 0.10 and iojs as well

node_js:
  - "0.10"
  - "0.12"
  - "iojs"

Some sites report hundreds of potential problems which can be overwhelming to scroll through. The problems often have the same message but occur on different lines.

Maybe we should cap the list by default. Something like:

  ⚠  499 potential problems found.

  ⚠  183:70 Anchor text may not identify the link destination.
  ⚠  183:174 Anchor text may not identify the link destination.
  ⚠  183:243 Anchor text may not identify the link destination.
  ⚠  183:295 Anchor text may not identify the link destination.
  ⚠  183:351 Anchor text may not identify the link destination.
  ⚠  183:409 Anchor text may not identify the link destination.
  ⚠  183:467 Anchor text may not identify the link destination.
  ⚠  183:522 Anchor text may not identify the link destination.
  ⚠  183:579 Anchor text may not identify the link destination.
  ⚠  183:638 Anchor text may not identify the link destination.
  ⚠  183:694 Anchor text may not identify the link destination.
  ⚠  183:749 Anchor text may not identify the link destination.

  487 additional problems not shown. Run with `--verbose` to show full list.

Or maybe we should just group similar errors?

  ⚠ 183:70, 183:174, 183:243, 183:295, 183:351, 183:409, 183:467, 183:522, 183:579, 183:638, 183:694, 183:749 Anchor text may not identify the link destination.

Or:

  ⚠ Anchor text may not identify the link destination. Occurs at 183:70, 183:174, 183:243, 183:295, 183:351, 183:409, 183:467, 183:522, 183:579, 183:638, 183:694, 183:749.

Example of the problem:

Sometimes after repeatedly running the tests I get:

Error: Unexpected close tag
Line: 4
Column: 7
Char: >

xml2js is a parser written in pure JavaScript so the node-gyp buildstep we get by using xml2json will no longer be necessary.

Haven't looked into if we can just switch or if it requires a lot of extra work.

i.e. Let the user do wcag whatever.com anotherwebsite.com foo.com.

I'm not even sure what the output would look like.

$ wcag -h

or

$ wcag --help

to print out usage/help-text.

If there are no objections I can implement this on my next iteration

Turns out the global installation isn't the problem: https://travis-ci.org/contolini/node-wcag/builds/80614351

$ npm install
npm ERR! Linux 3.13.0-40-generic
npm ERR! argv "/home/travis/.nvm/versions/node/v0.12.7/bin/node" "/home/travis/.nvm/versions/node/v0.12.7/bin/npm" "install"
npm ERR! node v0.12.7
npm ERR! npm  v2.11.3
npm ERR! code E404
npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/repo-templates
npm ERR! 404 
npm ERR! 404 'repo-templates' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 It was specified as a dependency of 'verb'
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.
npm ERR! Please include the following file with any support request:
npm ERR!     /home/travis/build/contolini/node-wcag/npm-debug.log
The command "npm install" failed and exited with 1 during .
Your build has been stopped.

wat.

Hi, I'm the developer of a similar solution https://github.com/zrrrzzt/wcag-validator.
I would rather continue developing your version than my own, but I'll need it to work as a module in addition to a CLI version.
If you're interested I can do the necessary code changes myself and do a PR.

According to https://achecker.ca/checker/suggestion.php?id=7, "img element cannot have alt attribute value of null or whitespace if the img element is contained by an A element and there is no other link text."

See cfpb/consumerfinance.gov#3647. The images don't have alt text but do have accompanying link text, yet wcag still fails those images.

Sometimes you don't want the entire report. You just want to know if it PASSES (no errors founds) or FAILS. See #8 (comment).

I want a quick way to display which version I'm using.

$ wcag -v

or

$ wcag --version

output

$ 0.1.4

If there's no good reason not to implement this I can take care of it.

Using a localhost address in https://github.com/cfpb/node-wcag#module-usage always passes and returns an empty array for errors and potentialProblems.

According to docs at npm "licenses" is no longer valid metadata.

Use the valid-url module

var validUrl = require('valid-url')

if (opts.uri && !validUrl.isWebUri(opts.uri)) {
    return callback(new Error('You supplied an invalid URL.'), null);
}

Add some documentation to the README about the API that powers the CLI. See #2 (comment).

I really love request, but I think it's not needed in this case. All we do is a plain GET.
As usual I can implement this if anyone else likes the idea.

In packages.json engines states >=0.8. I propose we bump that to 0.10.

When installing globally this warning is displayed repeatedly:

../deps/libexpat/lib/xmltok.c:471:1: warning: missing field 'isName2' initializer [-Wmissing-field-initializers]
};
^

If a request doesn't return 200, tell the user they supplied a bad URL.

http.get('http://thisisnotalegitimatewebsite.foo').on('error', function() {
  console.log("You supplied an invalid URL.");
});

I've always had one module containing both CLI and module. However, after reading this I think it would be better to keep them apart.

$ npm install wcag

Would install the module

$ npm install wcag-cli -g

would install the CLI (much as it is today)

It would still be possible to enable use of wcag as CLI handle

$ wcag <url> --key=<key>

I haven't had the time to look into this, but here's what I've got so far.

$ wcag https://www.mrfylke.no/ --id=69f6ea6a9e30b37c3d341d3b716df218f8942c0e

Returns

Error: Unable to connect to undefined

The same error message is returned from the module.

'use strict';

var wcag = require('wcag');
var options = {
  id: '69f6ea6a9e30b37c3d341d3b716df218f8942c0e',
  uri: 'https://www.mrfylke.no',
  guide: 'WCAG2-AA'
};

wcag(options, function (error, data) {
  if (error) {
    console.error(error);
  } else {
    console.log(data);
  }
});

//=> [Error: Unable to connect to undefined]

So far I've only seen this error with this url. If you check the url via the achecker websites everything is ok. The error message itself seems to be returned from lib/checkURI.js so that's probably a good place to start.