mgifford/accessibility-skills/opquast-digital-quality

Opquast Digital Quality Best Practices

Canonical source: examples/OPQUAST_DIGITAL_QUALITY_BEST_PRACTICES.md in mgifford/ACCESSIBILITY.md

This skill is derived from that file. When in doubt, the example is authoritative.

Apply the Opquast Digital Quality Checklist (Version 5, 2025-2030) when building or reviewing web projects. The framework contains 245 rules across 14 categories covering content, privacy, e-commerce, forms, accessibility, security, performance, and more.

Rules are published under Creative Commons BY-SA 4.0.

Agents may reference and cite rule text; attribute Opquast and respect the

ShareAlike licence — derivatives must use the same licence.

See opquast.com for the authoritative source.

Severity Scale (this skill)

Category-level severity guidance:

• Security failures (HTTPS, headers, passwords): Critical to Serious
• Forms failures (labels, error handling): Critical to Serious
• Navigation failures (keyboard, focus): Critical to Serious
• Images/Media missing alt/captions: Critical
• Privacy policy missing: Serious
• Presentation contrast: Serious; zoom blocked: Serious
• Content, Links, Identification: Moderate to Minor in most cases
• Server/Performance, Newsletter, Internationalisation: Minor in most cases

When to Use This Skill

• Building a new website or web application
• Reviewing or auditing an existing site for quality
• Implementing accessibility, security, or privacy features
• Creating e-commerce flows, forms, or navigation systems
• Generating HTML/CSS code that must meet quality standards

Quick Reference by Category (245 rules across 14 categories)

Workflow

1. Identify Applicable Categories

Not all 14 categories apply to every project:

• All web projects: Content, Forms, Identification, Images/Media, Links,

Navigation, Presentation, Security, Server/Performance, Structure/Code

• Add if applicable: E-Commerce (online sales), Newsletter (email marketing),

Internationalisation (multi-language), Personal Data/Privacy (user accounts/data collection)

2. Consult the Full Rule Text

For the complete rule text, code examples, and rule numbers, consult the canonical Opquast guide or the official checklist directly — this skill summarizes the categories and highest-value patterns rather than reproducing all 245 rules verbatim.

3. Apply During Development

When generating or reviewing code, apply rules as implementation requirements:

• HTML generation: Include metadata, semantic structure, accessible forms,

proper alt text

• CSS generation: Ensure contrast ratios, focus styles, responsive layout,

print styles

• Server configuration: Set security headers, enable compression, configure

caching

• Content review: Check date formats, link text, abbreviation expansion

4. Validate

After implementation, verify against applicable rules. Common automated checks:

• HTML validation and heading hierarchy
• Colour contrast ratios (4.5:1 normal text, 3:1 large text)
• Missing alt attributes
• Missing form labels
• Security headers present
• Broken internal links

Essential Code Patterns

Page Template Minimum

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <meta name="description" content="Page description here." />
  <meta property="og:title" content="Page Title | Site Name" />
  <meta property="og:description" content="Page description for sharing." />
  <title>Page Title | Site Name</title>
  <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
</head>
<body>
  <a href="#main" class="skip-link">Skip to main content</a>
  <nav aria-label="Main navigation"><!-- ... --></nav>
  <main id="main"><!-- ... --></main>
  <footer>
    <a href="/privacy">Privacy Policy</a>
    <a href="/terms">Terms of Use</a>
  </footer>
</body>
</html>

Accessible Form Field

Use native required on native inputs. aria-required is redundant when required is present and should be omitted to avoid accessibility tree noise (rule 98 principle: don't add ARIA states that duplicate native semantics). Use aria-required only on custom widgets (role="combobox" etc.). Also indicate required state in visible text — an asterisk alone is insufficient unless the convention is explained (rule 71).

<label for="email">
  Email address <span aria-hidden="true">*</span> <span class="hint">(required)</span>
  <span class="hint" id="email-hint">Example: user@example.com</span>
</label>
<input id="email" type="email" autocomplete="email"
  required aria-describedby="email-hint" />

Password Field (rules 75–76, 202–205)

<label for="password">Password</label>
<div class="password-wrapper">
  <input id="password" type="password" aria-describedby="password-hint" />
  <button type="button" aria-controls="password" aria-pressed="false">
    Show password
  </button>
</div>

Security Headers (Server Config)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'self';
Referrer-Policy: strict-origin-when-cross-origin

Do not expose server software versions in response headers (rule 213) — remove or obfuscate Server and X-Powered-By. Apply Subresource Integrity to third-party scripts/stylesheets (rule 214):

<script src="https://cdn.example.com/library.min.js"
  integrity="sha384-<hash>" crossorigin="anonymous"></script>

Focus and Contrast Styles

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}
body {
  color: #1a1a1a; /* ~16:1 contrast on white */
  background: #ffffff;
}

Print Styles

@media print {
  nav, header, footer, .sidebar, .no-print { display: none; }
  body { font-size: 12pt; color: #000; }
  a[href]::after { content: " (" attr(href) ")"; }
}

Accessible Data Table (rules 242–243)

<table>
  <caption>Quarterly revenue by region (USD thousands)</caption>
  <thead>
    <tr><th scope="col">Region</th><th scope="col">Q1</th></tr>
  </thead>
  <tbody>
    <tr><th scope="row">North America</th><td>1,200</td></tr>
  </tbody>
</table>

WCAG Relationship

Opquast complements WCAG 2.2 rather than replacing it. Key mappings:

Use Opquast as a holistic quality baseline and layer WCAG testing for full accessibility compliance.

Sustainability Connection

Several Opquast categories directly align with SUSTAINABILITY.md and the Web Sustainability Guidelines:

• Server/Performance (rules 226-230): compression, caching, minification —

directly reduce data transfer and energy per page view

• Presentation (rule 193): not blocking zoom; (rule 194): responsive layout —

reduce need for separate mobile sites

• Structure/Code (rule 239): no meta refresh — avoids unnecessary page reloads

When applying Opquast Server/Performance rules, cross-reference with SUSTAINABILITY.md for additional guidance on carbon-aware delivery and asset optimisation.

Definition of Done Checklist

Apply to every project; skip categories not in scope: