Coder Social home page Coder Social logo

quail's Introduction

Build Status

Deprecation

All projects have a useful lifespan. Quail was born during a time when accessibility testing, as a discipline, was maturing. There were numerous teams building solutions in parallel -- Quail was just one of these. In the end, we were all orbiting around the same general approach. Technology may have been a distinguishing factor a couple years ago, but even these advantages have largely dissolved as solutions have evolved and improved over time.

Given the realities of the market and the limited time that the Quail team can devote to this project, we are initializing deprecation for this project. Folks are welcome to fork it or volunteer to maintain it, but realistically, there are better options out there.

If you are looking for one, we recommend aXe: the Accessibility Engine by Deque Labs.

Quail: Accessibility Information Library

The project website is quailjs.io.

Quail is a Node module and a jQuery plugin that lets you easily check HTML for adherence to accessibility standards. It comes with over 200 tests which implement Open Accessibility Tests and comes with WCAG 1.0, WCAG 2.0, and Section 508 guidelines.

Developers can build their own guidelines, or easily build a custom guideline that integrates with their project. While the project supports checking entire HTML pages, integration with a CMS to check partial HTML content is probably the most popular use case.

Notice for developers working in the 2.2.x version.

Please base your changes on the master-2.2.x branch.

Requirements

You will need the following installed on your system to run Quail.

  1. Node.js
  2. Grunt & Grunt CLI
  3. Bower
  4. Java JDK (To run Selenium Server)
  5. Karma

Using Quail

Setup

Run the following commands to build Quail.

git clone https://github.com/quailjs/quail.git
cd quail
npm install
bower install
grunt build

Using Quail from the command line

To see the Quail CLI API, run the following. You can also add the Quail bin directory to your PATH if you are so inclined.

./bin/quail --help

Once the command is set up, you can run the following to test any addressable web page.

./bin/quail eval http://placekitten.com

Write the results as a JSON object out to file in an existing directory.

./bin/quail evaluate http://placekitten.com -o ./analyses

You can also pass configurations to the evaluator.

./bin/quail evaluate http://placekitten.com -c ~/path/to/myconfig.json -o ./analyses

This is the default set of configurations. Your configurations will replace the defaults.

{
  "phantomjs": {
    "resourceTimeout": 5000
  },
  "blacklists": {
    "domains": [
      "fbstatic.com",
      "facebook.com",
      "twitter.com",
      "google-analytics.com",
      "googleadservices.com",
      "googlesyndication.com",
      "perfectaudience.com",
      "typekit.com",
      "sharethis.com",
      "doubleclick.com",
      "optimizely.com",
      "gigya.com"
    ],
    "mimetypes": [
      "application/x-shockwave-flash",
      "application/(ms)?(word|powerpoint|excel)"
    ],
    "headers": []
  }
}

The phantomjs configurations affect the PhantomJS runtime.

The blacklists block resource resource requests from PhantomJS by the resource's domain, its mime type or a header name in the request. Currently the only header value that can be blocked is the value of Accept (mime type).

To work on an existing assessment in a browser (so that breakpoints can be set in the console), run the following.

./bin/quail dev aMustHaveTitle

The following is experimental, which means it probably won't work. You can generate a new assessment with this command.

./bin/quail gen someNewAssessment

Testing

Core unit tests in Karma

./node_modules/karma/bin/karma start ./config/karma-unit.conf.js

Testing assessments in Selenium

All assessments. This takes about 10 minutes to run.

node ./test/assessmentSpecs/testRunner.js

An individual assessment. This takes about 2 seconds to run.

node ./test/assessmentSpecs/testRunner.js -I aMustHaveTitle

In a specific browser.

_BROWSER=chrome node ./test/assessmentSpecs/testRunner.js

Documentation

Full documentation is available via readthedocs.org.

Contributing

Pull requests should be made against the master branch.

We are currently looking for the following types of contritions.

  1. Help with our current Milestone objectives.
  2. JavaScript enthusiasts who want a chance to build out:
  3. A dependency injection load pattern: Replace our load-order-depending spinup with an Inversion of Control pattern
  4. A pub/sub pattern: Refactor the custom event bubbling code in the core Classes (e.g. TestCollection) to use a real event pub/sub library
  5. Improve an NPM package, better build and test scripts, etc: Improve the Quail NPM package

