Skip to content

CI/CD Integration

GitHub Actions and GitLab CI examples for automated WCAG testing. Block non-compliant deployments automatically.

The @holmdigital/engine is designed to fail builds when accessibility violations are detected. Use the --ci flag to ensure the process exits with code 1 on failures.

Workflow Overview

A typical CI/CD pipeline with accessibility scanning follows this flow:

1. Checkout2. Install3. Build4. Start Server5. Scan6. Deploy

How It Works

1. Checkout & Setup

The workflow checks out your code and sets up Node.js. Packages are installed from the public npm registry - no authentication required.

2. Build Application

Your application is built (e.g., npm run build). This produces the static files or starts your server.

3. Start Local Server

A local server is started in the background (&). The workflow waits for the server to be ready using wait-on.

4. Accessibility Scan

The @holmdigital/engine scans the running application. With --ci flag, it fails the build if critical violations are found. The scan checks against WCAG 2.1, EN 301 549, and applicable national laws.

5. Deploy (Optional)

If the scan passes (100/100 compliance), the workflow can proceed to deploy your application to production.

Note: Our packages are published to the public npm registry (npmjs.com), so no special authentication is required. Simply run npm install or npm ci in your CI/CD pipeline.

GitHub Actions

Basic workflow that runs accessibility checks on every push and pull request:

name: Accessibility Check on: [push, pull_request] jobs: a11y-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '20' - name: Install dependencies run: npm ci - name: Build Application run: npm run build - name: Start Server run: npm start & env: PORT: 3000 - name: Wait for Server run: npx wait-on http://localhost:3000 - name: Run Accessibility Scan run: npx @holmdigital/engine http://localhost:3000 --ci --lang en

GitLab CI

Equivalent configuration for GitLab CI/CD:

a11y_check: image: node:20 stage: test script: - npm ci - npm run build - npm start & - npx wait-on http://localhost:3000 - npx @holmdigital/engine http://localhost:3000 --ci --lang en allow_failure: false

Adding Deployment

After the scan passes, you can add any deployment step. Here are templates for common deployment targets:

GitHub Pages

# Add after the scan step - name: Deploy to GitHub Pages uses: peaceiris/actions-gh-pages@v4 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./dist

Vercel

# Add after the scan step - name: Deploy to Vercel uses: amondnet/vercel-action@v25 with: vercel-token: ${{ secrets.VERCEL_TOKEN }} vercel-org-id: ${{ secrets.VERCEL_ORG_ID }} vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }} vercel-args: '--prod'

Netlify

# Add after the scan step - name: Deploy to Netlify uses: nwtgck/actions-netlify@v3 with: publish-dir: './dist' production-deploy: true env: NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }} NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

Custom Server (SSH/rsync)

# Add after the scan step - name: Setup SSH Key uses: shimataro/ssh-key-action@v2 with: key: ${{ secrets.SSH_PRIVATE_KEY }} known_hosts: ${{ secrets.KNOWN_HOSTS }} - name: Deploy via rsync run: rsync -avz --delete ./dist/ user@server:/var/www/html

AWS S3

# Add after the scan step - name: Deploy to S3 uses: jakejarvis/s3-sync-action@master with: args: --delete env: AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }} AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} SOURCE_DIR: 'dist'

Key concept: The accessibility scan runs before deployment. If the scan fails (compliance < 100), the workflow exits with code 1 and deployment never happens. This ensures your production site always meets regulatory requirements.

Tip: You can also generate a JSON report using the --json flag and upload it as a build artifact for deeper analysis. Use --pdf to generate a PDF compliance report.

Success! With this setup, every push is automatically verified for accessibility compliance. Non-compliant builds are blocked from deployment, ensuring your production site always meets regulatory requirements.