npm - @jrpool/kilotest - Versions diffs - 24.0.4 → 24.0.6 - Mend

@jrpool/kilotest 24.0.4 → 24.0.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (3) hide show

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@jrpool/kilotest",
-  "version": "24.0.4",
+  "version": "24.0.6",
   "description": "An ensemble testing service with a focus on accessibility",
   "main": "index.js",
   "scripts": {

package/style.css CHANGED Viewed

@@ -47,6 +47,15 @@ code {
 code.thin {
   font-weight: 400;
 }
+.contents-table {
+  margin-bottom: 2rem;
+  padding: 1rem;
+  border: solid 0.2rem #006666;
+  border-radius: 0.5rem;
+}
+.contents-table h2 {
+  margin-top: 0;
+}
 details {
   padding: rem;
   border: solid #000 1px;
@@ -118,8 +127,10 @@ pre {
 .secondCellRight td:nth-child(2) {
   text-align: right;
 }
-section:not(.wide) {
-  max-width: 36rem;
+section.main {
+  border-top: solid 0.3rem #006666;
+  padding-top: 1rem;
+  margin-top: 2rem;
 }
 summary {
   box-sizing: border-box;
@@ -153,6 +164,9 @@ tbody th {
 td, th {
   padding: 0 0.5rem;
 }
+textarea {
+  width: 100%;
+}
 thead th {
   padding-bottom: 1rem;
 }
@@ -169,10 +183,10 @@ ul.pseudoTopLevel {
 ul.nav {
   padding-inline-start: 0.25rem;
 }
-ul.nav > li, ul.headed > li {
+ul.nav li, ul.headed li {
   list-style: none;
 }
-ul.nav > li > a {
+ul.nav li > a {
   display: block;
   box-sizing: border-box;
   min-height: 44px;

package/tutorial/index.html CHANGED Viewed

@@ -6,37 +6,10 @@
     <meta name="publisher" content="Jonathan Robert Pool">
     <meta name="creator" content="Jonathan Robert Pool">
     <meta name="keywords" content="accessibility,a11y,testing,tutorial,WCAG,autocomplete">
-    <title>Accessibility Testing Strategies | Kilotest</title>
+    <title>Tutorial: Accessibility Testing Strategies | Kilotest</title>
     <link rel="icon" href="/favicon.ico">
     <link rel="stylesheet" href="/style.css">
     <style>
-      .skip-link {
-        position: absolute;
-        top: -3rem;
-        left: 0;
-        padding: 0.5rem 1rem;
-        background: #fff;
-        border: solid 2px #000;
-        z-index: 100;
-        transition: top 0.1s;
-      }
-      .skip-link:focus {
-        top: 0;
-      }
-      .tutorial-nav {
-        margin-bottom: 2rem;
-        padding: 1rem;
-        border: solid 1px #006666;
-        border-radius: 0.5rem;
-      }
-      .tutorial-nav h2 {
-        margin-top: 0;
-      }
-      section.tutorial-section {
-        border-top: solid 2px #006666;
-        padding-top: 1rem;
-        margin-top: 2rem;
-      }
       .note {
         padding: 0.75rem 1rem;
         border-left: solid 4px #006666;
@@ -141,7 +114,6 @@
       }
       .comment-section textarea {
         width: 100%;
-        max-width: 40rem;
         padding: 0.5rem;
         font-size: 1rem;
         font-family: inherit;
@@ -213,14 +185,10 @@
     </style>
   </head>
   <body>
-    <a class="skip-link" href="#main-content">Skip to main content</a>
-    <main id="main-content">
-      <h1><a href="/">Kilotest</a>: Accessibility Testing Strategies</h1>
-      <p class="time-estimate">Estimated reading time: about 60 minutes.</p>
-      <nav class="tutorial-nav" aria-label="Tutorial sections">
-        <h2>Sections</h2>
+    <main>
+      <h1><a href="/">Kilotest</a> tutorial: Accessibility Testing Strategies</h1>
+      <nav class="contents-table">
+        <h2>Table of contents</h2>
         <ul class="nav">
           <li><a href="#about">About this tutorial</a></li>
           <li><a href="#orientation">Part 1: Orientation</a>
@@ -241,71 +209,52 @@
             </ul>
           </li>
           <li><a href="#conclusion">Conclusion</a></li>
+          <li><a href="#further-reading">Further reading</a></li>
+          <li><a href="#suggest-improvement">Suggest improvements</a></li>
         </ul>
       </nav>
-      <!-- ═══════════════════════════════════════════════════════ -->
-      <section id="about" class="tutorial-section">
+      <h2>Notice</h2>
+      <p>This is a rough draft created in partnership with an artificial intelligence agent using Claude Sonnet 4.6 Thinking. Revisions are in progress.</p>
+      <section id="about" class="main">
         <h2>About this tutorial</h2>
-        <p><strong>Notice</strong>: This is a rough draft created in partnership with Claude Sonnet 4.6 Thinking. Revisions are in progress.</p>
-        <p>This tutorial is for web developers with limited experience in web accessibility testing. It takes about 60 minutes to complete.</p>
-        <p>You will learn about three strategies for testing web accessibility:</p>
+        <p>If you are familiar with web technology (HTML, CSS, JavaScript), but you have limited knowledge of digital accessibility testing, this tutorial is designed for you.</p>
+        <p>Estimated completion time: 1 hour.</p>
+        <p>The tutorial has two parts:</p>
         <ul>
-          <li><strong>Human testing</strong> — a person directly examines and uses the page</li>
-          <li><strong>Rule-engine testing</strong> — software applies codified rules to the page</li>
-          <li><strong>AI-agent testing</strong> — an AI agent analyzes the page</li>
+          <li><strong>Orientation</strong>. What digital accessibility is, why it is valuable, and how websites can be tested for it.</li>
+          <li><strong>Practicum</strong>. Examining a specific example.</li>
         </ul>
-        <p>A practicum applies all three strategies to a real example, revealing what each strategy finds, what each misses, and why.</p>
-        <p>Links to additional information are included throughout. Completing the tutorial does not require following any of those links.</p>
-        <div class="note">
-          <p><strong>Offline use:</strong> This tutorial is self-contained. You may complete it without an Internet connection, though external links will not be reachable.</p>
-        </div>
-        <div class="note">
-          <p><strong>Note on AI results:</strong> The AI testing results in Part 2 were captured in May 2026 from a specific model. As AI models and the resources available to them improve, results may change — potentially for better or worse. The captured results are preserved here as a fixed point of comparison.</p>
-        </div>
+        <p>If the tutorial makes you want to learn more, there are links to additional information at the end.</p>
+        <p>Improvements in this tutorial are certainly possible. You can help by submitting your suggestions at the end.</p>
       </section>
-      <!-- ═══════════════════════════════════════════════════════ -->
-      <section id="orientation" class="tutorial-section">
+      <section id="orientation" class="main">
         <h2>Part 1: Orientation</h2>
-        <p class="time-estimate">About 30 minutes.</p>
         <section id="why-matters">
-          <h3>Why accessibility testing matters</h3>
-          <p class="time-estimate">About 5 minutes.</p>
-          <p>Accessibility is not a separate concern added to a finished product. It is an aspect of code quality, legal compliance, and basic usability — present or absent in every page you ship.</p>
-          <h4>Code quality</h4>
-          <p>Inaccessible code is often incorrect code. HTML specifications define semantic elements and attributes for good reasons, and violations frequently indicate structural errors that affect all users, not only users with disabilities. A missing <code>autocomplete</code> attribute, for example, is not a cosmetic gap — it tells the browser that the developer has not declared the purpose of a form field that users rely on.</p>
-          <p>Accessible code also tends to be more maintainable: clear structure, meaningful labels, and correct role assignments make code easier to understand and modify.</p>
-          <h4>Legal compliance</h4>
-          <p>In many jurisdictions, web accessibility is a legal requirement. The most widely referenced technical standard is the <a href="https://www.w3.org/TR/WCAG22/">Web Content Accessibility Guidelines (WCAG)</a>, published by the W3C. WCAG 2.1 and 2.2 are referenced by law in the United States (Section 508, ADA), the European Union (European Accessibility Act), the United Kingdom (Equality Act), and many other countries.</p>
-          <p>Non-compliance exposes organisations to legal action, regulatory penalties, and reputational harm. Lawsuits and settlements involving web accessibility are documented each year in all of these jurisdictions.</p>
-          <h4>Usability</h4>
-          <p>Approximately 15–20% of people worldwide have a disability that can affect their use of the web. These include permanent conditions (blindness, deafness, motor impairments, cognitive disabilities) as well as temporary situations (a broken arm, recovering from eye surgery) and situational constraints (a noisy environment, a phone in bright sunlight, holding an infant).</p>
-          <p>Inaccessible code excludes or burdens these users. Features that are technically accessible also tend to benefit users without disabilities: clear labels reduce errors for everyone, logical keyboard flow speeds navigation, and high contrast aids readability in suboptimal lighting.</p>
-        </section>
-        <!-- ─── ─── ─── ─── -->
-        <section id="three-strategies">
-          <h3>The three testing strategies</h3>
-          <p class="time-estimate">About 8 minutes.</p>
-          <h4>Human testing</h4>
-          <p>A person directly examines the page, using the browser and auxiliary tools to find accessibility issues. This is sometimes called <q>manual testing</q>, though the term can be misleading — modern human testing uses several tools; it is the human judgment that distinguishes this strategy.</p>
-          <p>Human testing typically involves three techniques:</p>
+          <h3>Accessibility in a nutshell</h3>
+          <p><q>Accessibility</q> has several meanings. Here it refers to universal usability: usability for the widest practical range of people. It began with a focus on people with specific physical, sensory, and cognitive disabilities (an estimated 20% of the world population), but now it often refers to design and construction <em>standards</em> that elevate usability for everybody.</p>
+          <p>Accessibility standards exist for buildings, vehicles, devices, and software. Standards are defined by professional associations, governments, and individual experts. The latter are often called <q>best practices</q>.</p>
+          <p>Kilotest deals with <strong>web</strong> accessibility, so that is the focus of this tutorial.</p>
+          <p>Not everybody agrees with every standard, but some standards are widely accepted and have even been made legally mandatory. The web accessibility standards gaining the greatest legitimacy are those defined by the the World Wide Web Consortium (W3C). They include:</p>
           <ul>
-            <li><strong>DOM inspection.</strong> The tester uses browser developer tools to examine the HTML structure, attributes, and the accessibility tree. The accessibility tree is the browser's representation of the page as assistive technologies see it — role, name, state, and value for each element.</li>
-            <li><strong>Keyboard navigation.</strong> The tester uses only the keyboard (Tab, Shift+Tab, Enter, Space, arrow keys) to navigate and operate the page. This reveals whether all interactive elements are reachable and operable without a mouse.</li>
-            <li><strong>Screen reader testing.</strong> The tester activates a screen reader — software that vocalises page content — and navigates the page by ear. Common screen readers include NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android.</li>
+            <li>Web Content Accessibility Guidelines (WCAG): for websites</li>
+            <li>Authoring Tool Accessibility Guidelines (ATAG): for web authoring tools</li>
+            <li>Accessible Rich Internet Applications (ARIA): for scripted web applications</li>
           </ul>
-          <p>Effective human testing requires substantial knowledge: WCAG success criteria, ARIA authoring practices, HTML semantics, and proficiency with at least one screen reader. It also takes time — a thorough examination of a single page may take 30 minutes to several hours.</p>
-          <h4>Rule-engine testing</h4>
-          <p>Software applies a set of codified rules to a page and reports which rules are violated. This is sometimes called <q>automated testing</q>, though that label is also imprecise — what is automated is the rule application, not the judgment about what rules should exist.</p>
+          <h3>The stakes</h3>
+          <p>It is obvious that making a website that is insecure or leaks private or confidential data is risky. Similarly, making a website that is inaccessible is risky. It exposes the site owner to prosecution, civil litigation, and negative publicity. It also makes websites harder to use, deterring what you want users to do, such as understanding your mission or making purchases.</p>
+          <p>Many users interact with the web using <em>assistive technologies</em> (ATs): hardware and software tools that mediate between websites and users. Some are designed to serve users with disabilities, such as <em>screen readers</em> that explain structure and content orally, voice input software, eye trackers, breath-based navigators. ATs typically presume that a site conforms to accessibility standards.</p>
+          <p>Increasingly, almost all web use is being mediated by artificial-intelligence agents. They all make mistakes, but the error rate is likely to jump when a website violates accessibility standards.</p>
+          <p>The accessibility standards go beyond HTML, CSS, and JavaScript standards, so accessibility gets conformity to those standards as a side effect. This makes your code more maintainable and debugging easier as team members change.</p>
+        </section>
+        <section id="three-strategies">
+          <h3>Testing</h3>
+          <p>Accessibility <em>testing</em> is the process of verifying conformity to accessibility standards. There are three main strategies of web accessibility testing.</p>
+          <h4>Strategy 1. Human testing</h4>
+          <p>A person directly examines a website, using browsers, developer tools, I/O devices, and assistive technologies to find accessibility problems. This is sometimes called <q>manual testing</q>, but it really is <em>human</em> testing: testing by a person who investigates the site by inspecting and using it.</p>
+          <p>One subtype of human testing is testing by experts in the use of assistive technologies and atypical I/O methods. These are usually people who have gained their expertise through long-term use arising from disabilities.</p>
+          <p>Human testing gives you insight into accessibility problems that the other strategies are likely to miss. But it is also the slowest and most expensive strategy. So an efficient approach is usually to start with the other strategies, solve any problems they discover, and then do human testing on the improved site.</p>
+          <h4>Strategy 2. Rule-engine testing</h4>
+          <p>Software applies a set of codified rules to a page and reports on any violations of the rules. This is sometimes called <q>automated testing</q>, but it is humans who have defined the rules and designed the tests (sometimes with AI assistance).</p>
           <p>Rule engines come in several forms:</p>
           <ul>
             <li><strong>Browser extensions</strong> such as the <a href="https://www.deque.com/axe/devtools/">axe DevTools extension</a> and the <a href="https://wave.webaim.org/extension/">WAVE Evaluation Tool</a> run directly in the browser and report violations interactively.</li>
@@ -436,14 +385,9 @@
           <p>Both violations prevent browsers and assistive technologies from identifying the purpose of the affected fields.</p>
         </section>
       </section>
-      <!-- ═══════════════════════════════════════════════════════ -->
-      <section id="practicum" class="tutorial-section">
+      <section id="practicum" class="main">
         <h2>Part 2: Practicum</h2>
-        <p class="time-estimate">About 30 minutes.</p>
         <p>This practicum examines a single real-world web page for <code>autocomplete</code> attribute issues. The page is a public website homepage captured in May 2026. <strong>The name and URL of the site are withheld</strong> to avoid public-relations concerns unrelated to this tutorial. The page facts below are a snapshot; the live page may differ.</p>
-        <!-- ─── ─── ─── ─── -->
         <section id="example-page">
           <h3>The example page</h3>
           <p class="time-estimate">About 3 minutes.</p>
@@ -466,7 +410,6 @@
           <pre class="code-sample"><code>&lt;form action="#" method="post" novalidate="novalidate"
   autocomplete="new-password"&gt;</code></pre>
           <p>Both elements were captured from the rendered DOM on 2026-05-30 using a headless browser. They are the only non-hidden, non-search, non-consent form inputs on the page.</p>
           <h4>The two defects</h4>
           <p>Two <code>autocomplete</code> attribute issues are present:</p>
           <ul>
@@ -474,8 +417,6 @@
             <li><strong>Issue B</strong> — The <code>&lt;form&gt;</code> element has <code>autocomplete="new-password"</code>. On a <code>&lt;form&gt;</code> element, the only valid values are <code>on</code> and <code>off</code>. <code>new-password</code> is a valid token for <code>&lt;input&gt;</code> elements, not for <code>&lt;form&gt;</code> elements. This value appears to be a misapplication of a technique sometimes used to suppress browser autofill on individual input fields.</li>
           </ul>
         </section>
-        <!-- ─── ─── ─── ─── -->
         <section id="human-testing">
           <h3>Human testing</h3>
           <p class="time-estimate">About 7 minutes.</p>
@@ -510,8 +451,6 @@
             <li><strong>Issue B (invalid value on form):</strong> Possibly missed, unless the tester knows the valid values for <code>autocomplete</code> on <code>&lt;form&gt;</code> elements.</li>
           </ul>
         </section>
-        <!-- ─── ─── ─── ─── -->
         <section id="rule-engine-testing">
           <h3>Rule-engine testing</h3>
           <p class="time-estimate">About 7 minutes.</p>
@@ -547,21 +486,15 @@
             <li><strong>Issue B (invalid value on form):</strong> Missed by axe-core; found by HTML CodeSniffer in the Kilotest ensemble.</li>
           </ul>
         </section>
-        <!-- ─── ─── ─── ─── -->
         <section id="ai-testing">
           <h3>AI-agent testing</h3>
-          <p class="time-estimate">About 7 minutes.</p>
           <p>An AI agent was asked to find <code>autocomplete</code> attribute issues on the example page. Two scenarios were tested, illustrating how the content given to the agent affects what it can find.</p>
           <h4>What the AI agent was given and asked</h4>
           <p>In both scenarios, the instructions were the same:</p>
           <div class="ai-output">
             <p><strong>Instruction to the AI agent:</strong></p>
             <p>The following content is from a web page. Identify all violations of WCAG 2.2 Success Criterion 1.3.5 (Identify Input Purpose) related to the <code>autocomplete</code> attribute. For each violation, state the element, the problem, and the correction required. Be precise about which values are valid for each element type.</p>
           </div>
           <h4>Scenario 1: AI agent given the raw HTML source</h4>
           <p>The raw HTML delivered by the server was provided to the AI agent. This HTML does not contain the newsletter form, which is injected by JavaScript after page load.</p>
           <div class="ai-output">
@@ -573,7 +506,6 @@
             <p><strong>Result: Both issues missed — 100% false negative rate.</strong></p>
             <p>The AI agent correctly analysed what it was given, and correctly found no violations in the raw HTML. But the raw HTML does not contain the newsletter form. The AI agent could not report what it was not given. This is not a failure of the agent's reasoning — it is a failure of the data provided to it.</p>
           </div>
           <h4>Scenario 2: AI agent given the rendered DOM</h4>
           <p>The HTML of the fully rendered DOM — captured after JavaScript execution — was provided to the AI agent. This HTML includes the newsletter form with its email input and the form element.</p>
           <div class="ai-output">
@@ -593,20 +525,17 @@
             <p><strong>Result: Both issues correctly found — when given the right input.</strong></p>
             <p>With the rendered DOM, the AI agent identified both violations accurately and provided correct remediation advice. It also flagged that suppressing autocomplete on a personal data form is itself a usability concern for users who rely on autofill — a nuance that rule engines do not typically report.</p>
           </div>
           <h4>What this demonstrates</h4>
           <p>The two scenarios show that the effectiveness of AI-agent testing depends critically on what the AI agent receives, not only on the capability of the underlying model. Providing the rendered DOM rather than the raw HTML source is the difference between finding both issues and finding neither.</p>
           <p>This has a direct practical implication: when using AI agents for accessibility testing, you must understand whether the page's content is server-rendered or JavaScript-rendered. If it is JavaScript-rendered, the agent must receive the rendered DOM, not the raw source.</p>
           <p>It also illustrates a limitation that affects all three strategies: all depend on the tester (human, rule engine, or AI agent) receiving the full relevant content. Differences in what each strategy can access — raw source, rendered DOM, accessibility tree, visual rendering — partly determine what each strategy can find.</p>
           <h4>Verdict on autocomplete issues</h4>
           <ul>
             <li><strong>Issue A (missing attribute on input):</strong> Missed when given raw HTML; found when given rendered DOM.</li>
             <li><strong>Issue B (invalid value on form):</strong> Missed when given raw HTML; found when given rendered DOM.</li>
           </ul>
+          <p><strong>Note on AI results:</strong> The AI testing results were captured in May 2026 from a specific model. As AI models and the resources available to them improve, results may change — potentially for better or worse. The captured results are preserved here as a fixed point of comparison.</p>
         </section>
-        <!-- ─── ─── ─── ─── -->
         <section id="comparison">
           <h3>Comparing the strategies</h3>
           <p class="time-estimate">About 6 minutes.</p>
@@ -669,14 +598,10 @@
           </details>
         </section>
       </section>
-      <!-- ═══════════════════════════════════════════════════════ -->
-      <section id="conclusion" class="tutorial-section">
+      <section id="conclusion" class="main">
         <h2>Conclusion</h2>
         <p class="time-estimate">About 5 minutes.</p>
         <p>You have seen all three accessibility testing strategies applied to the same page and the same issue type. Each strategy has genuine strengths and genuine limitations. The key points to take away:</p>
         <ul>
           <li><strong>Use all three.</strong> The strategies are complements, not alternatives. Rule engines provide fast, consistent first-pass coverage. AI agents can reason about nuance and explain issues. Human testing catches what the others miss and is the ultimate measure of real-world usability.</li>
           <li><strong>Understand what each strategy sees.</strong> A strategy can only report on what it receives. For JavaScript-rendered content, ensure your tools — rule engines, AI agents, or human testers — are working with the rendered DOM, not the raw HTML source.</li>
@@ -684,8 +609,9 @@
           <li><strong>Verify AI output.</strong> AI agents can produce both false positives and false negatives. Their output is a useful starting point, not a final verdict. Critical review against the relevant standards is essential.</li>
           <li><strong>Test early and often.</strong> The cheapest time to fix an accessibility issue is before the page is shipped. Rule-engine testing integrated into a development workflow catches issues while the code is fresh and the fix is small.</li>
         </ul>
-        <h3>Further reading</h3>
+      </section>
+      <section id="further-reading" class="main">
+        <h2>Further reading</h2>
         <ul>
           <li><a href="https://www.w3.org/WAI/WCAG22/Understanding/">Understanding WCAG 2.2</a> — W3C explanations of each success criterion</li>
           <li><a href="https://www.w3.org/WAI/test-evaluate/tools/list/">Web Accessibility Evaluation Tools List</a> — W3C registry of rule-engine tools</li>
@@ -694,29 +620,28 @@
           <li><a href="https://arxiv.org/abs/2304.07591">Accessibility Metatesting: Comparing Nine Testing Tools</a> — research on rule-engine coverage variation</li>
           <li><a href="https://arxiv.org/abs/2309.10167">Testaro: Efficient Ensemble Testing for Web Accessibility</a> — the rationale for ensemble testing</li>
         </ul>
-        <p>Return to the <a href="/">Kilotest home page</a>.</p>
-        <div class="comment-section" id="feedback-section">
-          <h3>Suggest an improvement</h3>
-          <p>Have a suggestion for improving this tutorial? Submit it below. Your suggestion will be saved for the tutorial authors to review.</p>
-          <form id="comment-form" novalidate>
-            <label for="comment-text">Your suggestion (up to 500 characters):</label>
-            <textarea
-              id="comment-text"
-              name="content"
-              maxlength="500"
-              rows="5"
-              autocomplete="off"
-              aria-describedby="char-count-msg"
-            ></textarea>
-            <p class="char-count" id="char-count-msg"><span id="char-remaining">500</span> characters remaining</p>
-            <button type="submit" id="comment-submit">Submit suggestion</button>
-          </form>
-          <div role="status" id="comment-feedback" aria-live="polite" aria-atomic="true" class="comment-feedback"></div>
-        </div>
       </section>
+      <section id="suggest-improvement" class="main">
+        <!--<div class="comment-section" id="feedback-section">-->
+        <h2>Suggest improvements</h2>
+        <p>Please submit suggestions for improving this tutorial below. The Kilotest managers will review them.</p>
+        <form id="comment-form" novalidate>
+          <p id="comment-label">Your suggestions (up to 500 characters):</p>
+          <textarea
+            id="comment-text"
+            name="content"
+            maxlength="500"
+            rows="5"
+            autocomplete="off"
+            aria-labelledby="comment-label"
+            aria-describedby="char-count-msg"
+          ></textarea>
+          <p class="char-count" id="char-count-msg"><span id="char-remaining">500</span> characters remaining</p>
+          <button type="submit" id="comment-submit">Submit suggestions</button>
+        </form>
+        <div role="status" id="comment-feedback" aria-live="polite" aria-atomic="true" class="comment-feedback"></div>
+        <!--</div>-->
+      </section>
     </main>
     <script>
       // ── Knowledge check (Lesson 1) ──────────────────────────────