npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

axe-cucumber-protractor

v0.0.6

Published

Protractor plugin for running axe with cucumber support.

Downloads

3

Readme

axe-cucumber-protractor

Implementation based on dequelabs/axe-matchers in Ruby. This allows axe to be used in protractor with cucumber feature files.

Installation

npm install --save axe-cucumber-protractor or yarn add axe-cucumber-protractor

Example usage

In your step file, import:

import 'axe-cucumber-protractor' or require('axe-cucumber-protractor')

Then in a feature file:

Feature: my page
    Scenario: my page that should be accessible
        Given the page should be accessible according to: wcaga

Features

This package has been made with one simple goal in mind, to run axe with protractor through the usage of cucumber feature files on Chrome. But because it is not much extra work to also make other features available, the setup has been made in a way that everything can be added. This status overview shows what you can use it for:

| Feature | Options | default | Status | | |--- |--- |--- |--- |--- | | negate | not | - | Not implemented | | | include | | [] (default) | Not implemented | | | exclude | | [] (default) | Not implemented | | | according to | | ['wcag2a'] | Implemented | | | run only | | - | Not implemented | | | with rules | | [] (default) | Not implemented | | | Skipping rules | | [] (default) | Implemented | | | Options | | - | Not implemented | |

API

Built-In Accessibility Cucumber Steps

To construct an axe accessibility Cucumber step, begin with the base step, and append any clauses necessary. All of the following clauses may be mixed and matched; however, they must appear in the specified order:

Then the page should be accessible [including] [excluding] [according-to] [checking-rules/checking-only-rules] [skipping-rules]

Base Step

Then the page should be accessible

The base step is the core component of the step. It is a complete step on its own and will verify the currently loaded page is accessible using the default configuration of axe.run (the entire document is checked using the default rules).

Inclusion clause

Then the page should be accessible within "#selector"

The inclusion clause (within "#selector") specifies which elements of the page should be checked. A valid CSS selector must be provided, and is surrounded in double quotes. Compound selectors may be used to select multiple elements. e.g. within "#header, .footer"

see additional context parameter documentation

Exclusion clause

Then the page should be accessible excluding "#selector"

The exclusion clause (excluding "#selector") specifies which elements of the document should be ignored. A valid CSS selector must be provided, and is surrounded in double quotes. Compound selectors may be used to select multiple elements. e.g. excluding "#widget, .ad"

see additional context parameter documentation

If desired, a semicolon (;) or the word but may be used to separate the exclusion clause from the inclusion clause (if present).

Then the page should be accessible within "main"; excluding "aside"
Then the page should be accessible within "main" but excluding "aside"

Accessibility Standard (Tag) clause

Then the page should be accessible according to: tag-name

The tag clause specifies which accessibility standard (or standards) should be used to check the page. The accessibility standards are specified by name (tag). Multiple standards can be specified when comma-separated. e.g. according to: wcag2a, section508

The acceptable tag names are documented as well as a complete listing of rules that correspond to each tag.

If desired, a semicolon (;) may be used to separate the tag clause from the preceding clause.

Then the page should be accessible within "#header"; according to: best-practice

Checking Rules clause

Then the page should be accessible checking: ruleId

The checking-rules clause specifies which additional rules to run (in addition to the specified tags, if any, or the default ruleset). The rules are specified by comma-separated rule IDs.

see rules documentation for a list of valid rule IDs

If desired, a semicolon (;) or the word and may be used to separate the checking-rules clause from the preceding clause.

Then the page should be accessible according to: wcag2a; checking: color-contrast
Then the page should be accessible according to: wcag2a and checking: color-contrast

Exclusive Rules clause

Then the page should be accessible checking only: ruleId

This clause is not really a separate clause. But rather, by adding the word only to the checking-rules clause, the meaning of the step can be changed. As described above, by default the checking-rules clause specifies additional rules to run. If the word only is used, then only the specified rules are checked.

Skipping Rules clause

Then the page should be accessible skipping: ruleId

The skipping-rules clause specifies which rules to skip. This allows an accessibility standard to be provided (via the tag clause) while ignoring a particular rule. The rules are specified by comma-separated rule IDs.

see rules documentation for a list of valid rule IDs

If desired, a semicolon (;) or the word but may be used to separate the skipping-rules clause from the preceding clause.

Then the page should be accessible according to: wcag2a; skipping: accesskeys
Then the page should be accessible according to: wcag2a but skipping: accesskeys

Examples

Then the page should be accessible within "main, header" but excluding "footer"

Then the page should be accessible excluding "#sidebar" according to: wcag2a, wcag2aa but skipping: color-contrast

Then the page should be accessible checking only: document-title, label

Then the page should be accessible according to: best-practice and checking: aria-roles, definition-list