Credits

References

HTML Test Suite for WCAG 2.0, Sorted by Guideline

Legal

QUAIL is covered under the MIT License, and is copyright (c) 2015 by Jesse Beach. Current license is at http://quailjs.org/license.

quail's People

Contributors

attiks avatar baldwicc avatar bartfeenstra avatar freepad avatar hannolans avatar honzi avatar jessebeach avatar marcoalting avatar mlewand avatar nschonni avatar theodoreb avatar toddpress avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

quail's Issues

Approach to integrating with Drupal's CKEditor Module

So to try to bring this into the CKEditor module for Drupal the plan would be to add the quail plugin to the CKEditor's plugin directory sites/all/modules/contrib/ckeditor/plugins/

Edit the config file sites/all/modules/contrib/ckeditor/ckeditor.config.js

config.extraPlugins = += (config.extraPlugins ? ',quail' : 'quail' );
CKEDITOR.plugins.addExternal('quail', Drupal.settings.ckeditor.module_path + '/plugins/quail/');  
window.alert(Drupal.settings.ckeditor.module_path + '/plugins/quail/');

That still doesn't load the quail.js but this would be housed in sites/all/libraries/quail/

I think it would also be required to login to Drupal and check it as an enabled plugin admin/config/content/ckeditor/edit/Full

Is there anything I'm missing in the general approach?

Discussion: Moving from "severity" to "testability"

The term "severity" is actually inaccurate in QUAIL, as severity might be different for different standards. What we are really meaning is "testability" i.e. is this a test that is 100% accurate, mostly accurate, or just so impossible to do through automated testing that it just outlines a place where a manual reviewer should look further?

I'm proposing that we change from "severity" to "testability" - which thankfully is an actual word. I can make it also map to "severity" for API purposes, so this could happen safely in a 2.1 version.

Change license to MIT

To facilitate quail being adopted into more projects, while retaining the GPL option for downstream implementations, I would like to investigate moving to an MIT license. There doesn't see to be any issues with moving licenses even for projects that already implement quail. Thoughts?

Move to use require.js

To cut back on size and including tools not needed for most tests, start to break out to require.js modules.

Merge label tests

All the tests about input, radio elements, etc. might need to be merged into a single test that all form elements have an associated label element. This would prevent having to create more tests for every HTML5 element, and sorta-future-proof these tests.

Is that really your cat?

Just checked out the latest code. So neat that you're using AE as an example.

So, how do we apply this now. In AE I could see the errors and saw you just included it:
<script src="../src/quail.js"></script>

But I didn't see anyting with the simple.html version.

Great to see progress!

Change build system, add /dist directory

To facilitate an automated build system, break out the quail /src directory into core, libs, and custom test callbacks. This will also allow wrapping the library for different contexts, like cheerio.

For the time being, final files should be compiled to both the /src and /dist directories since some projects are expecting that, but we can plan to sunset this in a future release.

Update test.json to be valid

Changing resources/guidelines/test.json to the following will make it valid and parsable;

[
"imgAttributeAltExists",
"imgAttributeAltNotFilename",
"imgAttributeAltTooLong",
"imgNonDecorativeHasAlt"
]

Discussion: Removing certain OAC tests, revisiting alignment with WCAG/508

QUAIL started off using only the Open Accessibility Check framework, but quickly outgrew those, as they did not capture common best practices, and were basically written to be implemented in PHP or Java, which meant that certain things like CSS style checking would be difficult.

I'd like to open the discussion in this issue about how we should approach tests in general in QUAIL in the future. I like the model of shipping with a ton of tests, and allowing implementers to actually choose the tests they want to use; however, a saner starting point might be helpful.

Here's my thoughts:

  1. I'll put together a wiki of test-to-standard alignment. I already have most of that data, but it will help to have more community involvement, and to ensure we have proper test coverage. I'll start by focusing on WCAG 2.
  2. We cull QUAIL of tests that do not necessarily align with any best practice or standard. These tests should first just be disabled by the default guidelines, then deprecated, and finally removed by version 2.5.
  3. We find a better way to name tests than the kludgy-QUAIL-name system. This is going to have to be something that is done for a major 3.0 release, I'm thinking namespacing tests to the guidelines or specification, then doing something to link common tests together.

Thoughts? Discussion? I'll link to the wiki soon.

If no guideline is provided, fallback to all provided tests.

Most users when implementing quail will be loading their own tests object, not using the full tests.json file provided with quail. In these cases, it would make senes to just use the keys of the provided tests object to define the guideline.

Tags to tests.json

In order to help CMS integration, tests.json should include tags that can be used to differentiate tests. Here's a few:

  1. content - This test is appropriate for checking content, as opposed to things that are usually in the or related to doctypes.
  2. deprecated - Tests for things that are deprecated HTML elements, i.e. frames, blink.
  3. image - Related to images
  4. header - Related to headers
  5. forms
  6. structure - Things about page structure
  7. aria - Aria-related things like appropriate roles
  8. forms - Labels, inputs, etc.

Change how errors are logged and reported

When a test is flagged, instead of adding it to an array, call a method which will log it in an object for later use, and then also calls any registered callbacks so they can deal with it immediately.

Missing tests

Bring back a handful of tests that were lost in the move to jQuery:

documentIsReadable
documentIsWrittenClearly
imgAltTextNotRedundant
selectJumpMenus
svgContainsTitle
textIsNotSmall
videosEmbeddedOrLinkedNeedCaptions

Tests to be sunset

This is an issue to track tests that should probably be sunset, either because they are excess fluff from OAC, or test for things that are rarely run across these days.

These should probably be moved to a separate file rather than being removed altogether. Part of me wants to just say any test with is not at least a testability greater than .1 should go away. Lots of these are tests that are too general to test for and should be broken up.

  • addressForAuthorMustBeValid
  • appletContainsTextEquivalentInAlt
  • appletContainsTextEquivalent
  • appletProvidesMechanismToReturnToParent
  • appletUIMustBeAccessible
  • appletsDoNotFlicker
  • appletsDoneUseColorAlone
  • basefontIsNotUsed
  • cssDocumentMakesSenseStyleTurnedOff
  • frameRelationshipsMustBeDescribed
  • frameSrcIsAccessible
  • framesetIsNotUsed
  • frameTitlesDescribeFunction
  • frameTitlesNotEmpty
  • frameTitlesNotPlaceholder
  • framesHaveATitle
  • framesetMustHaveNoFramesSection
  • imgHasLongDesc
  • imgImportantNoSpacerAlt
  • imgNotReferredToByColorAlone
  • imgServerSideMapNotUsed
  • All the "tabindex" tests
  • inputElementsDontHaveAlt
  • inputImageAltIdentifiesPurpose
  • inputImageNotDecorative
  • linkUsedForAlternateContent
  • linkUsedToDescribeNavigation
  • objectDoesNotFlicker
  • objectLinkToMultimediaHasTextTranscript
  • objectInterfaceIsAccessible
  • objectMustHaveTitle
  • objectMustHaveEmbed
  • objectMustHaveValidTitle
  • objectProvidesMechanismToReturnToParent
  • objectTextUpdatesWhenObjectChanges
  • objectShouldHaveLongDescription
  • objectUIMustBeAccessible
  • objectWithClassIDHasNoText
  • scriptContentAccessibleWithScriptsTurnedOff
  • scriptInBodyMustHaveNoscript
  • scriptUIMustBeAccessible
  • scriptsDoNotFlicker
  • scriptsDoNotUseColorAlone
  • selectWithOptionsHasOptgroup
  • siteMap
  • tabIndexFollowsLogicalOrder
  • tableLayoutHasNoCaption
  • tableLayoutDataShouldNotHaveTh
  • tableLayoutHasNoSummary
  • tableSummaryIsSufficient

New event: pre-test fail filter

Add a new option that's a callback which allows users to basically say "no, this item is fine." While we can do this through the selector in jQuery, sometimes there are complicated use cases where pre-filtering items would make sense.

Crawling with QUAIL

I understand QUAIL to be primarily used as a real time editing review for user generated content.

However, are there any reasons why you couldn't use it to crawl a site (there must be a Mozilla Plugin for this) and record the errors for everything related to http://example.org

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.